Closed voice platforms make you rent your own agents. Dograh is completely open source- nothing is gated. Visual flow builder, add your model key across 30+ integrations or use local models, telephony, human transfer, and advanced QA & monitoring - all free to self-host in one command. Also connect your claude code with MCP to build voice agents for a use case or call recordings.
Free
Launch Team / Built With
AWS Startup AdvisorPersonalized AWS guidance that meets you where you’re already building
Promoted
Vapi
Hey Product Hunt, I'm Pritesh, one of the makers of Dograh.
Dograh is an open source platform for building voice AI agents - calling agents that answer calls, book appointments, qualify leads, or run payment reminders over the phone.
Here's the problem we kept hitting. AI is getting locked up. Closed platforms make you rent your own agents on their cloud, at their price. And right now big labs are lobbying to restrict open source AI itself. We run on one belief: no company should own voice AI.
So from day 0 we open sourced every line. BSD-2 license, one command to install, nothing held back, nothing gated. Everything runs on your own server, and it's yours. You build phone agents and also own the whole stack.
That is the difference. There is no platform to rent here. No per-minute fee, no gated tier. Bring your own keys, or run local models completely offline, even air-gapped. And it's MCP native - connect Claude Code and build a voice agent by chatting with it.
Inside you still get everything the closed platforms sell:
Visual flow builder - no glue code
Real time speech to speech - 70+ languages with mid-call switching
Telephony + warm handoff to a human
Call recordings with automatic QA
Free REST API
Why that matters:
The payoff is ownership - your only cost is your model bill
Your data never leaves your servers - compliance gets simple
No glue code - you ship in hours
It fits developers and agencies building agents for clients or their internal use case, and compliance-heavy teams in healthcare, finance, and collections. Common uses today include appointment booking, lead qualification, support lines, payment reminders.
We are a small team. A star on GitHub or honest feedback here does more for us than you would think.
Install it, break it, tell me what's missing. I'm here all day.
But first, try a Dograh voice agent now.
@pritesh_kumar3 Love it
@digvijay_s Thanks for the support!
Thanks @digvijay_s :)
@pritesh_kumar3 All the best!! Will try and let you know the feedback
How is the latency handled for cascaded systems- for the TTFB - end to end (user stops and then heard the first chunk audio) from lets say one of the many api calls during a 10 turn conversion- 30 api calls to each endpoint - stt, llm , tts - if one of the api calls fails lets say turn 5, sst failed ( null or later then 500 ms response), how your framework is handling 1. Fallback model 2. Retry with same model ? Including edge cases for streaming response error for all the three nodes ( stt, llm , tts )
@kumar_gautam Thank you for your message.
These are some very relevant questions. We connect over Websocket for TTS and STT, so any failure over websocket connection is automatically retried. For LLMs, we have fallbacks in place, so that if our primary LLM takes longer to respond or fails to respond, there are fallback LLMs in place.
I welcome you to try out @Dograh
@kumar_gautam WebSocket failures for STT and TTS are retried automatically, while LLM timeouts or failures trigger fallback models.
@kumar_gautam thanks for the detailed question. Curious what end to end TTFB you're aiming for. if you're benchmarking us against something, I'd genuinely like to hear where we fall short.
It is exciting to see voice AI move toward open source. As these models scale, how are you approaching the challenge of real-time sentiment analysis and behavioral tracking for agents during live calls, and what metrics do you prioritize to measure conversational quality without compromising user privacy?
@lucianb - Thanks, and good question. Sentiment scores are easy to compute but hard to act on mid-call unless we have super robust orchestrator spanning multiple LLMs of different sizes and capabilities (something we are working on).
The signals that actually predict a bad conversation are structural and post call: how often the caller repeats themselves, how often they interrupt, how long the silence runs before they answer (dead air), whether they ask for a human and refuse to talk to the agent. We handle this using a native QA node in workflow builder and also integrate with solutions like Tuner, Noveum. On quality we hold one metric above the others: did the caller get what they called for. Everything else is a proxy for it.
Privacy is where open source does the real work. Self-hosted, the audio never leaves your infrastructure, so there is no third party to trust with it. You keep the derived signals and drop the recording.
@lucianb Hey Lucian, thanks for the question. We have an inbuilt QA node that you can run across 100% or a smaller sample of your live calls. The QA node has inbuilt functionality to do sentiment analysis or any custom analysis for your use case.
And since dograh is self hostable you can add a guardrail/mask layer to send PII anonymised data- though this might still need some plumbing and not available out of the box.
Hope this helps :)
@lucianb Thanks for the thoughtful question. We focus on practical call outcomes while giving teams control over how their data is processed, stored, and retained.
@lucianb appreciate the question. What would you actually do differently mid-call if you had real-time sentiment? curious what the action would be on your end.
Great launch team. Kudos!
In the meantime, Id love to know how to catch an agent that gives a bad response. And what does the debugging experience look like if we are tryin to figure out why. ?
@mayurmaheshwari - Thank you for your support.
You can use native QA node in Dograh or integrate with our partner services like Tuner, Noveum or Roark to catch a agent that is not doing its job properly and giving a bad response.
You can use chat mode on Dograh to debug and test an agent while building it.
We are always available on Slack to answer any questions you might have. :)
@mayurmaheshwari Use Dograh’s native QA node to flag bad responses, then test and debug the agent in chat mode.
@sandeep_vemu @abhishek Im actually going to try dograh
@mayurmaheshwari Great to hear! Let us know if you have any questions while trying it.
@mayurmaheshwari thanks for your comment!
On the debugging part of your question, tracing comes in handy. Every run has a trace that shows the exact prompt sent in that turn, what the transcriber actually heard, the active node, tools available vs. called.
Two things it usually surfaces. Either STT misheard and the model answered the wrong question perfectly, or it's the prompt. The trace shows the assembled global + node prompt, so clashing instructions, or the same behaviour specified in two places, become visible. Models get less reliable when instructions for one aspect are scattered rather than co-located. The Langfuse playground then lets you edit that exact prompt and re-run without placing another call.
You can read more here
Thanks@mayurmaheshwari . as suggested above , we have got QA node, Eval partnerships and tracing. And we are also adding persona simulations and pre configured evals in the coming days.
Congratulations on the launch! 🎉
If Dograh is fully open source and self-hostable, what’s the best way for an agency or developer to monetize voice agents they build for customers? Can they white-label the solution and charge their own customers?
@nihalkumar_dwivedi Yes, agencies and developers can white-label Dograh, deploy it for customers, and charge under their own pricing model.
@nihalkumar_dwivedi - Thank you for your message.
Yes, @Dograh comes with a very permissive licence that allows you to self host and white-label the solution and use it for commercial purposes.
You can also use our hosted platform as a headless API provider if you have smaller volume to start with and then move on to self host on your own infrastructure as the volume grows.
@nihalkumar_dwivedi One practical thing worth adding: because it's self-hosted, you can stand up an isolated deployment per client (on-prem or in their VPC) and brand it end to end. That's a real selling point for regulated customers - you can tell them their calls, recordings and transcripts never leave their own boundary, which is often what closes the deal at your own pricing.
@nihalkumar_dwivedi Yes, and self-hosting also gives agencies a strong story around privacy and control for their customers.
Congratulations on the launch @sabiha_khan4 ! Curious to know which major sectors you’re seeing initial traction in. Also, are there any limitations around regional languages or specific geographies?
@rahul_aluri - Thank you for your message.
We are seeing good traction in Legal Intakes (inbound and outbound), Car Rentals (inbound), Restaurant Booking (inbound) and Medical Insurance (outbound) sectors.
The limitations are mostly around declaring about robo call for automated calls. Supporting regional languages are more of a capability concern and using the right set of models behind the orchestrator.
All the very best with @Spur.fit
@rahul_aluri Thanks a lot for your comment. Love what you're doing at @Spur.fit.
Adding on the languages/geography part, since you bring your own models, you can pick the best STT/TTS/LLM per language (70+ supported) rather than being capped by a single vendor's coverage. Geographic reach depends on your telephony provider, and for data-residency-sensitive regions you can deploy in-region or in your own VPC via self-hosting.
Congrats on everything you've been shipping for the fitness coaching space!
@rahul_aluri We’re seeing traction in legal, restaurant booking, and medical insurance use cases. Regional language support depends on the STT, TTS, and LLM models you choose, while geographic coverage depends on your telephony provider.
Thanks @rahul_aluri . Early traction is spread across sales and support use cases; there are no major geography or regional-language limitations.
@pritesh_kumar3 @sandeep_vemu @a6kme1 love the mission behind creating wildly applicable open source offerings. Maybe its an odd question but I am curious - what is the pathway toward revenue generation - is the goal to primarily capture some big fish on the enterprise side? Anyways - killer launch - big fan of what you're doing - following the product / following along!
@dzaitzow - Thank you so much for the kind words.
We strongly believe that once Dograh is into consideration of every company in the world for their voice AI use case, revenue will be an organic side effect of that. The primary focus right now is to be able to create as much value as possible for our early believers and customers to cement our place in this industry and market.
Enterprise tickets are of course something thats super welcome and helps us bring the revenue numbers up, and some of very large enterprises (Bn $$+) have told us that they are self hosting Dograh for their use case.
great question @dzaitzow :D
We are believers in OSS and isn't that how the dev ecosystem should always be - open and accessible :)
For monetisation - we are walking the shoes of great oss project in the past. A bunch os companies use our cloud simply because they have the optionality to switch to Open source when required
@pritesh_kumar3 really neat!
@dzaitzow We monetize through managed cloud hosting, usage-based infrastructure, and enterprise support. Self-hosting remains fully open source, while larger teams can pay for convenience, scale, and hands-on help.
@dzaitzow thank you for your comment. The open source part is the bit we most want to get right, so good to hear it landing. Thanks for following along.
@sabiha_khan4 no stress - really interesting!