docs.aywaruntime.com

Run voice agents inside your own infrastructure.

Aywa Runtime is a private voice agent runtime for teams that want provider ownership, data residency, predictable licensing, and production control without rebuilding their assistant stack.

Start install Explore API

private-runtime

curl -fsSL https://install.aywaruntime.com | \
  sudo AYWA_TOKEN="$AYWA_INSTALL_TOKEN" bash

aywa status
aywa update --channel stable
aywa support-bundle --redact

Control plane Licenses, billing, registry tokens, instance metadata.

Customer runtime Calls, audio, transcripts, provider keys, tools, webhooks.

Deployment target VPS and Docker Compose first, Kubernetes when the team needs it.

Why Aywa Runtime

Built from Aywa's own voice infrastructure constraints.

Aywa Runtime exists because production phone agents eventually need a tighter execution layer than a hosted voice-agent platform can always provide: predictable runtime licensing, private data flow, provider control, fast turn-taking, and operational visibility when a real call goes wrong.

The runtime is shaped by Aywa's own SDR phone-agent work and deployed production requirements: streaming STT, model routing, TTS fallback, barge-in, BYO telephony, webhook tools, and call-level observability in one private runtime boundary.

No Aywa platform markup on call minutes Bring your providers and audit the real STT, LLM, TTS, storage, and telephony costs.

Call data stays close Audio, transcripts, recordings, provider keys, and tool payloads remain in the deployed infrastructure.

Designed for real voice latency Turn management, endpointing, interruption, and TTS playout are treated as the core product.

Documentation library

The pages a production team needs before it routes calls.

Start with the install flow, then move into providers, API resources, operations, and migration validation.

QuickstartInstall token, host setup, status checks, first runtime readiness pass. Start here DeploymentVPS, Docker Compose, durable state, reverse proxy, backups, and Kubernetes path. Infrastructure Runtime APIAuth, assistants, phone numbers, calls, logs, metrics, files, tools, credentials. Reference ProvidersLLM, STT, TTS, telephony, storage, analytics, and default runtime profile. Configuration Tools and WebhooksServer cascade, durable outbox, replay, retries, and API request guardrails. Integrations OperationsReadiness, metrics, timelines, support bundles, SLOs, incident checks. Runbook Support and UpdatesRelease channels, signed updates, rollback, redacted bundles, and support boundaries. Maintenance LicenseSigned leases, instance activation, renewal, registry access, and grace behavior. Commercial MigrationImport compatible assistants, map providers, validate tools, and cut traffic safely. Compatibility SecurityData boundary, secrets, auth, SSRF policy, redaction, and compliance posture. Trust

Quickstart

From dashboard token to a live runtime host.

The dashboard issues a short-lived install token. The installer validates the signed license, pulls signed release artifacts, writes the local configuration, and registers the instance heartbeat.

Create a workspace

Install on a host

Run the installer on Ubuntu with Docker. The first production path is VPS + Docker Compose.

Connect providers

Add your LLM, STT, TTS, telephony, storage, and analytics credentials in the private runtime environment.

Verify readiness

Use aywa status, /readyz, and /metrics before routing production calls.

Deployment

VPS first. Compose by default. Kubernetes when needed.

The first production distribution should be an installer that lays down Docker Compose, a signed runtime image, Caddy or a compatible reverse proxy, and a license renewal agent. That keeps the setup simple for agencies and technical teams while leaving a path to Kubernetes later.

Single VPS Best for trial, agencies, and initial production.

HA Compose Multiple runtime nodes with Postgres, Redis leases, S3 artifacts, and shared analytics.

Kubernetes Helm chart target for teams with existing platform engineering.

Architecture

A small control plane, a private data plane.

Aywa's SaaS layer should never need raw call audio, transcripts, provider secrets, tool payloads, or recordings. Those belong to the deployed runtime and the customer's storage.

Aywa control plane

Auth

Billing

License issuer

Registry access

Customer runtime

Assistant API

Turn manager

STT / LLM / TTS router

Tools and webhooks

SIP / WebRTC media

Customer data plane

Postgres

Redis / Valkey

S3 / R2 / MinIO

ClickHouse

Runtime engine

The phone experience is governed by the turn manager.

The runtime coordinates streaming speech recognition, model streaming, tool calls, speech synthesis, interruption, and media playback as one voice session rather than separate provider calls.

