Scale your platform
Add capacity to your Render deployment, then coordinate multiple API instances with PostgreSQL and Redis.
Your platform now runs agents, scheduled briefings, coding sessions, and Company work. Start with one always-running API instance and one Uvicorn worker. Add capacity when the measurements show you need it.
Check what needs capacity
Use Render's CPU and memory metrics alongside AgentOS run latency and queue activity. If the API runs out of memory, increasing the instance size is often the first useful change. Slow model responses or an external API rate limit need a different fix.
Coding sessions can run in AgentCore while the API remains on Render. If coding work is still running directly on the API host, configure sandboxes before increasing that workload.
What changes with multiple instances
Replicas share one platform and its data:
| Component | Responsibility |
|---|---|
| PostgreSQL | Conversations, Company records, schedules, and the durable job queue. |
| Redis | Live run events and cancellation shared across API instances. |
| AgentCore | Isolated coding sessions outside the API containers. |
| S3 | Saved coding workspaces and native-session checkpoints. |
| API replicas | Serve requests and participate in the shared execution queue. |
Redis coordination matters because a request may reach one instance while another executes the run. Sticky sessions alone do not solve that. Platforms without coding agents do not need AgentCore or S3 checkpoints.
Add Redis coordination
In the Render dashboard, create a Key Value instance in the same workspace and region as the API. Choose a paid plan with persistence and use its internal connection URL as REDIS_URL in the API environment.
Ask your coding agent to prepare the application:
Follow docs/scaling.md to prepare this platform for two Render API instances.
Keep one instance running while we configure and verify the shared services.
Add the Redis client dependency and regenerate requirements.txt using the
repository's dependency workflow. Set QueueConfig.redis from REDIS_URL,
keeping durable=True and the queue database in PostgreSQL.
Read AGENTOS_INTERNAL_SERVICE_TOKEN into AgentOS.internal_service_token.
Set stateless=True on the existing final MCPConfig in app/interfaces.py,
preserving its tools and authentication configuration.
Check shared database, JWT, MCP, scheduler, queue, and checkpoint settings.
Keep one Uvicorn worker per instance. Show the diff and verification plan.
Do not increase replicas or provision services yet.The existing constructor settings should include:
queue=QueueConfig(durable=True, db=db, redis=getenv("REDIS_URL")),
internal_service_token=getenv("AGENTOS_INTERNAL_SERVICE_TOKEN"),Generate one AGENTOS_INTERNAL_SERVICE_TOKEN and use the same value across replicas. This environment variable takes effect through the constructor argument above. Independently generated internal tokens cannot authenticate scheduler calls routed to another instance.
Keep AGENTOS_URL, JWT verification, MCP authentication, database connections, sandbox settings, and checkpoint bucket/prefix consistent. Use the same queue retry and lease settings. Account for the combined database connection pools of all instances.
Deploy before increasing replicas
Deploy the coordination changes with one instance first. Check API health, a normal agent run, scheduled work, and the MCP clients you use. Explicit stateless MCP removes legacy transport-session resumability and server-initiated requests; test connector behavior before proceeding.
When those checks pass, change the API service's numInstances to 2 in render.yaml, push it, and sync the Blueprint. Keep the same service URL and shared configuration. Two replicas also mean more compute and database connections.
Verify the whole path
Use per-instance logs to verify that submission and execution actually reach different instances. Check:
- A streamed run whose worker is on another instance.
- Cancellation and reconnecting to the run.
- Continuing a saved conversation.
- A scheduled briefing and a Company Task, without duplicate execution.
- Recovery after replacing an API instance during disposable test work.
Queue recovery and sandbox checkpoint recovery are separate checks. With the default max_attempts=1, a crashed run can fail visibly; additional attempts restart from the original input and can repeat external actions. Checkpoints recover saved coding state, not arbitrary live processes.
Test uploads and generated-file downloads as well. A checkpoint bucket does not automatically provide shared hosting for every file your agents produce.
Next
Work through Your platform is ready to check your deployment, review what runs automatically, and choose what to build next.