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.
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.
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 :)
This is a great direction for voice AI!
Do you have better support for multi-step conversations as well?
@ankushkun Thank you for your query. We actually have first class support for multi step conversation. When the entire industry was doing one monolithic prompt for voice agent, we and few others (like Bland) were doing natively multi node agents which broke a big monolithic prompt in multi step conversation.
This was specially challenging with models like Gemini Realtime which does not allow updating agent prompt in between conversation, but we figure out some hacks which allows our multi step conversation to work well with them (reconnecting with context playback and compaction).
Hi @ankushkun we support multi step conversations extensively.
Infact with Dograh you can build multi-step conversations for real time/speech-to-speech models as well (apart form cascade)
@ankushkun Yes, Dograh supports multi-step conversations and customizable workflows for different use cases.
@ankushkunAdding to this, each step is its own node, so you can branch on the caller's response and call APIs mid-flow.
The part that makes it genuinely better to build with: test it as a text chat instead of dialing in each time, edit any message on the fly to see the LLM's generation and refine your prompt right there, and add a QA node to auto-check each step. Iterating on complex flows gets much faster.
THanks you for all the replies, that's amazing!!
@ankitnayan - Thanks for your comment. Speech to speech are excellent models which offer language switching and lower latency. Many labs are working on Speech to Speech models, like @Google (Gemini Live), @OpenAI (OpenAI Live), @Grok (Grok AI) etc. @Dograh support these and many more.
The only challenge currently is that you cant use custom cloned voice with them, and the tool calling can sometimes be a bit unpredictable. However, we are seeing some very rapid progress in the space and these are bound to improve in short term.
@ankitnayan Mostly control. Speech-to-speech is faster and handles language switching well, but you currently give up custom cloned voices and some predictability around tool calls. The gap is closing quickly, though.
@ankitnayan While we have seen S2S win on latency and 'humanness'. Having said that tool calling and instruction following is not upto mark with LLM's in cascade approach. However with
@Dograh we ship the ability to break S2S stream accross multiple agents instead of 1 end to end stream and thus give you minute control over your instructions - shorter context and minimal instruciton following - thus enabling premium grade performance with S2S models.
We will be weleasing benchmarks soon . Keep an eye out :)
@ankitnayan one addition - with s2s you also lose per-stage visibility. with a cascaded setup you can trace STT/LLM/TTS separately when something goes wrong, with S2S its one end-to-end model, so debugging a bad response gets harder.
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.
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.
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.