Algoland Compressor can run inside customer-controlled infrastructure while keeping the implementation sealed. The customer gets local API functionality and verified reports, not source code or private internals.
If a customer uses its own compute, executable code must run in that environment. The protection comes from how that code is delivered and controlled: sealed runtime, signed build, restricted operational API, integrity checks and contractual controls.
| Option | Where data runs | What the customer receives | IP exposure |
|---|---|---|---|
| Remote Algoland API | Algoland infrastructure | HTTPS API access only | Lowest executable exposure, but customer data leaves its infrastructure unless synthetic samples are used. |
| Locked container or VM | Customer infrastructure | Signed sealed runtime with local API endpoints | Balanced pilot model: customer compute and local data, no source or internals. |
| Confidential runtime | Customer cloud or dedicated host | Attested sealed runtime, encrypted storage, restricted shell/admin access | Strong enterprise model when infrastructure supports attestation. |
| Algoland-controlled appliance | Inside customer network | Network appliance exposing local API only | Strongest balanced production model: customer data stays local, internals stay controlled by Algoland. |
Compress, decompress, verify, health, status, usage reporting, license state and deployment policy endpoints.
No source code, implementation details, debug access, internal documentation or shell access to the runtime.
Signed build hash, license validation, version pinning, update control, audit logs and no-reverse-engineering contract terms.
customer storage payload -> local sealed Algoland runtime -> /api/compress or chunked session -> .algd artifact + usage report -> /api/decompress + /api/verify -> SHA-256 exact restore report Customer controls network and compute. Algoland controls runtime signing, licensing, releases and support.