58cc9c8b1c
* fix(web): honor X-Forwarded-Proto in uvicorn so request.url is https behind a reverse proxy ## Problem When Dograh runs behind a TLS-terminating reverse proxy (Cloudflare → Traefik in Kubernetes, nginx in the docker-compose install), the inside of the cluster/host is plain HTTP. Uvicorn defaults to trusting `scope["scheme"]` from the socket, so `request.url.scheme` reads `http` even though the client dialed `https`. That breaks any code path that hashes or echoes the request URL back to the caller. Concrete symptom seen in production: **Vobiz inbound webhook signatures fail with "signature validation failed for vobiz"** because Vobiz computes HMAC over the URL it dialed (`https://.../inbound/run`) while Dograh recomputes it as `http://...`. Log excerpt from the failing call: ``` WARNING | provider.py | Vobiz webhook signature mismatch. Expected: daOpAZPm..., Got: 1+eW/RxE... WARNING | telephony.py | /inbound/run: signature validation failed for vobiz ``` Twilio, Plivo and any other provider that signs over the callback URL have the same failure mode when Dograh is deployed behind a proxy. ## Fix Start uvicorn with `--proxy-headers --forwarded-allow-ips="*"` in `scripts/run_web.sh`. Uvicorn rewrites `scope["scheme"]` and client address from `X-Forwarded-Proto` / `X-Forwarded-For` when the request originates from a trusted upstream — Traefik and Cloudflare set both correctly, so `request.url.scheme == "https"` inside the app once again and provider signature checks pass. Verified end-to-end on a production k3s install (Traefik + Cloudflare edge → dograh-web pod) — after the change, the very next Vobiz inbound webhook validated successfully and the call connected past the previous 11-second signature-failure hangup. * address review: let operators narrow FORWARDED_ALLOW_IPS Both bot reviewers on #515 flagged `--forwarded-allow-ips="*"` as a defence-in-depth concern: if uvicorn is directly reachable from an untrusted network (bypassing the proxy), any client can spoof `X-Forwarded-Proto` / `X-Forwarded-For`, and uvicorn will rewrite `request.client` / `request.url` from those attacker-controlled headers. Fix: consume `FORWARDED_ALLOW_IPS` from the environment (uvicorn already recognizes this env var; see `deploy/hostinger/docker-compose.yaml:179` for the existing precedent). Default stays `"*"` so the behavior of the original fix is preserved for the standard docker-compose / helm layouts where the app pod is only reachable via the proxy Service. Operators who terminate uvicorn on a host that's also reachable directly can narrow it to the proxy CIDR: FORWARDED_ALLOW_IPS="10.42.0.0/16" ./scripts/run_web.sh * address review: declare FORWARDED_ALLOW_IPS in the helm chart, not the script uvicorn already enables proxy-header handling by default and falls back to the FORWARDED_ALLOW_IPS env var when --forwarded-allow-ips is absent, so the CLI flags were redundant and the script-level "*" default hid a security-relevant trust decision away from operators. Drop the flags, keep run_web.sh deployment-agnostic, and declare the env var where the other deployment config lives — web.forwardedAllowIps in values.yaml (default "*", narrowable to a proxy CIDR) — mirroring how docker-compose already sets it on the api service. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * simplify run_web.sh comment Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: prabhat pankaj <prabhatiitbhu@gmail.com> Co-authored-by: Abhishek Kumar <abhishek@a6k.me> Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|---|---|---|
| .agents/skills | ||
| .devcontainer | ||
| .github | ||
| .vscode | ||
| api | ||
| config/coturn | ||
| deploy | ||
| docs | ||
| evals | ||
| examples | ||
| nginx | ||
| pipecat@aadd1d5dd6 | ||
| scripts | ||
| sdk | ||
| ui | ||
| .dockerignore | ||
| .gitignore | ||
| .gitmodules | ||
| .nvmrc | ||
| .python-version | ||
| .release-please-manifest.json | ||
| AGENTS.md | ||
| CHANGELOG.md | ||
| CLAUDE.md | ||
| CONTRIBUTING.md | ||
| docker-compose-local.yaml | ||
| docker-compose.yaml | ||
| LICENSE | ||
| README.ja-JP.md | ||
| README.md | ||
| README.zh-CN.md | ||
| release-please-config.json | ||
| remote_up.sh | ||
| SECURITY.md | ||
Dograh AI
The open-source, self-hostable alternative to Vapi & Retell — build production voice agents with a drag-and-drop workflow builder. From zero to a working bot in under 2 minutes.
📖 Docs · 📜 BSD 2-Clause · 🌐 中文 · 🌐 日本語
- 100% open source, self-hostable — no vendor lock-in, unlike Vapi or Retell
- Full control & transparency — every line of code is open, with flexible LLM / TTS / STT integration
- Maintained by YC alumni and exit founders, committed to keeping voice AI open
🎥 Featured
Featured by Better Stack — a hands-on look at Dograh
📺 Prefer a 2-minute product walkthrough? Click here.
⚖️ Dograh vs Vapi vs Retell
An honest comparison on the axes that matter most to teams evaluating voice AI platforms.
| Dograh | Vapi | Retell | |
|---|---|---|---|
| License | BSD 2-Clause (open source) | Proprietary | Proprietary |
| Self-hostable | ✅ Yes — one Docker command | ❌ SaaS only | ❌ SaaS only |
| Pricing | Free (self-host) · usage-based (cloud) | Per-minute SaaS | Per-minute SaaS |
| Bring your own LLM / STT / TTS | ✅ Any provider, or use Dograh's stack | Configurable within their integrations | Configurable within their integrations |
| Source-level customization | ✅ Every line is yours to modify | ❌ Closed source | ❌ Closed source |
| Data residency | Your infra, your rules | Their cloud | Their cloud |
| Vendor lock-in | None | Full | Full |
🚀 Get Started
Download and setup Dograh on your Local Machine
Note
We collect anonymous usage data to improve the product. You can opt out by setting
ENABLE_TELEMETRY=falsebefore running the startup script.
Note
If you wish to run the platform on a remote server instead, checkout our Documentation
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
⚡ Prefer an AI agent to set it up for you? If you use Claude Code or Codex, install the official Dograh setup skill and let your agent handle installation, configuration, and troubleshooting — it detects your OS, picks the right deploy path, runs Dograh's own setup scripts, and verifies the result.
# In Claude Code /plugin marketplace add dograh-hq/dograh-plugins /plugin install dograh@dograhThen start a new session and ask it to "set up Dograh" (or run
/dograh-setup). Codex is supported too — see the plugin repo.
Note
First startup may take 2-3 minutes to download all images. Once running, open http://localhost:3010 to create your first AI voice assistant! For common issues and solutions, see 🔧 Troubleshooting.
🎙️ Your First Voice Bot
- Open http://localhost:3010 in your browser.
- Pick Inbound or Outbound, name your bot (e.g. Lead Qualification), and describe the use case in 5–10 words (e.g. Screen insurance form submissions for purchase intent).
- Click Web Call — you're talking to your bot.
🔑 No API keys needed. Dograh ships with auto-generated keys and its own LLM / TTS / STT stack. Connect your own keys for LLM, TTS, STT, or Telephony (e.g. Twilio, Vonage, Telnyx) anytime.
Features
Voice Capabilities
- Telephony: Built-in telephony integration like Twilio, Vonage, Vobiz, Cloudonix (easily add others), with support for transferring calls to human agents
- Languages: English support (expandable to other languages)
- Custom Models: Bring your own TTS/STT models
- Real-time Processing: Low-latency voice interactions
Developer Experience
- Zero Config Start: Auto-generated API keys for instant testing
- Python-Based: Built on Python for easy customization
- Docker-First: Containerized for consistent deployments
- Modular Architecture: Swap components as needed
Testing & Quality
- Test Mode: Try your agent end-to-end before publishing, with no production calls or data affected
- In-Dashboard Web Calls: Talk to your bot directly while building — no telephony setup required
- QA Node: A built-in workflow node that analyzes prompt quality across your other nodes
Deployment Options
Local Development
Refer Local Setup
Self-Hosted Deployment
For detailed deployment instructions including remote server setup with HTTPS, see our Docker Deployment Guide.
Cloud Version
Visit https://www.dograh.com for our managed cloud offering.
📚Documentation
You can go to https://docs.dograh.com for our documentation.
📦 SDKs
- Python SDK — pypi.org/project/dograh-sdk
- Node SDK — npmjs.com/package/@dograh/sdk
🤝Community & Support
👋 Coming from the Better Stack video? Drop your use case in our pinned GitHub Discussion — we read every reply and the founders personally onboard early adopters.
- Slack — the cornerstone of Dograh AI contributions. Connect with maintainers, discuss features before coding, get help with setup, and stay current on contribution sprints.
- GitHub Discussions — share use cases, ask questions, swap workflow recipes.
- GitHub Issues — report bugs or request features.
👉 Join us → Dograh Community Slack
🙌 Contributing
We love contributions! Dograh AI is 100% open source and we intend to keep it that way.
Getting Started
- Fork the repository
- Create your feature branch (git checkout -b feature/AmazingFeature)
- Commit your changes (git commit -m 'Add some AmazingFeature')
- Push to the branch (git push origin feature/AmazingFeature)
- Open a Pull Request
⭐ Star History
📄 License
Dograh AI is licensed under the BSD 2-Clause License- the same license as projects that were used in building Dograh AI, ensuring compatibility and freedom to use, modify, and distribute.
🏢 About
Built with ❤️ by Dograh (Zansat Technologies Private Limited) Founded by YC alumni and exit founders committed to keeping voice AI open and accessible to everyone.