Skip to content
UniDPP Docs

Operations: deployment and the always-on loop

Deployment and the always-on loop

Section titled “Deployment and the always-on loop”

The reference deployment lives in unidpp-pilot-data: ten services on 127.0.0.1:8389-8399, each an append-only journal plus a binary, all wired by one operator manifest and orchestrated by the unidpp-stack program.

Terminal window
./ops/target/release/unidpp-stack up     # build-if-needed + start every service + wait healthy
./ops/target/release/unidpp-stack status # the truth: per-service health, journals, and every
                                         # public hostname probed THROUGH its tunnel
./ops/target/release/unidpp-stack down   # stop everything; journals are preserved

up is the idempotent repair: healthy services are reused untouched, dead ones restart (journals replay on start), and every tunnel is re-ensured. A second run is a no-op, which makes it safe as a cron watch:

*/10 * * * * cd <pilot-dir> && ./ops/target/release/unidpp-stack up >/dev/null 2>&1

What status actually checks

Section titled “What status actually checks”
  • Every service (including the console and the JP peer node) answers /healthz and identifies itself at /; a healthy listener of the wrong service fails the check, not just a dead port.
  • Every tunnel is probed through its public hostname: a tunnel process can be alive while its origin is down, and the world sees 502. status prints the real answer and exits non-zero.
  • Journal state: the registry’s journal records → items, the log’s tree head, the seeded applicability.

PID discipline

Section titled “PID discipline”

Never pkill/killall by process name on a host running the stack — the stack’s services share binary names with test instances. Kill by the exact PID from run/*.pid, or unidpp-stack down. After any local test run that spawned services, unidpp-stack status to confirm the stack’s integrity.

The containerized variant

Section titled “The containerized variant”

docker-compose.yml in the same repo runs the identical stack containerized (same ports, same env wiring; unidpp-stack stays the primary path). Journals and the passport store are bind-mounted so state survives restarts.

Tenants

Section titled “Tenants”

A tenant is a manifest: tenants/<name>/unidpp-operator.yaml + journals. unidpp-stack tenant <name> [up|down|status] renders the service environment from the manifest (unidpp-config render-env) and runs exactly the declared services. Whitelabel and sovereign deployments are manifest deltas; see Multi-tenant operations and Deployment profiles.