Deployment options
Choose a deployment from the identity, isolation, connectivity, storage, and operational responsibility your organization requires.
| Mode | Typical boundary | Identity | Storage |
|---|---|---|---|
| RunMat Cloud | Hosted multi-tenant service | Hosted identity integration | Managed relational and object storage |
| Single-tenant | One organization or controlled tenant set | Customer OIDC | Configured database and blob store |
| Isolated or air-gapped | Restricted network | Local enterprise OIDC and signed entitlement material | Local infrastructure |
Server is designed as a single public HTTP service with internal modules for authentication, organizations, files, packages, policy, execution, dispatch, and observability. Production deployments also require PostgreSQL-compatible metadata storage and a configured blob backend.
Before deployment, define the public base URL, TLS termination, OIDC issuer and audience, tenant bootstrap, blob lifecycle, database backup, outbound-provider policy, observability export, and recovery objectives. A readiness test should exercise authentication, file upload and download, history, events, and every enabled execution path.
Configuration names and availability can vary by distribution. Use the configuration reference shipped with your Server build and validate it in staging before promotion.
Required services
A production installation needs the Server binary, a PostgreSQL-compatible database for identity and resource metadata, and a supported blob store for files and artifacts. Interactive login requires an OIDC issuer. Email, analytics, observability export, enterprise SSO/SCIM, billing, managed model providers, search, and remote execution are optional integrations.
Run the API behind TLS termination. Configure forwarded client IPs for the actual proxy chain. The socket peer is the safe default. If the deployment trusts X-Forwarded-For, set the known proxy-hop count; the first header value can be client supplied.
Installation sequence
- Provision the database and blob container with separate least-privileged credentials.
- Generate encryption material, the API-key pepper, and provider secrets in a secret manager.
- Configure public API and application origins, CORS, and OIDC issuer, audience, and client IDs.
- Apply the database migrations supplied with the release.
- Start one instance and check liveness plus database/blob readiness.
- Test login, organization/project creation, small and multipart transfers, history, and event reconnect.
- Add replicas after confirming background-job and dispatch ownership.
Keep reviewed non-secret configuration per environment. Missing production secrets, issuers, and storage settings should fail startup. Production mode permits only production identity and durable blob backends.
Backup and recovery
Back up database metadata and blobs as one recovery set. The database records which content hashes and versions belong to each project; the blob store holds the bytes. Restore into an isolated environment and verify current files, historical versions, snapshots, and retained-storage totals. Both components are required: database metadata resolves project history, and the bucket supplies its content.
Readiness checklist
- Readiness includes database and blob dependencies; liveness only proves the process responds.
- Request IDs, structured logs, traces, and metrics reach the selected observability backend.
- OIDC key rotation and clock skew have been exercised.
- Proxy timeouts and body limits permit expected streaming and dataset sizes.
- Backup, retention, key rotation, and incident ownership are documented.
- Remote workers, when enabled, are isolated and use worker-scoped credentials.