Dograh Review 2026: Open-Source Voice AI Agents

What Dograh is in 2026

Dograh is an open-source voice AI platform. The repository at github.com/dograh-hq/dograh shows 5,860 stars, and the project positions itself as a self-hosted alternative to Vapi and Retell. The pitch is straightforward: you run the voice agent stack on your own infrastructure, bring your own keys for speech-to-text, language model, and text-to-speech providers, and pay providers directly instead of paying a platform markup on every minute.

The architecture follows the pattern most voice agent frameworks settled on by 2026. Audio comes in from a telephony provider over a websocket, gets streamed to an STT engine, the transcript goes to an LLM with a system prompt and any tool definitions, the response text goes to a TTS engine, and the synthesized audio streams back out. Dograh's job is orchestrating that pipeline: managing the websocket session, handling turn boundaries, calling tools, and keeping the conversation state coherent across the exchange.

What makes the wiring interesting is that each stage is pluggable. The docs describe support for multiple STT providers, multiple LLM backends, and multiple TTS engines, with the expectation that you supply API keys for whichever ones you pick. That means the quality ceiling of any given deployment depends heavily on which combination you choose. A Deepgram plus GPT plus ElevenLabs stack sounds very different from a Whisper plus open-weight model plus Piper stack, and the cost difference between those two is enormous.

Deployment shape is Docker-based. The repository ships a compose file that brings up the application, a database, and whatever supporting services the pipeline needs. There is also a hosted option at dograh.com, with pricing starting at $5/mo according to the pricing page. That hosted tier is cheap enough that it reads more like a way to try the product than a serious production plan, and the real value proposition sits with self-hosting.

The license matters here. Open-source voice agent platforms vary wildly in what "open source" actually means — some are source-available with commercial restrictions, some are fully permissive. Anyone evaluating Dograh for a commercial deployment should read the license file in the repository directly rather than trusting a summary, because the difference between Apache 2.0 and a Business Source License is the difference between building a product on it and not.

Install: Docker, keys, first agent under 30 minutes

The install path the docs describe is: clone the repository, copy the environment template, fill in provider keys, run docker compose up, and open the local UI. The environment variables break down into a few groups. There is database connection config, there is a set of provider credentials for STT, LLM, and TTS, and there is telephony config for whatever carrier or SIP trunk you are connecting.

Provider keys are the first real decision point. If you are using OpenAI for the LLM stage, you need an OpenAI key. If you are using Deepgram for STT, you need a Deepgram key. The TTS provider needs its own key. Dograh does not bundle any of these, which is the point of BYOK — you are not paying a platform markup, but you are also responsible for managing three separate provider accounts, three separate billing relationships, and three separate sets of rate limits.

Telephony is where most first-time setups stall. You need a phone number that can route audio to your Dograh instance. The common path is a Twilio or Telnyx number pointed at a websocket endpoint, or a SIP trunk if you are bringing your own carrier. The docs cover the Twilio path in more detail than the others, which is a reasonable default given Twilio's market position, but it does mean that if you are on Telnyx or a smaller carrier you will be translating the instructions.

Getting to a working agent in under 30 minutes is realistic if you already have provider accounts and a phone number. It is not realistic if you are starting from zero, because account creation, key generation, and number provisioning each add friction. The compose file does most of the heavy lifting on the infrastructure side, so the time sink is credentials and telephony rather than the application itself.

One thing worth checking before you commit: the compose file assumes certain ports are free and certain volumes are writable. On a machine that already runs other services, port conflicts are the most common first-run failure. The docs mention the default ports, so adjusting them is a config change rather than a code change.

Latency: STT to LLM to TTS round trip

Latency is the whole game in voice agents. A human conversation tolerates roughly 200 to 300 milliseconds of silence before it starts feeling wrong, and anything past 500 milliseconds reads as the agent being slow or broken. The end-to-end budget has to cover STT finalization, LLM time-to-first-token, TTS time-to-first-byte, and network transit in both directions.

Dograh does not publish per-stage latency numbers in the repository or the docs, and this review will not invent any. What can be said is structural: the pipeline is streaming, which means the LLM does not need to finish its full response before TTS starts. If the implementation streams tokens from the LLM into the TTS engine and streams audio out as it is synthesized, the perceived latency is dominated by time-to-first-token plus time-to-first-audio rather than total generation time. That is the difference between a responsive agent and a laggy one, and it is the single most important architectural property to verify in the code.

