Run the whole voice stack — the media engine, the relay, and (optionally) your own speech models — inside your network, on your hardware. Nothing about a call has to leave your perimeter: SIP trunks terminate on your host, media is bridged in-process, and audio never transits TeleQuick’s cloud. This is the path for regulated verticals (HIPAA / SOC 2), data-residency requirements, and air-gapped or VPC-locked estates. Self-hosting is shipped and running in production at customer sites today. It is not yet a one-click installer — the first rollout is script-driven and usually done alongside our team. This page is the map of what runs where and the shape of the install so you know what you’re signing up for.
Before you self-host, read Deployment Models to decide between managed cloud, fully self-hosted, and hybrid (self-hosted media plane + managed control plane). Many teams only need the media plane on-prem — the control plane can stay managed.

​
What runs where

A self-hosted voice deployment is two hosts (plus an optional GPU host):
RoleWhat it doesWhere it runs
Voice engineTerminates SIP trunks and RTP media, runs the QUIC/HTTP-3 transport on :443, embeds the AI agent runtime, and bridges browser audio. One process, one machine.Dedicated Linux host with its own NIC
Media relayFans MoQT audio tracks out to browser/app subscribers and across hosts. Fronted at relay.telequick.dev.Same host (single-site) or separate hosts (multi-site mesh)
Control planeThe tenant admin API, agent/trunk config store, call-events pipeline, and recording storage. Serves portal.telequick.dev and the voice console at agent.telequick.dev.A second box (DB + object store + event bus)
Inference (optional)Your own speech-to-speech / ASR-LLM-TTS model server, reached over QUIC.GPU host(s) — see below
The engine is a modular host process: the SIP gateway (B2BUA + registrar), the RTP media plane, the QUIC/MoQT engine, the relay, and the agent runtime are all modules loaded into one process. You deploy and operate it as a single unit.

​
Before you begin

1

A dedicated Linux host for the engine

The engine takes full ownership of its NIC with a kernel-bypass fast path (zero-copy RX/TX for SIP, RTP, and QUIC on one interface). That means the NIC can’t be shared with other services — give the engine its own bare-metal box or a VM with a dedicated, passthrough-capable interface.
Because the process owns the NIC, applying config or a new build is a reboot cutover, not a hot reload — while the engine is down the interface is quiesced, and you won’t see a normal listening UDP :443 socket in ss while it’s running. Plan a maintenance window for changes. This is the single biggest operational difference from a typical service.
2

A control-plane host

A second Linux box runs the admin API, the config database, the call-events store, and recording object storage. There is no Docker — everything runs as systemd units against a pinned Node runtime under /opt. This keeps the install auditable and avoids a container runtime in regulated environments.
3

(Optional) a GPU host for self-hosted models

If you want inference on-prem too, provision one or more GPU hosts to serve your speech model. The engine reaches them through the inference control plane over QUIC — covered in Self-Hosted Inference.
4

DNS you control

You’ll point per-tenant SIP and WebRTC hostnames at the engine, and the console/relay hostnames at the right box. Public QUIC/WebTransport needs valid TLS certs for your brand domains (the transport does SNI across them).

​
Install and cut over

1

Provision the hosts

Stand up the engine host (dedicated NIC), the control-plane host, and — if self-hosting models — the GPU host(s). Lay down systemd units and the service config on each.
2

Deploy the engine

The deploy script builds the engine host, its transport core, and the modules, ships them to the box, and swaps them in atomically. Then reboot the engine host to bring the NIC-owned data plane up on the new build (see the reboot warning above).
3

Bring up the control plane

Start the admin API, database, event bus, and object store on the control-plane host as systemd units. The event bus is always TLS + SASL authenticated — there is no plaintext mode. Recordings land in the local object store and surface in the console.
Tenant credentials (trunk digest secrets, provider API keys) are sealed at rest. The engine and control plane share one key-encryption key so the engine can unseal them at call time — no plaintext secrets on disk. This is what makes the deployment HIPAA / SOC 2 defensible.
4

Point DNS and provision a tenant

Create a workspace in the console. Onboarding provisions the per-tenant SIP and WebRTC hostnames — <workspace-id>.sip.telequick.dev and <workspace-id>.webrtc.telequick.dev — and the SIP SRV records that route carrier INVITEs to your engine. Point portal.telequick.dev, agent.telequick.dev, and relay.telequick.dev at the right hosts.
5

(Optional) attach self-hosted inference

Register your model server with the inference control plane and set the agent’s provider to your endpoint. The engine will route turns to your GPUs over QUIC instead of a cloud realtime provider. Full steps live in Self-Hosted Inference.
6

Place a test call

Register a softphone against your tenant SIP domain (or point a carrier trunk at it) and dial in. Watch the call land, the agent answer, and — if recording is on — the .wav appear in the console. See Inbound Calls for the trunk and dialplan wiring.

​
Honest status

What’s shipped: the engine, SIP/RTP media plane, QUIC/MoQT transport, relay, agent runtime, call-events + recording pipeline, and credential sealing all run in production on-prem today.What’s still maturing: the self-hosted inference leg — the QUIC-based control plane that discovers and routes to your GPU pods is shipped, but the fully on-prem speech-to-speech model path has not yet been live-verified end-to-end in a customer deployment. If you need on-prem GPU inference from day one, plan it as a joint bring-up rather than a drop-in. The managed-cloud model providers (cloud realtime, ASR/LLM/TTS) work against a self-hosted engine today if you’re allowed egress to them.
There is intentionally no separate sandbox environment — a self-hosted deployment is a single production environment. Test in a dedicated workspace or a second install, not a sandbox toggle.

Deployment Models

Managed, self-hosted, and hybrid — how to split the media and control planes.

Self-Hosted Inference

Serve your own speech models on your GPUs and route to them over QUIC.

Managed Cloud

Prefer zero infra? Ship the same agent on the managed cloud in minutes.

Self-Hosted Troubleshooting

NIC ownership, reboot cutovers, DNS, and sealed-credential gotchas.