Voice runs the same code everywhere — the only question is whose infrastructure it runs on. Pick a deployment model based on where your call audio and customer data are allowed to live, whether you want to operate GPUs, and how much of the stack you want to manage yourself. There are three models. Most teams start on managed cloud, and a regulated few move media or inference into their own environment later. Nothing about your agent config, SDK code, or dialplan changes when you switch — those are portable across all three.

​
The three pieces

Before you choose, it helps to know what actually runs. Every TeleQuick Voice deployment is three planes:

Control plane

The console at agent.telequick.dev, the tenant-scoped control-plane API at engine.telequick.dev, the Postgres-backed config database, and the columnar analytics store behind your reports. Holds agent configs, trunk definitions, call records, and recordings metadata.

Voice engine

The QUIC/HTTP-3 endpoint on :443, the SIP gateway/B2BUA, the RTP media plane, and the embedded agent runtime. This is where call audio actually flows — PSTN trunks, browser MoQT tracks, and the WebRTC fallback leg all terminate here.

Inference

The speech models — a self-hosted speech-to-speech model on your GPUs, or a hosted provider endpoint (OpenAI Realtime, Gemini Live, Deepgram, ElevenLabs, …) that the runtime dials out to. This is where transcripts and generated audio are produced.
The models below differ only in which of these three you host and which we do.

​
Choose a model

We run all three planes. You bring an API key and an agent config; there is no infrastructure to operate.
  • You host: nothing. We host: control plane, engine, and (for the default runtime) inference.
  • Media path: call audio lands on our engine. PSTN trunks point at your per-tenant SIP host <workspace-id>.sip.telequick.dev; browsers connect to the QUIC endpoint on :443.
  • Best for: shipping fast, variable call volume, teams with no ops appetite for real-time media or GPUs.
There is intentionally no sandbox environment — managed cloud is a single production plane. Use a separate workspace for staging rather than expecting a sandbox toggle. See Managed Cloud quickstart.

​
Where data lives

Data residency is decided by where the engine runs, because the engine is the only plane that touches raw call audio.
DataManaged cloudSelf-hostedHybrid (managed CP + own inference)
Live RTP / call audioOur engineYour engineOur engine
Transcripts & generated audioOur inference (or your provider)Your inferenceYour GPUs
Agent config & trunksOur control planeYour control planeOur control plane
Call records & recordingsOur storesYour storesOur stores
Provider / SIP credentialsSealed, our storesSealed, your storesSealed, our stores
Two levers narrow the media footprint further, in any model:
  • Direct media. Per-trunk media_mode: direct terminates RTP on the shard where the agent runs, so audio never traverses an extra hop; proxy is only for hostile-NAT carriers. See Sessions, Calls, Tracks & Streams.
  • Sealed credentials. Every provider key and SIP secret is encrypted at rest under your key-encryption-key regardless of where the control plane lives.

​
When to self-host inference

Self-hosting the models is the most common reason to leave pure managed cloud. Reach for it when:
1

Transcripts can't leave your boundary

Regulated audio (health, finance, government) where sending speech to a third-party API is off the table. A self-hosted speech-to-speech model keeps every transcript and generated token inside your GPUs.
2

You want model control

You need a specific fine-tune, a pinned model version, or a model no hosted provider offers. You serve it yourself and the runtime routes to it.
3

GPU economics beat per-minute pricing

At sustained concurrency, amortized GPUs can undercut metered realtime API minutes. Self-hosting turns a variable per-minute cost into fixed capacity.
The runtime reaches your models through an inference control plane that discovers GPU pods, scrapes their load, and routes requests over QUIC — you supply the GPUs (your own cluster, or a rented GPU host); we supply the routing and the duplex audio adapter.
The text-generation routing tier of the inference control plane is shipped; the single speech-to-speech model path is not yet verified end-to-end in production. If you’re planning a self-hosted-inference rollout, validate against your own traffic before cutover. Details in Self-Hosted Models.
If you don’t need any of the above, stay on managed inference — point the runtime at a hosted realtime or ASR/LLM/TTS provider and skip GPUs entirely. See Runtime overview.

​
Next steps

Managed cloud quickstart

Ship a voice agent with zero infrastructure.

On-prem quickstart

Run the full stack in your own environment.

Self-hosted models

Serve your own speech models on your GPUs.

Voice architecture

The end-to-end signalling, media, and runtime path.