Self-host overview

For the current launch path, "self-hosted" means the worker runs on your machine, dev box, CI host, or VPS while the hosted Viewport control plane authorizes and records the run.

hosted Viewport control plane -> lease/grants -> your vpd worker -> receipts back to Viewport

What You Can Run Today

Self-Hosted Worker

Pair and start a polling worker:

vpd pair PAIRING_CODE --worker --transport=polling --workdir "$HOME/.viewport/worktrees"
vpd worker doctor --json
vpd worker start --mode persistent --transport polling

The worker executes the workflow locally and can use local tools, model keys, package registries, and repo access according to your environment. Hosted Viewport still owns hosted admission, workflow authority, and receipts.

Server Configuration

Hosted Viewport is the default server for the normal pairing command. If you operate a compatible internal control plane, specify it explicitly at pair time:

vpd pair PAIRING_CODE --worker --server https://viewport.customer.internal --transport=polling --workdir "$HOME/.viewport/worktrees"

The open-source daemon should be portable. The server it is paired with decides the policy for that environment.

Relay And On-Prem

Relay self-hosting is useful when you need tighter network control for monitor or streaming paths. It is not the same as a full on-prem control plane.

Full-stack on-prem support is not a launch claim. Contact the team if your deployment requires it.

Operational Defaults

• keep the worker workspace under a dedicated directory;
• run one worker process per lease/concurrency slot unless the runner explicitly supports more;
• use vpd worker doctor --json before live runs;
• rotate local secrets through your own secret manager;
• do not commit worker profile files or lease tokens.