Install

One command installs the platform: kapable-ops bootstrap walks a 10-node dependency graph from a blank box to a served, TLS-terminated sample app. Every node is idempotent — the same command is the installer, the verifier, and the repair tool.

First call
kapable-ops --help

You should see the operator command list.

The command

From your workstation (the installer connects to the server over SSH; nothing needs to be pre-installed on the box):

kapable-ops bootstrap \
  --server my-kapable-box \
  --domain example.com \
  --acme-email ops@example.com \
  --admin-email admin@example.com \
  --org-slug acme \
  --org-name "Acme" \
  --staff-email admin@example.com \
  --public-ip 203.0.113.10 \
  --artifact-source ~/kapable-artifacts \
  --no-mail
FlagMeaning
--serverSSH host (alias or user@ip) of the target box. Root access required.
--domainYour base domain. Org hosts and platform services hang off it; apps at <app>.<org>.<domain>.
--acme-emailLet's Encrypt registration email.
--org-slug / --org-nameYour first organization. The slug becomes its subdomain.
--admin-email / --staff-emailThe owner account created for you, and which account gets platform-staff rights.
--public-ipThe box's public IPv4 — cross-checked against DNS during preflight.
--artifact-sourceDirectory containing the licensed platform binaries for your release. See artifact distribution.
--no-mailSkip SMTP entirely. Use --smtp-host/-port/-username/-password and --email-from instead when you have a mail provider.

The 10-node graph

Nodes run in dependency order; each prints its outcome as it lands.

#NodeWhat it does
0preflightSSH reachability, OS check, DNS records resolve to --public-ip, ports open.
1pgPostgreSQL 16 installed, cluster up, platform databases created.
2secretsService secrets generated on the box and written to per-service env files (never transmitted).
3berthThe deploy orchestrator installed with per-service signing keys; refuses unsigned deploys from first boot.
4caddy-stage-1The edge in HTTP-only bootstrap mode, ready to answer ACME challenges.
5fleet-deployAll platform services deployed through Berth as signed artifacts, health-checked.
6caddy-stage-2Full TLS edge: the gateway generates route config from its database; certificates are minted on demand and gated by an authorization check.
7first-orgYour organization and owner account created through the real signup API; credentials persisted on the box at /root/.kapable-bootstrap/ (mode 0600); a real login is performed as the gate.
8first-appA sample app registered, built through the CI pipeline, and deployed.
9seal-checkEnd-to-end verification: the app answers 200 over a real certificate. See Verify.

APPLIED vs NO-CHANGE

Each node reports one of two outcomes. APPLIED means the node found something missing or wrong and fixed it — expected everywhere on a first run. NO-CHANGE means the node verified its slice of the system and touched nothing.

Run the command twice. A correct installation reports NO-CHANGE on all ten nodes the second time. That all-NO-CHANGE repeat is not a formality — it is the proof that the installer converged, and it is the same mechanism you will later use to repair drift.

If a node fails, read the error — it names the cause and the corrective action. Fix, then re-run the same full command: completed nodes fly by as NO-CHANGE and execution resumes where it stopped. A full re-run is the supported resume mechanism.

Next Steps

Next

Getting Started · Authentication