Scaling & Postgres
Run multiple CLI auth server instances—shared DATABASE_URL and SERVER_URL, no sticky sessions, and pooled Postgres on Vercel.
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.