DEPLOY ANYWHERE. ONE ARTIFACT, EVERY ENVIRONMENT.

An ops team running governed Claude in production usually inherits a stack of seven services. A web tier, a session cache, a rate-limit store, a job runner, a search index, a log shipper, an identity service. Each one is a deploy path, an upgrade cadence, and an on-call surface. A CISO who approves that stack for one environment then has to re-approve each moving part for staging, for an air-gapped VM, and for a developer laptop, because the variance between deployments is where governance drift hides.

systemprompt.io collapses that stack into one process. The HTTP server, the job scheduler, the template engine, the JWT middleware, the tiered rate limiter, analytics, and cost tracking all link into the same Rust binary. PostgreSQL is the only runtime dependency. Session state lives in the database. Rate-limit state lives in process memory. No Redis, no Kafka, no Elasticsearch sits in the dependency graph, so the CISO's approval covers one artifact rather than seven services.

The entry point is nine lines. Two function calls bring up routes, schemas, jobs, health checks, and the CLI. A linker pin keeps extension registrations from being stripped under link-time optimisation, then the CLI dispatcher runs. A staff engineer can read the full bootstrap in under a minute and map every deploy target back to the same two calls. The full source of the entry point is named in the reference below.

A team adding a custom capability to a typical AI stack writes a separate service, a Dockerfile, a deploy pipeline, and an interface contract, and then carries the contract drift forever. Every upgrade has to re-certify the host plus every plugin against a new ABI, and a production incident can land on either side of the service boundary. The build-vs-buy answer for a CTO is whether they own that coordination or push it down to the linker.

systemprompt.io pushes it down to the linker. A custom capability is a crate that implements the extension trait and registers itself with a registration macro. The macro emits a factory into a linker section at compile time. At startup the registry walks that section once and instantiates each extension. No classpath scan, no dynamic loader, no host-plugin ABI to version. A staff engineer verifies the mechanism by opening the trait and the macro in the references below. The wire between host and extension is a compiled symbol, not a process boundary.

The same pattern ships in the box. The template links three extensions into the binary (web, marketplace, email), and the host provides the infrastructure extensions for database, logging, analytics, files, users, AI, MCP, OAuth, content, agents, and the scheduler. A custom extension follows the same recipe. Implement the trait, call the macro, recompile, redeploy the same artifact. The CISO approving the rebuild is approving one binary, not a host plus a plugin catalogue.

Environment drift is the slow killer of self-hosted infrastructure. Local config diverges from staging, staging diverges from production, and a config-only change ships an outage nobody spots in review because the diff lives in a config server, not in the repo. A CTO who asks "what is different between prod and the air-gapped cluster" should get the answer from git log, not from a screenshot.

systemprompt.io binds the binary to a profile through one environment variable. At startup, the profile loader reads the chosen profile name, loads the matching YAML file, and stores the result in a global one-time cell. Every subsystem reads from that single value for its configuration. Rate-limit tiers, JWT issuer and audience, log level, database connection, and storage paths all resolve from the same profile. Switching environments means changing the variable and restarting the process. The binary does not change, so an air-gap approval granted against one SHA is still valid against the staging run of the same SHA.

A profile is a directory checked into version control. The local profile disables rate limits and turns logging up for developer ergonomics. The production profile sets tiered rate limits, JSON logging, and a JWT configuration with issuer, audiences, and expiration. Per-region or per-tenant profiles follow the same shape. A CISO asking "what changed in the air-gapped profile last quarter" reads a git diff, not a change-ticket trail.

Most stacks ship one binary for the server, another for the CLI, and a third dashboard image to operate it. Three things to package, three to version, three to keep in sync on upgrade. A staff engineer running an incident at 3am has to remember which binary on which host has which subcommands. systemprompt.io is one artifact playing all three roles, so the command a developer runs on a laptop is the command an operator runs in production.

The same binary parses subcommands and dispatches them. systemprompt services start --foreground brings up the HTTP server. systemprompt admin agents list runs against the database. systemprompt infra logs view queries the log store. The CLI is not a wrapper around the server. It is the server invoked with a different subcommand, so an admin task in production and a debug run on a laptop hit the same code paths and the same profile loader.

The production container reflects that. The image starts from debian:bookworm-slim, installs two system libraries (libpq5 for the PostgreSQL client and libssl3 for TLS), copies the pre-built binary into /app/bin/, sets a healthcheck hitting the health endpoint, and runs the entrypoint. No Rust toolchain in the image, no multi-stage compile. A CISO doing a supply-chain review sees a binary and two library packages, not a compiler and a build cache, which keeps the attack surface of the production image small.

Scaling a typical AI gateway means scaling the cache and the session store with it. Add a replica, add capacity to Redis, watch for hot keys. A CTO signing off on an in-cluster deployment ends up approving three distributed systems instead of one, and every one of them is a separate on-call surface. systemprompt.io takes those moving parts off the table by keeping per-request state stateless and per-process state local, so horizontal scaling is N binaries behind a load balancer.

JWT validation runs inside the request. The JWT service constructs a local decoding key from the profile secret once at startup, and every request verifies signature and expiry against that key without touching I/O. No session store sits in front of the binary and no external auth service is called per request, so any replica can serve any request and a lost pod does not strand a session on a remote cache.

Rate limiting is local too. Each replica meters its own share of traffic through the in-process tiered limiter, with separate token buckets per auth tier so a batch of MCP tool calls cannot crowd out an admin invocation at the same replica. A CTO who needs globally coordinated limits can still layer an upstream reverse proxy, but the binary does not require one to deploy safely.

Health and readiness ride on the same binary. The health endpoint verifies database connectivity for liveness probes. The readiness layer flips an atomic flag and broadcasts when the server starts accepting connections, and the database layer manages its own connection pool so no external pooler (PgBouncer, pgpool) has to be deployed and approved alongside.

A regulated team picking AI infrastructure asks one question early. Can this run somewhere we trust, including a network with no internet route? A vendor whose air-gapped build is a separate code branch forces the CISO to re-approve that branch against a different supply chain. systemprompt.io answers the question by being a binary, a database, and a profile, and nothing else. The same artifact runs in every environment, and air-gapping is a profile choice, not a fork.

The binary runs on any Linux x86_64 host with libpq5 and libssl3 available. The container image is the same binary on debian:bookworm-slim. No cloud-specific packaging, no environment-specific build path, so the CISO who approved the production SHA has approved the staging SHA and the air-gapped SHA as well.

Air-gapped deployment is a configuration, not a source-code fork. The binary is its own token issuer. Admin tokens are signed locally with HS256 using the profile secret, so tokens verify in-process without Auth0, Okta, or an external identity service in the loop. Logging writes to PostgreSQL. The only outbound network calls are to PostgreSQL and to whichever AI providers the profile explicitly configures, so an auditor can enumerate the perimeter of a deployment from one profile file, not from a network capture.