* feat(helm): add HPA for arq-worker + ui, ship a lean k3s prod example ## Problem The chart's autoscaling story only covers the `web` tier — one `web-hpa.yaml` template gated by `autoscaling.web.enabled`. Operators scaling the `arq-worker` (background jobs) or `ui` (Next.js SSR) tiers have to write their own HPA manifests out-of-band or fork the chart. Turning the existing memory-utilization target on for freshly-installed workloads also silently breaks: idle Python at the chart's default `128Mi` (workers) / `256Mi` (ui) memory request already sits above `80%`, so HPA scales every tier to `maxReplicas` on cold start with no traffic. On a tight node this cascades into "insufficient CPU" and blocks new-workload scheduling. ## Fix **New HPA templates** — `templates/arq-worker-hpa.yaml` and `templates/ui-hpa.yaml`, both mirroring the existing `templates/web-hpa.yaml` shape (autoscaling/v2, resource metrics, gated on `.Values.autoscaling.<tier>.enabled`). **Extended `values.yaml`**: - `autoscaling.workers` and `autoscaling.ui` blocks with sane defaults (`enabled: true`, `minReplicas: 1`, `maxReplicas: 5`, `targetCPUUtilizationPercentage: 70`). - `targetMemoryUtilizationPercentage: null` on both tiers by default, with an inline comment explaining why memory-utilization HPA is a broken signal at the chart's default request sizes. - Header comment reworked to (a) document the `metrics-server` requirement, (b) note that HPA takes ownership of Deployment `replicas` after first sync, (c) call out that CPU is a poor signal for the web tier (long-lived WebSockets), and (d) note that CPU is a fine signal for workers and ui. **Example**: `examples/values-k3s-prod.yaml` — a single-node k3s production override that exercises the new HPA blocks and demonstrates the paired safety changes (memory targets nulled, sized resource requests, migration job CPU sized for a tight node). Ship-ready starting point for the operator flow: hosted-AI only (no local models), all state on the node's local-path StorageClass, invite-only signup, TLS terminated at a shared Cloudflare Origin cert. ## Behavior Fresh install with defaults: - Workers scale 1 → 5 on CPU 70% target only. No memory-based scale-up storm on cold start. - UI scales 1 → 5 on CPU 70% target only. - Web autoscaling stays `enabled: false` by default (unchanged) — operators opt in per the existing README warning. Operators who want memory-based HPA back can: 1. Bump `workers.resources.requests.memory` (~256Mi) or `ui.resources.requests.memory` (~384Mi). 2. Set `autoscaling.<tier>.targetMemoryUtilizationPercentage: 80`. * address review: omit replicas when HPA on, suppress empty-metrics HPA, docs Fixes raised on #516: - **Worker/UI Replicas Reset On Upgrade** — arq-worker-deployment.yaml and ui-deployment.yaml now wrap `replicas:` in `{{- if not .Values.autoscaling.<tier>.enabled }}`, mirroring the existing web-deployment guard. With HPA on, Helm no longer reapplies the static replicaCount on upgrade and briefly shrink an HPA-scaled pool. - **Empty Metrics Render Invalid HPA** — arq-worker-hpa.yaml and ui-hpa.yaml now short-circuit the whole HPA object when both CPU and memory targets are null. Previously the template emitted `spec.metrics:` with no items (rejected by the k8s API server). - **`enableSignup: false` removed from examples/values-k3s-prod.yaml** — that knob depends on #514 which hasn't landed; unwiring it here avoids suggesting a lockdown that isn't in effect until the sibling PR merges. - **Header comment mismatch** — `# HPA: 1 → 5 on CPU 70% / memory 80%` claimed memory was on while every tier had `targetMemoryUtilizationPercentage: null`. Updated to "CPU 70% only (memory HPA opt-in)". - **Wrong default in comment** — `values.yaml` said workers default is `128Mi`; actual is `256Mi`. Fixed. - **UI comment said "idle Python"** — UI is Next.js/Node.js. Corrected on the UI HPA memory comment and the per-tier comments in values-k3s-prod.yaml (web: FastAPI, workers: Python/ARQ, ui: Node.js). All lints pass; verified with `helm template`: - Defaults render both HPAs and Deployments without static `replicas:`. - `--set autoscaling.workers.targetCPUUtilizationPercentage=null --set autoscaling.workers.targetMemoryUtilizationPercentage=null` renders only the Deployment (HPA suppressed). - `--set autoscaling.workers.enabled=false` renders the Deployment with static `replicas:` restored. * address review: align Deployment replicas gate with HPA render gate Follow-up on #516: my earlier fix guarded `spec.replicas` on only `autoscaling.<tier>.enabled`, but the HPA-empty-metrics guard I added suppresses the HPA object when both metric targets are null while `enabled: true`. That combination produced a Deployment with neither a `spec.replicas` value nor an HPA owner — a k8s Deployment defaults to `replicas: 1` in that case, but the chart no longer expresses intent. Fix: the Deployment `replicas` gate now mirrors the HPA render gate exactly. Rendered outcomes verified with `helm template`: | autoscaling.<tier> | HPA rendered? | Deployment replicas? | |-------------------------------|---------------|----------------------| | enabled: true, target set | yes | omitted (HPA owns) | | enabled: true, both null | no | static (kept) | | enabled: false | no | static (kept) | * fix(helm): default worker/ui autoscaling off; ui HPA floor of 2 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(helm): align web replicas/HPA gate with worker/ui pattern Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * docs(helm): document worker/ui HPAs in README; polish k3s example 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@cc535a0c86 | ||
| 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
⚖️ 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.