Provider choice dominates the numbers you will actually see. A fast hosted LLM with a low time-to-first-token matters more than raw throughput for this workload, because responses are short. On the STT side, streaming engines that emit partial transcripts let the system detect end-of-turn earlier. On the TTS side, engines that support streaming synthesis cut the first-audio delay substantially compared to engines that synthesize a full utterance before playing it.

Barge-in handling is the other half of the latency story. When the caller interrupts, the agent needs to stop speaking immediately, discard the in-flight TTS audio, and start listening. If the implementation waits for the current utterance to finish before yielding, interruptions feel broken. The repository shows handling for interruption events in the session layer, and the docs describe barge-in as a supported behavior, but the quality of the implementation is something you would need to measure on your own deployment with your own providers.

Where self-hosting helps latency is network proximity. If your Dograh instance runs in the same region as your telephony provider's media servers and your LLM provider's endpoints, you shave transit time that a hosted platform cannot always optimize for your specific geography. Where it hurts is that you now own the tuning. A hosted platform has already picked providers and tuned the pipeline; you are starting from defaults.

Voice quality and turn-taking

Voice quality in Dograh is entirely a function of the TTS engine you plug in. The platform does not synthesize speech itself. If you wire in a high-end neural TTS provider, the output sounds like that provider. If you wire in an open-weight local model, it sounds like that model. This is worth stating plainly because reviews of voice platforms often conflate platform quality with provider quality, and with a BYOK architecture the distinction is total.

Turn-taking is where the platform's own engineering shows. Detecting when a caller has finished speaking is harder than it sounds. People pause mid-sentence, they say "um" while thinking, and they sometimes trail off without a clear endpoint. A fixed silence threshold either cuts people off or makes the agent feel sluggish. The better implementations use a combination of silence duration, semantic completeness signals from the STT partials, and sometimes a dedicated turn-detection model.

The docs describe configurable silence detection, which suggests the threshold is tunable rather than hardcoded. That matters because the right value depends on your callers. A support line for elderly users needs a longer patience window than a scheduling bot for a fast-moving sales team. Being able to adjust this without forking the code is a real advantage of self-hosting.

Accent handling is downstream of STT accuracy, not something Dograh controls. If your STT provider struggles with a particular accent, the transcript degrades, the LLM responds to a garbled input, and the conversation falls apart. The mitigation is provider selection and possibly a custom vocabulary or keyword boost list, which most commercial STT engines support. Dograh's role is passing audio through cleanly, and the repository shows the audio path is a straight stream rather than something that resamples or compresses in a lossy way.

Naturalness grading is subjective and provider-dependent, so any specific score would be meaningless without naming the exact STT, LLM, and TTS combination and the exact audio conditions. What is fair to say is that the platform does not appear to add artifacts of its own. The audio in is the audio the STT engine sees, and the audio out is the audio the TTS engine produced.

Cost: self-host versus Vapi, Retell, and Bland

This is the section that decides whether Dograh is worth your time. The per-minute pricing of hosted voice platforms bundles STT, LLM, TTS, telephony, and orchestration into one number. Self-hosting unbundles all of it, which means the comparison is not one number against another but a sum of parts against a bundled rate.

Start with telephony. Twilio and Telnyx both charge inbound and outbound per-minute rates that vary by destination. For US domestic calls, the rates are low enough that telephony is rarely the dominant cost, but for international destinations it can be. You also pay for the phone number itself, usually a small monthly fee per number.

Then STT. Commercial streaming engines charge per minute of audio, and the rate depends on the engine and whether you are using features like diarization or custom vocabulary. Open-weight STT running on your own GPU has no per-minute cost but requires GPU capacity, which brings its own math.

Then the LLM. This is where the pricing snapshot matters. If you are running a premium reasoning model like openai/o1-pro at $150 per million input tokens and $600 per million output tokens, a chatty voice agent will burn through budget fast. A mid-tier model at $30 per million input and $60 per million output is roughly an order of magnitude cheaper. For voice agents, where responses are short and the context is a rolling conversation, a fast mid-tier model is usually the right call — the reasoning-heavy models are overkill and their latency is worse.

Then TTS. Per-character or per-minute pricing varies widely. Premium neural voices cost meaningfully more than standard ones, and the difference shows up in the bill at volume.

