pinecallDocs
Sign inBook a demoGet started
Get started / Overview

Overview

Run the whole runtime yourself: on a laptop to develop it, on Kubernetes to serve calls.

Self-hosting is running the Pinecall runtime yourself: the gateway, the workers and the services they stand on, on your own machines and your own cloud account. It is open source (pinecall/runtime), the same code that serves cloud.pinecall.io.

Building an agent does not need any of this. Pinecall Cloud runs the runtime for you: start with the Quickstart.

What is the runtime?#

One Python package, pinecall-runtime (uv tool install pinecall-runtime; it needs Python 3.12, which uv brings), and its operator's CLI of the same name. It serves both the sandbox and production from one gateway and one database.

The gatewayEvery HTTP route, the console and the widget, for the sandbox and production. Any gateway serves any call. The workersThey run the calls on LiveKit: a fleet each for the sandbox and production, so a sandbox call never shares a machine with a production one. PostgresThe one stateful service: every call's log, the orgs, the keys, every secret sealed under the vault key. LiveKit and RedisThe media plane and SIP, a LiveKit each for the sandbox and production; Redis is how gateways tell each other what just happened.

Two ways to run it#

On your machine On Kubernetes
for developing an agent against a runtime of your own, trying Pinecall, developing the runtime serving calls
made by pinecall-runtime local up, one command Terraform for the cloud, Helm charts for the runtime
where Postgres, Redis and LiveKit in Docker; the gateway and one sandbox worker on the machine a GKE cluster on Google Cloud: two gateways, Postgres under CloudNativePG, and for each of the sandbox and production a LiveKit, SIP and workers that scale with the calls
the console built into the package, at http://127.0.0.1:8080 built into the runtime's image
phone calls Linux only, and a carrier that reaches the machine's port 5060 a SIP name each for the sandbox and production, port 5060 open to the carriers alone
backups and alerts none WAL to a bucket as it is written, a base backup each night, alerts on the gateways' measures

Both run the same code with the same settings: what differs is where each variable comes from (Environment variables).

What you need#

On your machine

  • Docker with the compose plugin, and uv, which installs the runtime: uv tool install "pinecall-runtime[voice]".
  • Node 24 or later, for the pinecall CLI.
  • A key for each vendor your calls run on: a model, speech-to-text and a voice — or models on your own hardware, and no vendor at all.

On Kubernetes

  • A Google Cloud project, with gcloud signed in, Terraform, Helm and kubectl.
  • A DNS zone on Route 53 for the runtime's names: the one name the sandbox and production are served at, and a SIP name for each.
  • Checkouts of the runtime, the console and the widget side by side: make image builds the console and the widget into the runtime's image.
  • A private directory of your own values: every chart's values and the Terraform variables, which the repository never holds.
  • The same vendor keys, put once into the runtime's own keys or each org's.

Your own GPU#

Optional on either: open models on your own NVIDIA card as the runtime's vendors. Three model servers (Whisper for the ears, Gemma 4 for the model, Kokoro for the voice) and a providers row that points at them. No cloud vendor hears, thinks or speaks in the call.

Next steps#

On your machineThe whole runtime on one computer, with one command. On KubernetesA cluster from nothing, to serve calls. Your own GPUOpen models as the runtime's vendors. The runtime CLIOrgs, keys, routes and the fleet.