Deploy#

Run the FastAPI runtime, Next.js dashboard and PostgreSQL as supervised containers behind an HTTPS reverse proxy. Use one runtime instance for active call handling. SQLite remains available for local evaluation; the current production Compose deployment uses PostgreSQL 18.

Before you start#

• A Linux host with Docker and Compose 2.30 or newer.
• A DNS name, valid HTTPS certificate and restricted service ports.
• Production Telnyx and voice-provider credentials.
• Unique authentication, session, media-signing and database secrets.
• Durable PostgreSQL storage and an encrypted off-host backup destination.
• A pinned, reviewed source revision and a database-compatible rollback plan.

Prepare the deployment#

1. Review the supplied compose.yaml for your host. Its env-file locations, interface bindings and public origins are deployment-specific; adapt them before starting services. Keep PostgreSQL unexposed to the public network.

2. Store runtime, dashboard and PostgreSQL environment files outside the release directory with access restricted to the deployment account. Raw env-file parsing requires Compose 2.30 or newer.

3. Set the runtime DATABASE_URL to the PostgreSQL service with the intended database and credentials. Leave Phase 1 shadow-database and dual-write settings disabled unless you are explicitly exercising that migration path.

4. Set the final public origin and the dashboard's internal runtime URL. Supply the same runtime API token to both services.

5. Validate the deployment without printing resolved secrets:

   Copy

   docker compose config --quiet
   docker compose build
   docker compose up -d --wait --wait-timeout 240
   docker compose ps

The persistent database volume survives ordinary container replacement. Warning: docker compose down -v deletes that volume and must not be used for routine deployment.

Configure HTTPS and carrier traffic#

Route dashboard requests to the web service and Telnyx callbacks and media WebSockets to the runtime. Restrict direct runtime operator APIs with the runtime token. The browser uses the dashboard's authenticated runtime proxy.

The runtime rejects oversized HTTP requests according to MAX_REQUEST_BODY_BYTES; keep an equivalent or stricter proxy limit. Keep fake providers and development authentication bypasses disabled.

Check dashboard /api/health and runtime /api/ready before routing live Telnyx traffic. Readiness includes database reachability and schema checks. Deployment does not enable carrier mutation, browser-phone, queue, voicemail or recording gates; configure and accept each capability separately.

Upgrade and recover#

Back up the database before applying a new revision. A failed deployment may already have changed containers or applied migrations even if the release pointer still names the previous version. Inspect readiness and migration state before rebuilding the previous release; confirm schema compatibility first. The former Railway deployment is retired, so use the current Compose topology for new installations and database operations.

Verify#

1. Confirm PostgreSQL, runtime and web containers are healthy.
2. Check dashboard /api/health and runtime /api/ready through their intended proxy routes.
3. Sign in and verify an unauthenticated operator API request is refused.
4. Check that all unapproved phone and recording gates remain disabled.
5. Complete the live line acceptance check on a controlled line before putting the receptionist into service.
6. Restore a backup in a disposable environment with telephony disabled.

If it does not work#