Private AI on infrastructure you control
Run the platform inside your own environment: the console, the Agent Gateway, PostgreSQL and NATS on one Linux server with Docker Compose, from the same images as the hosted service. Self-hosted means you control where the control plane runs, where models execute, and where your data lives.
Two ways to deploy self-hosted AI agents
Which path you take depends on your infrastructure and requirements:
| Option | Prerequisites | When to use |
|---|---|---|
| Docker Compose — one Linux server | Linux with Docker Engine 24+ and the Compose plugin. 4 CPU, 8 GB RAM, 40 GB disk. | A pilot, a small team, or a single site. |
| No internet — image archive and signed files | The image archive carried to the site, a signed licence document and a local model. | Sites with no external connectivity, or rules that prohibit internet access. |
Get the bundle, then install
Obtain the accepted release bundle and matching installation guide from the delivery team. The commands below illustrate a versioned bundle; verify the exact filenames, dependencies, licence and image provenance for your release.
cd compose
cp .env.example .env # set ACT_HOSTNAME
docker compose up -d --wait
docker compose logs control-plane | grep -A4 "FIRST-BOOT ADMIN"Customer-hosted deployments use packaged deployment configuration. An offline deployment requires an accepted bundle, local model and disconnected installation tests.
Enrolling hosts
Hosts > Add a host gives the same one-line install command as the hosted service, pointed at your server. With the default internal certificate, give each host your server's CA for the first download; the agent installs it from then on.
Air-gapped sites
Disconnected operation needs more than container images. Accept the local model, identity and licence flow, dependency inventory, update process, restore procedure and no-egress tests before treating an installation as air-gapped.
Runtime-editable URLs
The public URLs the control plane hands to agents and uses for the identity-provider callback are changed from the console's Settings page, not by redeploying.
Enrollment wizard and the data-boundary view
A guided enrollment wizard and a site view that shows exactly where data is allowed to cross the boundary are part of the hosted control plane rather than of a self-hosted install.
On first start the control plane writes a one-time set-password link for the first administrator to a protected file on the server (never to its log); open it on your console and choose the password. Sign-in through your own identity provider (OIDC) is set up under Settings > Sign-in.
Customer-hosted installations support an identity provider through OIDC with PKCE. Hosted workspace SSO must be confirmed for the agreed deployment.
A self-hosted deployment brings its own model the same way a hosted one does.
Bring your own model — OpenAI-compatible endpoints, Ollama, Anthropic, or Cloudflare AI Gateway / Workers AI — with keys envelope-encrypted at rest.
Release signing keys
Every self-host release archive ships a detached Ed25519 signature over its inventory. Before running anything from an archive, check the fingerprint of the key that signed it against this list, verify the signature, then the file hashes, as the SETUP guide inside the archive describes. Never trust a key shipped inside the archive you are verifying.
| Key | SHA-256 of the public key | Valid from | Status |
|---|---|---|---|
actree-selfhost-release-2026-10 · Ed25519 | 2dd371a3b48d5590b6f11aa2f0a83e6588c3c3d8fed2df726405bcdac730ec49 | 2026-10-20 | In force |
Three deployment models
- Sovereign — fully self-hosted
- Hosted — multi-tenant control plane
- Hybrid — self-hosted execution, hosted control plane
Bring one question of your own.