nvoken

Guides

Deployment

nvoken is always embedded in a host application. A complete installation is one binary plus Postgres — choose the single-daemon or Google Cloud profile after local evaluation.

nvoken is always embedded: a host application calls its API. It is self-hostable and bring-your-own-key, and a complete installation is one binary plus Postgres.

Start with Run nvoken locally first. The local setup is for evaluation — it has no TLS, backups, supervisor, durable secret store, or high availability. Choose a production profile only after that.

Choose a profile

nvoken ships two supported production deployment profiles. Pick the one that matches where you operate.

Single-daemon

One nvokend process in the combined role, embedded execution, in-process live events, and one operator-provided PostgreSQL database. A small production shape with durable restart recovery.

It is not highly available: while the daemon, its host, or Postgres is unavailable, the Runtime API is unavailable too. You own process supervision, host replacement, ingress and TLS, secret storage and rotation, Postgres availability and sizing, and backups. nvoken owns schema migrations, configuration validation, durable admission, execution claims and fences, checkpoints, ToolCall state, and authoritative reads.

The single-daemon profile ships a machine-checked example config, smoke and load tooling, failure drills, and incident runbooks.

Google Cloud Run

A Terraform root that deploys the recommended Google Cloud topology: one public combined Cloud Run service for the Runtime API and durable control-plane loops, plus a private request-bound executor reached through Cloud Tasks. Every new Invocation and its dispatch intent commit together in Postgres; the task request then exact-claims and runs one bounded generation segment.

Set invocation_execution_mode = "embedded" to roll back to the combined service's Postgres polling runner — public API semantics do not change. The Google Cloud profile provisions private Cloud SQL, Secret Manager, and an explicit migration job.

What you provide

Both profiles are operator-owned at the edges:

  • PostgreSQL 17 with durable storage, a tested backup plan, TLS or an equivalently protected connection, and enough connection capacity.
  • A process supervisor and HTTPS ingress (single-daemon), or the Google Cloud project and IAM authority (Cloud Run).
  • A secret store and at least one active provider API key.

Recovery guarantees

Neither mode treats delivery as ownership. An abruptly lost model segment is requeued from its last validated checkpoint after lease expiry, while Postgres fences stale writers. See Sessions & durability for the model.

Current production-readiness claims and required evidence are tracked in the readiness profiles and evidence matrix. Having a profile package does not by itself make an unexercised installation production ready.