Deploy participant resolution as resilient enterprise infrastructure.
Run Roster across multiple instances with PostgreSQL, health-based routing, and the operational controls required for production-critical workflows.
Start with one container. Scale when participant resolution becomes critical infrastructure.
Simple to start. Ready to scale.
Roster supports three deployment shapes, so you can choose the architecture that fits the workload.
One Roster instance with embedded SQLite and durable /data storage. The simplest way to evaluate Roster or operate a standalone deployment. No external database required.
One Enterprise Roster instance backed by PostgreSQL. Use managed database operations without introducing multiple Roster instances.
Two or more identical Roster instances behind a load balancer, backed by PostgreSQL with a writer endpoint and one or more read replicas. For production-critical agents, applications, and workflows.
One public endpoint. Multiple Roster instances.
Clients continue to reach Roster through the same MCP, REST, CLI, and web surfaces. The load balancer distributes requests only to ready Roster instances. Every instance connects to the same PostgreSQL writer and read-replica endpoints and uses the same runtime configuration.
Writes and transactions go to the PostgreSQL writer. Eligible ordinary reads are distributed across the read replicas.
/health/ready routes traffic only to instances that can reach the PostgreSQL writer and pass Roster's HA configuration checks. /health/live separately monitors process liveness.
Writes, transactions, readiness checks, authentication data, and security decisions remain on the configured PostgreSQL writer.
Roster distributes eligible ordinary reads across the configured read replicas.
PostgreSQL coordinates rate limits and background work across Roster instances. Worker leases and recovery allow another instance to reclaim scheduled work. Sticky sessions are not required.
Controlled releases. Restricted runtime access.
Production deployments should be deliberate and use least-privilege credentials.
Use restricted application credentials for running Roster. Read replicas can use a separate read-only role.
Run the same Roster image version and runtime configuration across every instance.
Keep database backups, restore procedures, recovery objectives, monitoring, and operational responsibilities within your existing production process.
Your infrastructure stays under your control.
Deploy Roster on-premises, in a private cloud, in your public-cloud account, or on Kubernetes. Your infrastructure platform provides:
- Load balancing
- PostgreSQL replication
- Automatic primary promotion
- Stable writer and read-only endpoints
- Database backups and point-in-time recovery
- Failure-domain placement
- Centralized monitoring and logs
Roster connects to this infrastructure and validates its required HA configuration. It does not operate or independently verify the PostgreSQL cluster.
Explore hosting optionsEvery Roster surface scales with you.
Give agents access to governed participant resolution through the MCP clients they already use.
Add participant resolution to applications, workflows, automation platforms, and internal services.
Use the same Roster deployment from scripts, terminal workflows, and CI/CD pipelines.
Let authorized administrators and project owners manage projects, participants, memberships, labels, directory associations, and delegations.
No new integration surface is required when moving from a standalone deployment to Enterprise.
Explore integrationsSecurity by architecture.
Run Roster inside the infrastructure and network boundaries controlled by your organization.
Keep database, directory, identity-provider, and model-provider credentials under your control.
Represent human users, AI agents, and service accounts with separate identities and independently revocable credentials.
Control which capabilities, projects, participants, delegations, and directory records each identity can access.
Review platform activity and resolution-related events with Enterprise audit capabilities.
Inspect model execution and resolution activity without giving agents direct access to upstream directory credentials.
Enterprise capabilities
| Capability | Free & Pro | Enterprise |
|---|---|---|
| Self-hosted deployment | ✓ | ✓ |
| Embedded SQLite | ✓ | ✓ |
| Web, REST, CLI and MCP | ✓ | ✓ |
| Customer-selected model provider | ✓ | ✓ |
| PostgreSQL | — | ✓ |
| Multiple Roster instances | — | ✓ |
| High-availability deployment mode | — | ✓ |
| PostgreSQL read-replica routing | — | ✓ |
| Enterprise audit | — | ✓ |
| Enterprise SLA | — | ✓ |
Roster supports the application layer. Your platform provides database failover.
A highly available Roster deployment has two independent layers: two or more Roster instances behind a load balancer, and a PostgreSQL service with a writable primary, at least one read replica, automatic promotion, and stable endpoints.
If a Roster instance stops, the load balancer removes it and continues routing to ready instances. If the PostgreSQL primary stops, the database service promotes an eligible replica and moves the writer endpoint. Roster becomes ready again when that endpoint is available.
Roster does not provide PostgreSQL replication or primary promotion.
Production acceptance
Before directing production traffic to a highly available deployment, verify that:
- At least two Roster instances pass readiness checks
- Authenticated requests continue when either Roster instance is removed
- The PostgreSQL service promotes a replica and restores the writer endpoint
- Roster recovers without changing ROSTER_DATABASE_URL
- Ordinary reads tolerate the expected replication lag
- Background work recovers correctly after an instance failure
- Backups and isolated restore procedures have been tested
- Logs, monitoring, alerts, and operational ownership are in place
Availability is a property of the complete system — not the Roster container alone.