Platform Concepts

This overview covers v2 agents on dedicated coderunner pods. If you know Kubernetes, Helm, and Docker, these analogies explain how VoiceRun packages code, deploys revisions, and routes live calls.

Caller → Number / provider → Entrypoint → Route → Release → Pod → Session ↑ ↑ │ Organization → Environment ───────────────────────┤ │ │ Agent → Function (pushed code) ────────────────────┤ Coderunner │ Templates + values → rendered manifest ───────────┤ │ Secrets (bound at session start) ────────────────────────────────────┘ Session → child session through another entrypoint (parent.track)

A release pins the agent, environment, function and rendered manifest. The coderunner control plane builds its image and manages its pods. A phone number/provider delivers a call to an entrypoint. The first matching route selects a release by weight; a pod handles the session. The session records the selected release, environment, entrypoint, route name (track), and origin.

VoiceRunAnalogueNotes
OrganizationTenant (cluster / RBAC root)Everything below is organization-scoped
EnvironmentNamespaceproduction, staging; any agent can release into any environment; entrypoints belong to one
AgentApplication (workload name)Logical identity; owns Functions; has many Releases
FunctionContainer imagePushed code version per vr push, environment-agnostic, promotable
vr pushdocker pushNew Function version
Templates + values (.voicerun/templates, values.yaml)Helm chartRendered at release time
vr releasehelm upgradeNew immutable Release; -e also repoints an entrypoint
release.manifestHelm release recordImmutable list of documents picked by kind: Deployment, Simulation, Evaluator, Webhook
Organization SecretSecret (secretKeyRef)Referenced by name at render, value bound at session start, never in the release record
Deployment.spec.variablesInline env: valuesRender-time literals; no ConfigMap equivalent yet
ReleaseDeployment revisionagent + environment + function + manifest, immutable; desiredState running/standby = replicas > 0 / scaled to zero
ReleasePodPodObserved state reported by the coderunner control plane
Coderunner control planekubelet / controller-managerBuilds the per-release image, runs pods, pushes state snapshots
EntrypointGateway listener + HTTPRouteListener = phone number / web origins / native client id; environment-scoped; claims an org phone number
RouteHTTPRoute rulename + matches → releases with weights; catch-all = default; name stamped on the session as track
vr update entrypointEditing the HTTPRouteShift weights, add/remove routes; rollback = point the route at the previous Release, nothing is rebuilt
Organization phone number + telephony providerExternal IP / cloud load balancerOrg-scoped inventory; an entrypoint claims it
SessionRequest / connectionStamped with agent, environment, release, origin, track; may spawn a child via parent_session_id
Simulation (kind: Simulation)Helm test hook / Argo Rollouts ExperimentPersona + mode (ws joins the release directly, pstn dials the entrypoint) + count
SimulationRunhelm test runOne vr simulate: N sessions with origin: simulation
Evaluator (kind: Evaluator)Argo Rollouts AnalysisTemplateLLM judge or code assertion, shipped in the chart
EvaluationAnalysisRun measurementPer session per evaluator on session end; compare by track for progressive delivery

Where the analogy breaks#

A Release is both a deployment revision and the object routes target: no mutable Kubernetes Service sits between them. An Environment currently groups resources and constrains routing; it does not carry configuration or secrets. Voice sessions can spawn other sessions through the same routing gateway, so route names are persisted as tracks and exposed as parent.track for same-organization children.

Routing changes never rebuild code. Point a route back at a previous release to roll back, or promote a conditional route's release pool to the catch-all. See Routing for a caller-based rollout.

platformkuberneteshelmrouting