Skip to main content
Start day-to-day work with the read-only commands from the same released CLI that created the workspace:
Keep their output with the workspace so you can compare the current observed state with the last successful apply.

​
Monitor the stack

These lifecycle checks are the supported way to assess the stack itself. StackKits keeps the observation and verification evidence locally and needs no hosted monitoring service. The released Uptime Kuma module is not selected by the initial native v2 StackSpec, so a fresh Basement or Cloud Kit has no generated monitoring address. If you run a separate monitor, add checks only for routes you are authorized to monitor. Protected routes need an intentional health endpoint or an expected authentication response; weakening route protection to obtain HTTP 200 is not a valid monitor setup.

​
Before a change

  1. Update the StackSpec, not generated artifacts.
  2. Run stackkit validate and stackkit generate.
  3. Inspect stackkit plan --json and stop on any readiness blocker.
  4. Review the output and obtain the local owner’s approval before a mutating command.
  5. Run stackkit verify --http --json after the change.

​
Add a workload to an existing workspace

Selecting a new workload does not require re-running stackkit init or replacing the initial StackSpec. Edit the workloads block of the existing StackSpec, then establish secret custody before regenerating:
StackKits v0.21.11 adds stackkit secrets materialize as the explicit step between selecting a workload and running generate. Establish custody, then generate and apply; do not invent secret values.

​
Remove an applied workload

stackkit remove removes one exact applied workload with the local owner’s approval:
The CLI verifies the current plan, generation, apply result, and owner authority, then dispatches an owner-signed removal request that stays valid for five minutes through the digest-pinned Standard execution channel. Success requires an absent readback for the exact requirement, instance, and applied artifact digest. The request, result, and bounded terminal evidence are persisted below .stackkit/evidence/removal/.

​
Target one placement on a multi-node result

The verified apply summary exposes planHash, appliedRequestDigest, and a secret-free appliedWorkloads list. Each entry is a deterministic, hash-bound identity that binds the workload, runtime owner, placements, execution channel, and referenced artifact digests. Use it to identify what a later removal should target; it is neither removal authorization nor absence evidence on its own. Since v0.21.12, when the apply result placed a workload on more than one Site or node, name the one exact placement this removal owns. Take the values from the appliedWorkloads entry:
The named placement must match exactly one entry in the verified apply result. Every node-local absence receipt stays correlated to the same original apply through the shared appliedRequestDigest. Add --terminal-evidence-json when you need a machine-readable removal record on stdout.

​
Common workflows

Change StackSpec intent

Edit released intent and regenerate governed output.

Back up and restore

Create an idempotent snapshot and practice staged recovery.
The exact command surface is versioned with the release. Use stackkit --help and the command-specific help for the installed version before performing a backup, restore, upgrade, or removal.
StackKits does not provide an unattended hosted-operations workflow in Standard Mode. Treat every mutating command as a local operation on a host you control.
For an agent-connected workflow, see the MCP connector.