Scaling & Postgres
Run more than one CLI sign-in server instance.
Connect your agent today
Draft from chat, review in your calendar, and publish only what you approve.
Overview
The CLI auth server is stateless at the process layer: device-flow state lives in Postgres (device_requests table, auto-created on startup — see Auth server architecture → Postgres state model). That means horizontal scaling is safe when every instance shares the same database and the same public configuration.
Multiple instances
You can run several replicas behind a load balancer (or on serverless concurrency) if they share:
- The same DATABASE_URL
- The same SERVER_URL (public origin users and OAuth redirects see)
- The same OAuth client OPENQUOK_OAUTH_CLIENT_ID / OPENQUOK_OAUTH_CLIENT_SECRET
Sticky sessions are not required — any instance can serve the next poll or browser request.
Serverless (Vercel) and Postgres
On Vercel, functions scale concurrently. Use a managed Postgres connection string suited to many short-lived connections (pooling — for example Neon, Supabase pooler, Vercel Postgres, or your provider’s serverless URL). Avoid a single non-pooled DSN that exhausts connection limits under burst traffic.