Self-hosting an AI voice stack: a practical guide


Data residency, GPU costs, and control push many teams to run voice AI themselves. A practical path from one Linux box to a Kubernetes fleet.
Running voice AI on your own infrastructure gives you control over data, latency, and cost. It used to mean stitching together a SIP server, a media server, a speech stack, and an agent framework. With DialPress it is one stack with one set of deploy options.
Start with one server
A single Linux installer sets up the gateway, speech, and agents as hardened systemd services with TLS for your domain. It is the fastest way to a working phone number that an AI agent answers.
Move to containers
Docker Compose runs every module as its own container, with memory and CPU bounds per service. Scale a busy module on its own instead of scaling everything.
Grow into Kubernetes
The Helm chart runs each module as its own workload, autoscaling on live metrics. Stopping pods drain first, so deploys and scale-downs never drop a call.
Put speech on GPUs
Speech recognition and agents can run on GPU machines over mutual TLS, balanced by model and load. Weight bigger GPUs higher; route each model only to the machines that serve it.
Keep the same code
Your routes, agents, and apps do not change between a laptop and a fleet. That is the point of an infrastructure layer.
Field notes
Keep reading
Build an AI voice bot like an Express app
The dialpress Node SDK turns SIP into routes and handlers. Here is a PBX and an AI voice bot that share one gateway — and pass calls between them.

SIP vs WebRTC for AI voice agents
SIP reaches every phone number on earth; WebRTC reaches every browser. A production voice agent needs both — here is how they fit together.

Giving voice agents tools with MCP
Your booking system, your CRM, your order lookup — any API can become a voice agent’s tool without writing a line of agent code.
