On-prem deployment

Run the Compresr compression API inside your own network — a two-container stack with the same endpoints, SDKs, and keys as the hosted API.

Compresr on-prem runs the same compression API you use at api.compresr.ai inside your own network. Your documents are processed on your hardware and never leave it; only anonymous usage counts are reported back for billing. The deployment is a two-container Docker stack delivered via Distr, with model weights baked into the image.

When to choose on-prem

Data can't leave your network. Compliance, client contracts, or internal policy rule out sending context to a hosted API.
Air-gapped or egress-restricted environments. The engine container needs no internet access at any point — weights ship inside the image.
Latency control. Compression runs next to your retrieval stack, with no WAN round-trip.

If none of these apply, the hosted API is simpler: no GPU to provision, no upgrades to schedule.

Architecture

Container	Role	Network exposure
`compresr-proxy`	Customer-facing API: auth, validation, admission control, usage metering	Publishes port `8000`
`compresr-engine`	GPU compression engine	No host port. Joined only to an internal Docker network with no outbound internet

The proxy is the only thing your clients (and your network) ever talk to. The engine is reachable solely from the proxy over the internal network, and every proxy→engine call carries a short-lived signed token — hitting the engine directly is rejected even from inside the Docker host.

Which compression model the engine serves is selected at install time through Distr; the API surface is the same regardless.

Requirements

GPU: an NVIDIA GPU with at least 24 GB VRAM, plus the NVIDIA Container Toolkit on the host. There is no CPU-only mode.
Docker with Compose (the stack is deployed and upgraded through Distr).
A Compresr license key (cmp_...) — see How to get access.

There is no configuration file to fill in: the stack boots with zero customer-supplied settings, and your license key is presented per request, exactly like the hosted API.

Using it

The proxy exposes the same question-specific compression endpoints as the hosted API, on port 8000:

POST /api/compress/question-specific/ — single request
POST /api/compress/question-specific/batch — up to 100 items
POST /api/compress/question-specific/stream — Server-Sent Events
GET /api/compress/question-specific/models, GET /api/compress/question-specific/health

Point the SDK at your deployment and everything else is unchanged — parameters, response shapes, and error envelope match the hosted API:

python

Plain HTTP and the SDKs

The proxy itself speaks plain HTTP on port 8000. The Python SDK refuses a non-loopback http:// base_url with CompresrError("insecure_base_url") unless COMPRESR_ALLOW_INSECURE=1 is set; the TypeScript SDK logs a warning and proceeds. Terminate TLS in front of the proxy (your ingress or reverse proxy) and point the SDKs at that https:// URL, as above. cURL has no such check.

On first authenticated request, the instance binds itself to your license key: the proxy writes a signed identity manifest, and requests with a different cmp_ key are rejected with 401 from then on. One instance serves one customer.

For operations, the proxy also exposes unauthenticated GET /health, GET /ready, and a Prometheus-style GET /metrics (request counts and latencies by route and status, plus backpressure rejections).

Security model

The engine has no internet access. It runs on an internal-only Docker network with no host port and no outbound route; documents processed there cannot leave.
The engine holds no customer secrets. Your license key exists only in requests to the proxy; the proxy authenticates to the engine with its own short-lived signed tokens, provisioned automatically on first boot.
Instance-to-customer binding. The first authenticated key claims the instance (signed identity manifest); other keys get 401.
Weights ship in the image. Nothing is downloaded at runtime, so the stack works fully air-gapped after installation.
Request content is never persisted. context, query, and compressed output are not logged, not queued, and not stored beyond the lifetime of the request.

What crosses the network

The proxy reports usage events to the Compresr platform every few seconds for billing: the model name, original_tokens, compressed_tokens, duration_ms, and your license key. Never the content — no context, no queries, no compressed output.

If the platform is unreachable, a local queue buffers usage for a grace window of roughly 10 minutes; after that, compression endpoints return 503 until connectivity is restored. Health and metrics endpoints keep working throughout.

Limits

Limit	Value
Concurrent in-flight compressions	8 (override with `COMPRESR_MAX_INFLIGHT_REQUESTS`); excess requests get `503` + `Retry-After`
Per-request time budget	600 s (then `504`)
Batch size	1–100 items
Context size	~10 MB per context
Query length	≤ 10,000 characters

As with the hosted API, very short contexts are returned unchanged rather than compressed.

How to get access

On-prem is available on enterprise plans. Contact [email protected] and we'll provision your Distr access and license key, and walk your team through the install.