
Deploy Dograh Voice Platform
Voice AI agents, visual workflow builder, telephony. Vapi alternative
Just deployed
redis
Just deployed
Just deployed
Just deployed
/data
Just deployed
/var/lib/postgresql/data
Deploy and Host Dograh on Railway
Dograh is an open source voice AI agent platform. You build agents in a visual workflow editor, connect your own speech and language model accounts, and answer or place phone calls through a carrier you supply. It is a self-hosted stand-in for hosted services like Vapi and Retell, with your data and your provider keys staying on infrastructure you control.
About Hosting Dograh
This template runs Dograh as five services: the web app, the backend, a PostgreSQL database with vector search, Redis for background jobs, and an S3-compatible store for call recordings. The backend container also runs the database migrations and the background job worker, matching how the project ships it upstream.
Everything is wired together on deploy. Passwords are generated fresh for each deployment and there are no questions to answer before it starts. Model provider keys are entered inside the app after you create your account, so they are never stored as Railway variables.
Pinned to release dograh-v1.45.0 from 11 August 2026, using the images the
project publishes itself. No source builds.
Common Use Cases
- Run inbound voice agents that answer a business phone number
- Run outbound calling campaigns from a list of contacts you own
- Build and test call flows in the visual editor before putting them live
- Keep call recordings, transcripts and customer data on your own infrastructure rather than a hosted vendor's
Dependencies for Dograh Hosting
- A phone carrier account if you want real calls. Twilio, Telnyx, Plivo, Vonage, Vobiz and Cloudonix all connect over a websocket media stream and work here. You bring the account and pay the carrier directly.
- Provider accounts for speech to text, text to speech, and a language model. Dograh is bring-your-own-key across all of them.
- Nothing else. The database, job queue and recording storage are all included.
Deployment Dependencies
| Service | Image | Port | Volume |
|---|---|---|---|
| ui | dograhai/dograh-ui:1.45.0 | 3010 | none |
| api | dograhai/dograh-api:1.45.0 | 8000 | none |
| postgres | pgvector/pgvector:0.8.2-pg17-trixie | 5432 | /var/lib/postgresql/data |
| redis | redis:7.4.2 | 6379 | none |
| minio | minio/minio:RELEASE.2025-06-13T11-33-47Z | 9000 | /data |
Upstream project: https://github.com/dograh-hq/dograh Documentation: https://docs.dograh.com
Implementation Details
Getting started. Open the ui service's URL once the deploy finishes. First
boot takes about two minutes while the database initialises. Create your account,
then set ENABLE_SIGNUP to false on the api service and redeploy it so
nobody else can register. Add your provider keys in the app's settings screen.
Call recordings are kept private. The project's bundled storage class makes the recordings bucket anonymously readable, writable and deletable every time it starts, which its own code comment flags as unsuitable for production. Since browsers fetch recordings directly, that storage service has to be reachable on the public internet here, so left alone that setting would expose every recording to anyone who guessed the address. This template routes the app through its generic S3 storage path instead, aimed at the same bundled storage service. That path issues signed, expiring links and never alters bucket permissions. Verified on a clean deploy: unauthenticated requests to the bucket are refused, while the app's own uploads and playback work.
Correct handling of the proxy. FORWARDED_ALLOW_IPS is set so the backend
trusts Railway's edge and rebuilds its own public https address correctly.
Carriers sign the public address they called, so without this every inbound
webhook signature check fails.
What is not included. A self-hosted Asterisk phone system cannot run here, because it needs SIP and RTP over raw UDP and Railway carries only HTTP and TCP. That bridge is switched off deliberately. Websocket carriers are unaffected and are the supported path. There is also no relay server for browser-based test calls, which is upstream's own default; browser calls work on most networks but can fail behind strict corporate firewalls.
Your legal responsibility. Dograh includes a bulk outbound calling runner. Automated calling is regulated almost everywhere, and consent, calling hours, do-not-call lists and disclosure of an artificial voice are all down to you as the operator, alongside your carrier's acceptable use terms. This template ships no phone credentials and places no calls by itself.
Scaling up. Raise FASTAPI_WORKERS and ARQ_WORKERS on the api service
and give it more memory. If you run a second copy of the backend, set
ENABLE_CAMPAIGN_ORCHESTRATOR=false on it, or two campaign runners will dial
the same list twice.
Using storage elsewhere. Point S3_ENDPOINT_URL, AWS_ACCESS_KEY_ID,
AWS_SECRET_ACCESS_KEY, S3_BUCKET and S3_REGION at any S3-compatible
provider and delete the minio service.
Tightening call security later. TELEPHONY_WS_TOKEN_SECRET is set, so the
media connection URL is signed and checked, with failures logged rather than
blocked. Once your calls are working, set TELEPHONY_WS_TOKEN_ENFORCE to true
to reject unsigned connections. That two-step order is the project's own
recommendation.
Why Deploy Dograh on Railway?
Railway gives each service its own TLS domain and a private network between them, which removes the reverse proxy, the certificate setup and the tunnel that a single-server install of Dograh normally needs. The database, job queue and recording storage come up alongside the app with their credentials already wired, and the volumes keep your data across restarts and redeploys.
Because everything is described as a template, the whole stack is reproducible: redeploying gives you the same five services on the same pinned image versions, and scaling the backend or swapping in external object storage is a variable change rather than a server rebuild.
Template Content
