The whole stack, on your own servers
Run DialPress where your data has to live. Start with one Linux server, move to containers, and grow into Kubernetes, with the same apps and routes at every step.
At a glance
Your data
Calls, recordings, and transcripts stay on infrastructure you control.
Same code
Apps and routes don’t change between DialPress cloud and your servers.
Per module
Add capacity where the load is, not everywhere at once.
Zero-drop
Stopping instances drain first, so upgrades never cut a caller off.
Deploy
Pick where it runs
Each step uses the same modules. Move up when the load asks for it.
- Step 1
DialPress cloud
Start in our cloud. Numbers, carriers, and speech are included.
$ export DP=https://api.dialpress.ai/v1 $ curl -X POST $DP/agents/front-desk/calls \ -H "Authorization: Bearer $TOKEN" \ -d '{"to": "+15550100", "from": "+15550199"}' { "id": "c_8f2c", "state": "initiating" } $ curl "$DP/calls/c_8f2c?wait=answered&timeout=30s" { "id": "c_8f2c", "state": "answered" } - Step 2
One Linux server
A single installer sets up the gateway, speech, and agents as hardened systemd services, with TLS for your domain.
# hardened systemd units, TLS for your domain $ deploy/linux/install.sh install --build \ --domain voice.yourcompany.com --email [email protected] ✓ dialpress ✓ dialpress-speech ✓ dialpress-agents # or every module as a container $ docker compose -f docker-compose.yml \ -f docker-compose.modules.yml up -d --wait - Step 3
Kubernetes
A Helm chart runs every module as its own workload and autoscales it on live metrics. Stopping pods drain first, so deploys never drop a call.
$ helm upgrade --install dialpress deploy/helm/dialpress \ -f deploy/helm/dialpress/values-production.yaml Release "dialpress" has been upgraded. Happy Helming! $ kubectl get deploy -n dialpress dialpress 3/3 dialpress-api 2/2 dialpress-speech 4/4 dialpress-agents 3/3 - Step 4
GPU machines
Speech and agents run on GPU machines over mutual TLS, balanced by model and load.
# balanced by model and load, over mutual TLS $ export DIALPRESS_SPEECH_RECOGNITION_BALANCED=true $ export DIALPRESS_SPEECH_RECOGNITION_ENDPOINTS=\ gpu1.example.com:7071;models=whisper-small;weight=2,\ gpu2.example.com:7071;models=whisper-small|parakeet $ dialpress ✓ speech-recognition: 2 endpoints healthy
Built to scale
Every layer scales on its own.
01
Modular by design
Each module (gateway, speech, agents, messaging, recording) runs in-process, as its own process, or on its own machines over mutual TLS.
02
Horizontal gateways
Run as many gateway instances as you need. Registrations are shared, calls keep dialog affinity, and traffic is spread by policy.
03
GPU-balanced speech
Speech and agent requests go to the least-loaded healthy endpoint that serves the model, weighted per GPU.
04
Autoscaling
On Kubernetes, every module group scales on live metrics and CPU, with bounds you set per module.
05
Zero-drop deploys
Stopping instances drain first: no new calls, live calls finish. Upgrades and scale-downs never cut a caller off.
06
Same code, any size
One binary on a laptop, a Compose stack on a VPS, or a fleet on Kubernetes. Your apps and routes don’t change.
Common questions
Why self-host?
Data residency, control over models and GPUs, and predictable cost at volume.
What do I need to start?
One Linux server and a domain. The installer sets up TLS.
Can speech run on separate machines?
Yes. Speech and agents run on GPU machines over mutual TLS.
How is self-hosting priced?
Self-hosted deployments are quoted on an enterprise agreement.
Run DialPress on your servers.
Tell us where it has to run, and an engineer will help you size it.