Then infrastructure. If you self-host on a CPU-only box, you can run the orchestration layer cheaply, but any local STT or TTS model needs GPU. Renting a GPU by the hour is straightforward but the cost is fixed whether you are serving calls or not, which means low-volume deployments pay a premium per call and high-volume deployments amortize it well. This is the core of the break-even question.

At low call volume — say a few hundred minutes a month — the fixed cost of GPU rental plus the engineering time to maintain the deployment almost certainly exceeds what you would pay Vapi, Retell, or Bland at their per-minute rates. The hosted platforms win on total cost of ownership until volume is high enough to amortize the fixed costs. At high volume — tens of thousands of minutes a month and up — the per-minute markup a hosted platform charges starts to dwarf the fixed infrastructure cost, and self-hosting wins clearly.

The exact break-even point depends on which providers you pick, which hosted platform you compare against, and how much you value your own engineering time. Anyone serious about the decision should build a spreadsheet with their actual expected minutes, their actual provider choices, and the current published rates from each hosted platform. The pricing pages change, and a comparison built on last year's numbers is worthless.

One honest note on Beetlix: Beetlix is our own product, and it sits in the same general space of AI tooling, but it is not a voice agent platform, so there is no meaningful head-to-head here. If you are evaluating voice infrastructure specifically, Dograh and the hosted platforms are the relevant comparison set.

Production gaps: scaling, observability, compliance

Open-source voice platforms tend to be strong on the demo path and thin on the production path, and Dograh is no exception in the areas where the docs are quiet.

Scaling is the first gap. A single instance handling one call is easy. A single instance handling fifty concurrent calls depends on how the session layer is implemented, whether state is in memory or in a shared store, and whether the pipeline is async throughout. The repository shows a containerized deployment, which suggests horizontal scaling is the intended path, but running multiple instances behind a load balancer requires sticky sessions or a shared session store, and the docs do not spell out which. Anyone planning for concurrency beyond a handful of simultaneous calls should read the session handling code before committing.

Observability is the second gap. Voice agents fail in ways that are hard to debug after the fact — a turn gets dropped, the agent talks over the caller, a tool call returns something unexpected. Good production deployments need per-call transcripts, per-stage timing, and structured logs that let you reconstruct what happened. The repository shows logging infrastructure, but the depth of what is captured and how easy it is to query is something you would need to assess against your own operational requirements. If you are used to a hosted platform's built-in call analytics, expect to build more of that yourself.

Compliance is the third and most serious gap. Voice calls involving real people trigger a stack of obligations: consent to record, retention limits on recordings and transcripts, data residency rules for where audio and text are stored, and in some jurisdictions disclosure requirements at the start of the call. Self-hosting gives you control over where data lives, which is a genuine advantage for regulated industries, but it also means you own every one of those obligations. A hosted platform often provides compliance features and documentation as part of the product; with Dograh you are implementing them.

PII handling deserves specific attention. Transcripts contain whatever the caller said, which frequently includes names, addresses, account numbers, and health information. If you are storing transcripts, you need a retention policy, an access control model, and probably redaction. None of that is free, and none of it is automatic.

Verdict: self-host Dograh or pay per minute

Dograh is a credible open-source voice agent platform with a real repository, a Docker deployment path, and a BYOK architecture that gives you full control over quality and cost. The 5,860 stars on the repository suggest meaningful adoption, and the $5/mo hosted tier makes it cheap to see the product before committing to self-hosting.

The decision comes down to volume and control. If you are running a few hundred minutes a month, pay a hosted platform and move on — the fixed costs and operational burden of self-hosting will not pay back. If you are running tens of thousands of minutes a month, or if you have data residency or compliance requirements that rule out a hosted platform, self-hosting Dograh is worth the engineering investment. The break-even sits somewhere in between and depends on your provider choices.

Recommended stack for a self-hosted deployment: a streaming commercial STT engine for accuracy, a fast mid-tier LLM rather than a premium reasoning model because voice responses are short and latency matters more than depth, a streaming neural TTS provider for naturalness, and Twilio or Telnyx for telephony. Run it in a region close to your providers, instrument the pipeline before you go live, and build the compliance layer before you take a single real call.

How this review was researched

This review is based on the Dograh repository at github.com/dograh-hq/dograh, the vendor documentation at dograh.com, the published pricing page, and the live AI model pricing data used for the cost analysis. No hands-on testing was performed. Latency, voice quality, and concurrency figures are not published by the vendor and are not estimated here; anyone making a deployment decision should measure those on their own infrastructure with their own provider choices.