We just launched @Dograh , the open-source alternative to Retell and Vapi for building voice agents.
Self-hostable, so you own your stack and your data.
We started it out of rage - every tool was too expensive, too closed, or scammy (addon after addons).
So we open-sourced every line from day 0, on one belief: no company should own voice AI.
Big labs are lobbying with govts to ban open source.
More open source is how we fight back.
I am building a voice agent for lead qualification usecase for a friend's business who is running his home interiors company. I am completely new to dev ops like self hosting as well as building voice agents. So far, the MCP tools have been really powerful. I had a voice agent ready in 2 days that we went live with. We are iterating of course as we call more leads but the I think building with MCP tools was really efficient for someone like me. Really appreciate what you guys have built. I love that Dograh is open source and rhat I can self host it. I have found the support from founder prompt and really helpful in the early days of my agent building.
I would like a playbook for working on prompts. The MCP tool pretty much built the entire agent for me - the node splitting, prompt structure as well as tools i need to link with my agent nodes. But I have found making minor tweaks in the production agent difficult. If theres a standard convention to do that it will really help. A lot my minor changes in the nodes, especially the global node, have broken something which was working before.
Elevenlabs
Thank you @elias_shaik . Your review made our day. Being new to self-hosting and voice agents and going live with a lead-qualifying agent in 2 days is a great outcome.
Your point on iteration is well taken, and it's the thing we hear most: the MCP tools nail the initial build, but we haven't given you a convention for safely tweaking an agent that's already in production. A prompt playbook on what belongs in the global node vs. a task node, plus a safe-edit checklist for live agents is on our roadmap because of feedback like this.
Quick tip meanwhile — keep the global node to persona, conversation style, tone and universal guardrails mostly. When it's included in an agent node (the default), the system prompt is the global prompt followed by the node's own, in that order so anything step-specific in the global node reaches every node. Watch for the same aspect of behaviour being specified in more than one places: these shouldn't contradict, and each aspect is best kept in one place. That collision is the most common source of "this used to work."
Happy to jump on a call and understand the edits you've found risky; those are exactly what should shape the playbook.
Thanks @elias_shaik ! Great to see you going live in just 2 days - and the prompt playbook feedback is super useful.
Came across this while looking for some self hosted alternative to Vapi and gave it a spin over the weekend. Had a basic agent running in no time, and the fact that it's open source and runs on my own setup is the big win for me. Nice to see a tool like this out in the open.
Took some poking around to figure a few things out. More examples or a starter template or two would help someone getting going for the first time.
Vapi is solid but it's a hosted service, so you're renting the infra and everything runs through their platform. Dograh being self hosted meant I could just run it on my own setup and keep things in my control. The open source part sealed it for me.
Thank you @ritesh2503 for your review. Great to hear that you were able to get started with your use case in no time.
We hear your feedback on providing some starter templates to make the onboarding journey simpler.
Thanks for your review. Really appreciate the feedback. Getting started super quick has always been our priority be it one command self hosted deployment or MCP tool for designing a production grade agent. We are constantly looking to improve a developer's/builder's first experience.
Although we have an ai agent builder that creates a rough outline of the agent with basic requirement input, adding more starter templates is a great idea. Its in our roadmap.
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
@pritesh_kumar3 70+ languages with mid-call switching is a thoughtful feature, especially for real-world phone conversations.
@julian_ting2 Thanks, Julian. Mid-call language switching makes multilingual conversations much more natural.
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 :)
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.
@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
@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.
Vapi
Dograh
Thanks for the detailed feedback, Elias. A prompt-editing playbook with conventions for safely updating nodes, especially the global node, would be valuable. We’ll use this feedback to improve the production iteration experience.