The short answer

Self-hosting Agent Rooms means operating the Room services, persistence, identity integration and execution providers in your infrastructure. The reference app is a useful local starting point, but its development authenticator and mock runtime require deliberate replacement for a real application.

Understand what the reference app includes

The self-hosting guide starts from the open-source repository and its Rooms API example. The reference demonstrates Room creation, participation, task execution, artifacts, approval and lifecycle transitions.

Use that sequence to understand the domain before integrating a real provider. A deterministic mock makes it easier to inspect retained records without confusing model variability with an application error. A successful local health check demonstrates that the app responds, not that identity, backups or external execution are ready.

Replace development identity with verified identity

The default development tenant header is intended for a trusted local environment. It does not verify the caller. Your host must authenticate requests and resolve the tenant and actor from trusted identity evidence.

Follow the identity integration guidance and test attempted tenant switching and actor impersonation. An application should not let a caller obtain another organization's Room simply by supplying a different identifier. Apply authorization to the selected resource and operation after authentication.

Make persistence and upgrades explicit

Configure the PostgreSQL adapter and use the same intended schema for migration and runtime stores. The migration guide describes an ordered operational migration chain and coordinated rollout.

Before deployment, exercise a restore in a development or staging environment. Inspect not just the Room aggregate but also the operational records used by coordination and execution. A backup that preserves documents while losing worker ownership information does not demonstrate that the operational workflow can safely continue.

Connect one provider and one controlled workflow

An illustrative first deployment might support only internal proposal drafting. Give the provider the minimum tools that task needs. If the workflow later sends a message or writes to another system, add the corresponding approval and effect controls as a separate integration step.

Confirm which checkpoints the provider supports and awaits. Keep credentials in your deployment's secret-management path. Do not infer that changing from a mock to a real model preserves every behavior of the reference demonstration.

Define a deployment acceptance record

  • Record the exact source and coordinated package versions.
  • Verify authenticated access and rejection across tenant boundaries.
  • Inspect a completed task, artifact version and review decision.
  • Restore a backup and inspect the retained operational state.
  • Exercise a documented restart scenario with your worker configuration.
  • Assign responsibility for migrations, credentials, monitoring and incident recovery.

These are recommended integration checks, not a certification supplied by the demo. The PostgreSQL operations reference supplies the storage concerns to include in your own runbook.

Sources and further reading

Documentation reviewed . Consult the linked documentation for current implementation details.