Skip to main content
One release provides one Python distribution and one container image. Choose how to run that release: To evaluate airmux first, follow the quickstart, which uses the recommended shape. For the full platform, start with airmux unless you need to size or restart the services independently. Split does not permit mixed releases: every role must use the same image digest until cross-version bundle compatibility is defined.

Docker Compose

Run airmux and Postgres on one host.

Upgrade and rollback

Plan an upgrade and roll back from a consistent recovery point if verification fails.
Install the airmux CLI on the machine you use to manage the instance.

​
Full-platform production requirements

The image defaults to the airmux role. Its container listens on port 8080 and serves the webapp, /api/v1, /inf/v1, /healthz, and /readyz from one origin.

​
Claim the instance

The first human account becomes the instance owner. Claim a new public instance immediately after it becomes reachable:
Until the first account is created, anyone who can reach the sign-up page can claim ownership. Public sign-up is disabled after claim unless AIRMUX_PUBLIC_SIGNUP=true; invitation links still work for their invited email.

​
Persist and back up

Back up Postgres and /state together. The state directory contains plaintext provider credential files in the default secret-store configuration as well as gateway identity, cached bundles, and queued usage. The airmux layout owns one gateway state directory. Every split gateway must have a distinct persistent directory. Never clone a live gateway identity or share its SQLite outbox between replicas.

​
Verify a deployment

quickstart is the final proof because it performs a real inference request through the public route. Continue with operations, security, and upgrade and rollback before production traffic.