Smart endpointing

Partial and final STT events decide when to wait, continue listening, or start the next assistant turn.

Barge-in

User speech can cancel pending LLM work, abort TTS, and stop RTP/WebRTC playout for the active turn.

Provider fallback

TTS and model routes can fail over while preserving the same call and assistant lifecycle.

Warm transfer

Transfer is modeled as a state machine with bridge, return, and SIP dialog handling.

Answering machine detection

AMD signals feed the same call state and webhook flow as live human conversations.

Live controls

Monitor and control URLs can say, add a message, end a call, transfer, or hand off.

Providers

Bring the providers you already trust.

These are the production integration categories reflected by the current runtime code and docs. Provider credentials stay in the runtime environment, not in the Aywa SaaS control plane.

LLM OpenAI gpt-4.1, OpenAI-compatible routes, warm-transfer model routes

STT Deepgram nova-3 with partial and final streaming transcript events

TTS ElevenLabs, Cartesia sonic-3, OpenAI gpt-4o-mini-tts, fallback voices

Telephony BYO SIP trunk, BYO phone number, FreeSWITCH hooks, optional SIP edge

Web calls WebSocket transport plus WebRTC bridge paths for LiveKit and Daily adapters

Data plane Postgres documents, Redis/Valkey leases, S3-compatible artifacts, ClickHouse analytics

Tools and webhooks

Tool execution belongs near the runtime.

Tool calls, webhook delivery, and replay sit inside the runtime boundary. The outbox writes jobs before dispatch, retries after crashes, and exposes delivery attempts for support review.

Webhook priority

tool server
assistant server
phone-number server
account webhook fallback

License

Signed leases, offline validation, fair renewal.

The runtime should validate a public-key signed license locally and renew it in the background when the subscription is active. If the network is unavailable, the runtime continues through the signed lease and grace window instead of depending on a per-call SaaS check.

Issue

Control plane issues a signed license with plan, instance allowance, expiration, grace, and key id.

Run

Runtime validates the signature locally and reports heartbeat metadata without sending media data.

Renew

License agent renews the lease while billing remains active and registry access remains allowed.

Expire

Updates and activation stop after grace, while customer data stays in the deployed infrastructure.

Operations

Production readiness is explicit.

Production startup should fail closed unless API auth, HTTPS public URL, Postgres, encryption key, Redis, S3 artifacts, and webhook signing are configured. Health and readiness endpoints make that visible.

Health

/health, /healthz, and /readyz separate liveness from readiness.

Metrics

/metrics exposes Prometheus text, while /metrics.json serves dashboard counters.

Timeline

/call/:id/timeline merges call logs, messages, webhook attempts, artifacts, and warnings.

Support bundle

aywa support-bundle --redact packages diagnostics without provider secrets or raw payload secrets.

Production essentials

RUNTIME_PUBLIC_URL=https://voice.example.com
RUNTIME_STORE_POSTGRES_URL=postgres://...
RUNTIME_STORE_ENCRYPTION_KEY=base64...
REDIS_URL=redis://...
RUNTIME_ARTIFACT_S3_BUCKET=voice-artifacts
WEBHOOK_SIGNING_SECRET=long-random-secret
VOICE_PIPELINE_ENABLED=true
VOICE_PIPELINE_STT_ENABLED=true
VOICE_PIPELINE_TTS_ENABLED=true

Migration

Switch execution without rewriting the assistant.

The importer is for compatible assistant configurations from third-party voice platforms. It is designed to move execution into Aywa Runtime while keeping the assistant contract familiar and the infrastructure boundary explicit.

Export assistant configuration Import into Aywa Runtime Map provider credentials Validate tools and webhooks Run a staging call Cut traffic over gradually

Security and privacy

Document the boundary clearly.

Aywa Runtime is independently developed. Compatibility workflows identify migration sources and payload shapes only when useful; the product boundary remains Aywa's own runtime, installer, license, and operator model.

Stored by Aywa SaaS

Account identity, workspace membership, billing state, license records, install token hashes, instance metadata.

Stored by customer infra

Provider keys, phone calls, recordings, transcripts, tools, webhook payloads, runtime logs, artifacts.

Never hide this

Customers still operate their runtime, providers, telephony, backups, network security, and incident response.