What is self-hosting
Oso for Agents Self-Hosted runs the whole stack on your own infrastructure with Docker Compose. You supply two PostgreSQL databases and an OIDC identity provider, fill in a single.env file, and start everything with docker compose up -d.
A self-hosted stack runs a single environment and needs no outbound egress unless you enable a feature that requires it.
Architecture
The stack runs as a set of containers. Apart from PostgreSQL, it is stateless: the databases hold all persistent data and the other services rebuild from them on start.
A set of one-time setup containers —
ensure_tenant_environment, seed_metadata, init_policy, and oso_sync — bootstrap the stack on first boot and then exit; oso_sync_loop keeps the enforcement engine in sync as data changes.
When to choose self-hosting
Oso for Agents Self-Hosted is a good option if you have compliance requirements that prevent you from using the managed Oso for Agents service.What you provide
You bring two PostgreSQL databases — a single server hosting both works fine — and an OIDC identity provider such as Okta, Entra ID, or Google Workspace.Your responsibilities
Self-hosting means you own the operational concerns a managed service would otherwise handle:- Server and database provisioning and maintenance — provision, maintain, and harden the host and PostgreSQL.
- Service updates — apply new Oso for Agents Self-Hosted releases as they land (see Operations → Upgrades).
- High availability and scalability — a single stack is not highly available on its own; for high availability, run two stacks behind a load balancer (see Operations → High availability).
- Backups and disaster recovery — back up both databases and
.env(see Operations → Backups and restore). - Monitoring and uptime — watch the stack’s health and logs.