Dograh: a self-hosted voice agent platform you run with one Docker command

The bill and the data residency problem, not the feature list

Voice agent platforms such as Vapi and Retell are priced per minute and run in the vendor's cloud. That model fails in two specific situations. The first is a call volume where per-minute pricing becomes a line item somebody has to defend in a budget review. The second is a compliance constraint: recordings, transcripts and caller identifiers from a healthcare intake line or a financial collections flow cannot sit in a third party's storage without a data processing agreement and an audit trail. Dograh targets both. The README frames it as "the open-source, self-hostable alternative to Vapi & Retell", licensed BSD 2-Clause, and the comparison table it ships lists data residency as "your infra, your rules" and vendor lock-in as none. The intended user is a team with a Python-capable engineer and a server, not a solo operator who wants a hosted dashboard.

Workflow graph in, Pipecat pipeline out

The architecture has three layers. At the top is a visual workflow builder: you pick Inbound or Outbound, name the bot, and arrange the conversation as a graph. That graph is the artifact you edit, and it is also the artifact an AI coding assistant can edit, because Dograh exposes itself over MCP. That is the more unusual design decision here. Rather than treating the builder as the only interface, the project lets a Claude Code or Codex session create and modify workflows through a tool protocol, which means the workflow definition has to be machine-readable and stable enough for an external agent to manipulate. Below the builder sits the runtime, built on Pipecat, which appears as a pipecat entry at the repository root. Pipecat handles the streaming pipeline between audio in, speech recognition, the language model, and audio out. Dograh's contribution is the layer above: the graph, the node types, the telephony bridge, and the provider configuration. The third layer is the model stack, and this is where the BYOK claim gets concrete. The description says BYOK across speech-to-speech or LLM/STT/TTS, meaning you can either run a single end-to-end speech model or compose separate transcription, reasoning and synthesis providers. The README names Twilio, Vonage and Telnyx as examples of telephony keys you can connect.

One curl, one script, port 3010

The documented install is a single shell line that downloads a compose file and a startup script, then runs it. The README gives this exact command: curl -o docker-compose.yaml https://raw.githubusercontent.com/dograh-hq/dograh/main/docker-compose.yaml && curl -o start_docker.sh https://raw.githubusercontent.com/dograh-hq/dograh/main/scripts/start_docker.sh && chmod +x start_docker.sh && ./start_docker.sh. The README states that first startup may take two to three minutes while images download, and that the UI is then reachable at http://localhost:3010. Among the documented configuration keys, setting ENABLE_TELEMETRY=false before running the startup script opts out of anonymous usage collection, which the README says is on by default. There is also an agent-assisted path. The project publishes a plugin repository at dograh-hq/dograh-plugins, and the README shows the Claude Code commands /plugin marketplace add dograh-hq/dograh-plugins followed by /plugin install dograh@dograh, after which you ask the agent to set up Dograh or run /dograh-setup. The plugin is described as detecting your OS, choosing a deploy path, running Dograh's own setup scripts and verifying the result. Codex is listed as supported too. For remote servers, the README points to docs.dograh.com/deployment/docker rather than inlining the procedure, and a troubleshooting document lives at docs/getting-started/troubleshooting.mdx.

Where the one-command story stops

The compose file and start script are the easy part. The README says no API keys are needed for the quickstart, because Dograh ships with auto-generated keys and its own LLM, TTS and STT stack; connecting your own keys for LLM, TTS, STT or telephony is a separate step. Telephony is the sharper boundary. The README's first-bot walkthrough starts at the browser, with Test Audio and Test Chat, so you can build and talk to an agent before you have connected a phone number. Connecting a real number means attaching your own telephony keys (the README names Twilio, Vonage and Telnyx), and by default the quickstart opens a public *.trycloudflare.com quick tunnel to the API for inbound telephony webhooks. The second limitation is operational rather than technical: self-hosting moves the uptime problem to you. A dropped call at 2am is your pager, not a vendor's status page. The README's own comparison table lists self-hostable as a Dograh advantage, and it is, but only for teams already comfortable owning that.

Release cadence and what it implies for upgrades

The release list shows v1.48.0 on 2026-10-02, v1.49.0 on 2026-10-12, and v1.50.0 on 2026-10-31, with the last push to main on 2026-10-31. That is roughly a minor release every one to three weeks. For a self-hosted deployment this matters in a way it does not for SaaS. You are the one who decides when to pull, and you are the one who discovers that a workflow schema changed or a compose service was renamed. The project ships a start_docker.sh script rather than a migration tool. Anyone running Dograh in production should read the release notes for each version before pulling, and should keep the previous compose file so a rollback does not require reconstructing the environment. The BSD 2-Clause licence is permissive: it allows modification and redistribution with the copyright notice and disclaimer retained, and it does not impose a copyleft obligation on your own code. It also means no warranty, which is the standard trade for a permissive licence and worth stating plainly to whoever signs off on the deployment. This is a description of the licence text, not legal advice; have counsel review anything that touches regulated data.

Against Vapi and Retell, and against building it yourself

The obvious alternatives are the ones Dograh names. Vapi and Retell are proprietary, SaaS-only, and priced per minute. The difference is not feature parity, it is where the control boundary sits. With either, you configure within their integration list and their infrastructure. With Dograh, the comparison table claims "any provider" for LLM, STT and TTS, and source-level customization because every line is modifiable. That claim is only worth something if you actually intend to modify something. A team that self-hosts Dograh and then uses it exactly as it would use Retell has taken on the operational burden for none of the benefit. The more interesting comparison is against assembling Pipecat yourself. Pipecat is already the framework underneath, and a competent Python team could build a streaming voice pipeline on it directly. What Dograh adds on top is the visual graph editor, the MCP surface for agent-driven editing, the built-in telephony, and a UI for non-engineers to inspect and change call flows. If none of those four things matters to you, the framework alone is the smaller dependency. If your operations or support team needs to edit a call flow without opening an editor, the builder is the reason to take the whole platform.

Who this fits, and the three things to check first

Dograh fits teams with a compliance or cost reason to keep voice traffic on their own infrastructure and at least one engineer who is comfortable with Docker, Python and a telephony stack. It fits less well if you need a vendor to answer the phone when the platform breaks, or if your call volume is low enough that per-minute pricing is cheaper than the engineering hours self-hosting consumes. There is also a cloud option at app.dograh.com, which the README presents alongside the self-hosted path, so the project is not asking you to choose between open source and a managed service; you can evaluate on the hosted version and move. Before you commit to the self-hosted route, verify three things on your own hardware rather than trusting the quickstart: that the telephony provider you connect completes a real call in both directions, that your chosen STT and TTS endpoints respond fast enough from inside the container network that turn-taking does not feel broken, and that the workflow builder's node set expresses your call flow without custom code. If any of those three fails, the one-command install was never the hard part.

Editorial conclusion

Adopt Dograh if your voice agents handle data that cannot leave your network, or if per-minute SaaS pricing is the thing blocking a pilot, and you have someone who can read a docker-compose.yaml and a Python traceback. Do not adopt it if you want a managed SLA, a support contract, or a platform where the hard part (carrier relationships, model routing, latency tuning) is somebody else's job. Before committing, verify three things on your own hardware: that the telephony path you need is actually wired up, that your chosen STT and TTS providers are reachable from inside the container network with acceptable round-trip latency, and that the workflow builder's node set covers your call flow without you writing custom code. Dograh gives you the source; it does not give you the operations team.

Frequently asked questions

Official sources

1. dograh-hq/dograh on GitHub
2. License: BSD-2-Clause
3. Project website
4. README
5. Releases