Docs · Deploy

Deployment

The development candidate is designed for a single self-hosted node bound to loopback. Production deployment guidance remains intentionally conservative.

Build and start

go build -o watchpost ./cmd/watchpost
./watchpost --listen 127.0.0.1:8080 --data-dir /var/lib/watchpost

Do not run as root. Give the service account write access only to its data directory. The included packaging/watchpost.service is a starting point that must be reviewed for your paths and operating system.

Install Watchpost Agent

The separate agent currently packages supported Linux amd64/arm64 archives. The installer verifies SHA256SUMS before writing anything.

# Current user, no sudo
curl -fsSL https://watchpost-ops.github.io/agent-install.sh | sh

# Deliberate machine-wide binary
curl -fsSL https://watchpost-ops.github.io/agent-install.sh | sudo sh -s -- --system

The user route installs to ~/.local/bin/watchpost-agent; system mode installs to /usr/local/bin/watchpost-agent. Run watchpost-agent install afterward to create and start the service before pairing.

Reverse proxy boundary

Keep Watchpost on loopback and terminate HTTPS at a reviewed reverse proxy. Preserve the original host and scheme, apply request-size and timeout limits, and do not expose health or diagnostics more broadly than intended.

Backups

Stop Watchpost before copying its SQLite data directory in this development version. A filesystem copy taken during writes is not a supported online backup. Test restoration into a separate directory before relying on a backup.

Upgrades

Database migrations run at startup. Before any future production upgrade, preserve the old binary and a tested backup, then verify startup, authentication, post counts, evidence counts, and representative history queries.

Fleet deployment

Each paired Watchpost remains independently useful and holds a separate secret. Pairing is not a reason to expose the federation endpoint publicly without TLS, network policy, rate control, and key-rotation procedures.