Shape
Current production deployments are classic VPS deployments:- CXB Core fleet servers run multiple systemd worker instances.
- nginx terminates public traffic and routes to Unix sockets.
- CXB API runs as a FastAPI service.
- CXB Console is built with Vite and served as static files.
- CXB Dialler runs as a separate long-running process.
- MongoDB, Redis, LiveKit, and object storage are external runtime dependencies.
Strengths
- Cheap to run on small VPSs.
- Easy to reason about host-by-host.
- One call per worker is enforced at nginx and application level.
- Zero code changes needed to add a fleet server; add URL in CXB API settings.
- Failures are mostly isolated to a worker or host.
Weaknesses
- Deployment uses
rsync, systemd, and manual nginx edits. - Worker count changes require nginx config edits and service management.
- Fleet capacity discovery is URL-list based.
- Logs and metrics are distributed across servers.
- Rollback is manual.
- Large fleets become operationally heavy.
Non-negotiable production details
| Detail | Why it matters |
|---|---|
MAX_CONCURRENT_CALLS=1 | Preserves one-call-per-worker isolation. |
nginx max_conns=1 | Prevents a busy worker from receiving another WebSocket/call start. |
map $http_upgrade | Required so WebSockets and HTTP POST dialout both work. Hardcoded Connection "upgrade" breaks POST dialout. |
CXBCORE_WORKERS matches actual workers | Health endpoint capacity is derived from this. |
| Shared object storage where possible | Playback breaks when recordings live only on the originating fleet host. |
| Result and Agent Desk outboxes are persistent | Prevents transient CXB API failures from losing results or handoffs. |