Self-Hosted Dograh Voice Stack: Cost and n8n Setup

I did not want to rebuild a voice engine for dental lead calls

I am building a dental patient acquisition system on GoHighLevel, n8n, and CRMBridge for a UK dental marketing agency use case. Voice was the one layer I refused to hand-build from scratch: speech-to-text, text-to-speech, telephony, call state, barge-in, turn-taking, provider swapping. That is real-time systems work. It is not the best use of build time when the product value sits in CRM logic, campaign strategy, and vertical workflow design.

So I self-hosted Dograh: an open-source voice AI platform positioned as a self-hostable alternative to Vapi and Retell. This post is the technical teardown: how it is deployed, how n8n triggers outbound calls and ingests transcripts, what it actually costs, and why I am building Docker images from source instead of running a hosted snapshot.

Stack placement

Dograh is not the whole product. It is the voice execution layer inside a larger acquisition stack:

The dental-specific logic (what to ask, when to escalate, how to tag a lead) lives in Dograh workflows and n8n. Dograh handles the hard real-time voice plumbing.

Deployment: build from source, not a frozen image

Dograh publishes Docker deployment docs. The quick path is docker compose up on a prebuilt image. I am not running the hosted cloud product or a static image I cannot patch.

On a Hostinger VPS I clone dograh-hq/dograh and build Docker images from the repo so I can:

• Pull upstream fixes and features on my schedule
• Patch telephony or webhook behavior without waiting on a vendor release
• Extend Dograh for FusionSync client deployments (custom nodes, internal tooling, compliance hooks)

That is the same philosophy as our n8n MCP writing-room stack: own the orchestration layer, rent inference, keep state on hardware you control. Dograh becomes FusionSync's default voice stack for vertical builds where data must stay on the VPS, not on a third-party SaaS.

Everything runs on one VPS today: Dograh app, n8n (already on n8n.fusionsync.ai), and webhook endpoints on the same network. No call audio, transcripts, or lead context round-trips through Vapi/Retell cloud.

Workflow design in Dograh

Conversation logic is node-based, not a single mega-prompt. For dental lead qualification I mapped:

1. Start call: greet with name and reason if initial_context is present
2. Main agenda: verify service interest (implants, cleaning, whitening, etc.)
3. Branch / tool calls: scheduling hooks, escalation paths (WIP)
4. End call: clean hangup and webhook payload

The Global node sets persona ("Sam" / dental receptionist framing). The API Trigger node exposes a public agent URL. The Webhook node posts call outcomes back to n8n when the run completes.

Two trigger paths matter for production:

• API Trigger: programmatic outbound from n8n (primary for this build)
• Webhook (#6): receives post-call payloads into https://n8n.fusionsync.ai/webhook/...

n8n outbound trigger

When a lead hits the right CRM stage, n8n sends a POST to Dograh's public agent endpoint with:

• phone_number (E.164)
• initial_context (name, service interest, source campaign, anything already in GHL)

Dograh injects that context before the first spoken line. The difference is obvious on a live call:

• Bad: "What's your name?" on every dial
• Good: "Hi Vishal, I am calling about your dental implants enquiry on our website."

Example response shape from a successful trigger:

Authentication is Header Auth (Dograh (SH) credential in n8n). The agent UUID lives in the path: /api/v1/public/agent/{agent_id}.

Post-call webhook: transcript, recording, CRM sync

When the call ends, Dograh fires a webhook into n8n with the run metadata. The workflow branch I care about:

1. Receive webhook payload
2. Fetch or parse transcript (timestamped assistant/user turns)
3. Store recording URL or file reference if enabled
4. Map outcome to GHL custom fields / CRMBridge tags
5. Route hot leads to human callback queue

Transcript cleanup runs in a Code node. Raw transcript text is regex-parsed into structured messages:

First real test call (dental implants enquiry) parsed cleanly: assistant intro with context, user confirmation, agenda questions. That loop (trigger → call → webhook → parse → sync) worked on the first end-to-end run for outbound.

What it actually costs

Most voice AI articles hide the bill. Here is the honest stack for self-hosted Dograh at current test volume:

Dev telephony workaround: Twilio Dev Phone calling a Twilio-owned number (Twilio-to-Twilio). Same stack, no international voice charges while iterating on prompts and workflow nodes. We documented the same pattern in WhatsApp OTP troubleshooting for Meta verification; the principle applies here too.

Production telephony switches to real PSTN routes once workflows are stable. Budget for Twilio minutes separately from LLM tokens. They are different meters and both scale with call volume.

Compliance: why self-host matters for dental

Dental lead data can include PHI once a caller discusses treatment, symptoms, or appointment details tied to an identifiable person. Hosted voice platforms add another data processor to your compliance packet. Self-hosted Dograh keeps audio, transcripts, and inference on your VPS boundary.

Practical compliance path I am wiring for production:

1. Data residency: Dograh + n8n + storage on VPS or client-controlled cloud. No third-party voice SaaS in the path.
2. LLM: Azure OpenAI with HIPAA-eligible deployment and BAA (replace raw OpenAI key in prod).
3. Access control: n8n credentials isolated per client; webhook secrets rotated; no public agent URLs without auth headers.
4. Retention policy: Define recording and transcript TTL in n8n + CRMBridge writeback rules (still being finalized per client contract).

Dograh's own positioning on data sovereignty and on-prem deployment aligns with this: you audit the pipeline because the code is open. You still need your own legal/compliance review. Self-hosting removes one vendor. It does not remove HIPAA obligations.

What is not production-ready yet

Inbound calls are still being configured. Outbound API trigger + webhook loop is solid. Inbound PSTN routing, IVR handoff, and after-hours behavior are the next block before this ships to a paying dental client.

Also on the roadmap:

• Azure OpenAI swap for all prod inference
• CRMBridge field mapping for qualified vs callback vs not interested
• Cadence rules in n8n (retry windows, do-not-call guards)
• Dograh fork patches FusionSync needs for multi-tenant agency deployments

Why not build voice from scratch (again)

I have built calling infrastructure before. Possible, not free. Weeks go to WebRTC edge cases, provider quirks, and state machines that Dograh already ships.

My leverage is the dental acquisition system: GHL pipelines, CRMBridge into Exact/Dentally, n8n cadence, agency white-label fulfilment. Rebuilding a Vapi clone to prove a point is a bad trade. Forking and extending an OSS runtime is a good one.

That is the setup I would recommend to any agency or founder building a real voice product:

• Open source voice runtime (Dograh on GitHub)
• Self-hosted on a VPS you control
• Bring your own keys (with Azure OpenAI for healthcare)
• Orchestrate with n8n
• Own CRM and vertical logic on top

Same pattern as PolarBuild's dental stack: prove the workflow on n8n + GHL first, then harden for production compliance.

The bottom line

• Dograh is FusionSync's default self-hosted voice layer for vertical builds that need data on your infra, not a hosted voice SaaS.
• Deploy from source on a VPS so you can extend and upgrade Dograh, not rent a black box.
• n8n triggers outbound calls via API, receives webhooks, parses transcripts, and syncs outcomes into GHL/CRMBridge.
• Costs are VPS + LLM tokens + Twilio minutes. Dev Phone saves telephony spend while you iterate.
• HIPAA path is Azure OpenAI + VPS residency + explicit retention rules. Still your compliance work to finish.
• Outbound works. Inbound is next.

Agency owners packaging dental or healthcare voice intake: message me on WhatsApp with your vertical, compliance requirements, and whether you already run GHL + n8n. We can map where Dograh fits in a white-label fulfilment rollout.