Skip to content

Self-host Provon

Run Provon on infrastructure you control: the Workbench, API, Gateway, OTLP ingest, diagnostics, and background jobs ship as one deployment. Metadata, trace evidence, and stored credentials stay in your own stores; no hosted Provon management service is required to operate the instance.

View as Markdown Open the plain-text version of this page.
Choose a runtime

One Node process, or a split Cloudflare deployment.

Architecture and data flows

Planes, storage boundaries, request paths, and failure modes.

Runtime configuration

Secrets, origins, storage URLs, and background-loop settings.

Security boundary

TLS, credentials, identity policy, and evidence privacy.

Operations

Health signals, backups, upgrades, capacity, and incidents.

Upgrade a deployment

Release policy, rollout steps, and rollback limits.

Choose A Runtime#

Both runtimes share the same project, API-key, Gateway, trace, Rule, Run, and Finding semantics. The choice changes deployment topology and storage responsibilities, not the product model.

Runtime Choose it when Operational shape
Node You want the shortest path to a private VM, container, or single server One process serves the Workbench, API, Gateway, OTLP ingest, and local background loops
Cloudflare You want independently scalable Workers and managed queues/stores in your own Cloudflare account Pages, Workers, Queues, D1, KV, R2, R2 SQL, Data Catalog, Durable Objects, and a Container-backed warehouse
Choose runtime Configure secrets and origins Deploy and initialize stores Apply the security boundary Monitor, back up, and upgrade

Node: single-process deployment#

Use Node self-hosting for a VM, bare-metal host, Docker host, private cloud, or a single-instance container platform. The default queues and runtime state live in one local data directory: run one active Node instance unless you replace those adapters with shared infrastructure. Multiple replicas against the same metadata database do not make the local jobs or queues highly available.

Cloudflare: split managed deployment#

Use Cloudflare self-hosting when Gateway and OTLP traffic must scale independently from the Workbench, asynchronous ingest and diagnostics should run on managed queues and cron triggers, or telemetry should land in R2 Data Catalog with R2 SQL reads. Every resource belongs to your own Cloudflare account; the demo deployment uses isolated provon-demo-* coordinates.

What You Operate#

Self-hosting transfers these responsibilities to your team:

Area Responsibility
Availability Runtime health, restart policy, capacity, queue lag, and dependency recovery
Data Storage location, backups, restore tests, retention, and deletion policy
Security TLS, network policy, identity providers, secret custody, and API-key rotation
Upgrades Release selection, store initialization baseline, rollout, verification, and recovery
Integrations Provider credentials, OAuth applications, callback URLs, and outbound allowlists
Cost Compute, storage, telemetry growth, model-provider usage, and platform services

Provon applies project isolation and encrypts stored provider and connector credentials, but it cannot choose your infrastructure controls, backup policy, or legal data boundary.

  1. Read Architecture for storage, network, and failure boundaries.
  2. Deploy either Node or Cloudflare.
  3. Set secrets, public origins, storage, and connector values in Configuration.
  4. Apply the Security boundary before production traffic.
  5. Define backup, monitoring, upgrade, and recovery procedures in Operations; review the Upgrade guide before applying a new release.

For a product walkthrough before self-hosting, use the Quickstart.

Production Gate#

Important

Do not send production evidence until: every public endpoint uses HTTPS; PROVON_AUTH_SECRET is explicit, stable, backed up, and loaded from a secret manager; metadata, telemetry, blobs, and runtime state are on durable storage; backup and restore have been exercised; payload capture and retention match the data classification; sign-in, project API keys, Gateway, OTLP, diagnostics, and repair handoff are verified separately; queue and background-job failures are monitored; and the previous application version plus a rollback procedure are available.