Dograh: a self-hosted voice agent platform you run with one Docker command
Open source voice AI platform. Self-hosted alternative to Vapi and Retell. On Prem, BYOK across Speech to Speech or LLM/STT/TTS, with a visual workflow builder, MCP native and telephony support.
At a glance
- What is it?
- Dograh is a BSD-2-Clause Python platform for building inbound and outbound voice agents on your own infrastructure, with a visual workflow builder, bring-your-own model providers, MCP integration and telephony support. The interesting question is not whether it works but where the self-hosted boundary actually sits.
- Who is it for?
- 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.
- Can I use it commercially?
- Yes. BSD-2-Clause is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
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. The repository topics include on-prem-voice-agent-platform and local-llm, which is a fair signal of who this is aimed at.
Workflow graph in, Pipecat pipeline out
The architecture visible in the material 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, the Python framework listed in the repository topics. 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. Telephony is handled through Asterisk ARI, per the asterisk-ari topic, which is what makes inbound and outbound PSTN calls possible without a proprietary media gateway.
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. One configuration key is documented explicitly: 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. What the README does not enumerate is the credential surface behind BYOK. If you run the LLM/STT/TTS path, you are supplying keys or endpoints for each of those three roles, and if you run speech-to-speech you are supplying one. Those are not in the quickstart, which is reasonable (nobody wants API keys in a README) but does mean the sixty-second claim covers the install and not the configuration. Telephony is the sharper boundary. Asterisk ARI is the integration point, and the README's first-bot walkthrough starts at the browser, which suggests you can build and talk to an agent through the web interface before you have connected a phone number. Connecting a real inbound or outbound number means running or reaching an Asterisk instance and getting the ARI credentials right. Teams that assume telephony is bundled the way it is in a SaaS product will be surprised. 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.44.0 on 2026-08-01, v1.45.0 on 2026-08-11, and v1.46.0 on 2026-09-03, with the last push to main on 2026-09-09. That is roughly a minor release every two to four 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, and the material does not describe an upgrade procedure or a database migration story. 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 Asterisk ARI telephony bridge, 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 Asterisk ARI path to your carrier or SIP trunk 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.
Community notes