morzer¶
A CLI that manages the lifecycle of a self-hosted product on one Linux machine running Docker Compose: install, configure, update, roll back, back up, restore, diagnose.
The unit of delivery is a release bundle — an immutable archive containing a manifest, Compose files, configuration templates and lifecycle hooks. The unit of management is an installation — the state of one deployment on one machine.
What it is not¶
Not a container orchestrator, an infrastructure provisioner, a secret manager, a backup engine, a workflow engine, or a CI system. It coordinates Docker Compose, SOPS, age, systemd and the release's own hooks; it owns ordering, atomicity, verification and reporting.
That boundary is the point. Everything the manager does is a sequence of steps
against tools that already exist, and every one of those steps can be planned
with --dry-run, journaled, verified after the fact, and undone.
Two audiences¶
-
Operators
You run the product on a machine you own. You install it, converge it, watch it, update it, and put it back when an update goes wrong.
-
Bundle vendors
You ship the product. You write the manifest that declares what a release needs, and the hooks that carry the product-specific logic the manager deliberately does not know.
Install¶
See Installing morzer for a verified download, or from a clone:
just build # ./morzer
Try it without touching /etc¶
Every managed path derives from a single root, so the whole thing can be exercised against a throwaway directory:
just demo
That runs init, status, doctor and secret list against the example
bundle in testdata/bundle/, writing everything under tmp/demo/.
just demo-plan then shows what apply would do as a step list with a
configuration diff, and just demo-json shows the machine-readable output
contract.
The hidden --root flag relocates every managed path — including the absolute
configuration targets a manifest declares — so nothing touches the real /etc.
How this is organised¶
| Section | For |
|---|---|
| Get started | A first deployment, start to finish |
| Operating | The tasks an operator does: updating, rolling back, secrets, backups, recovery |
| Authoring | Shipping your own product as a release bundle |
| Reference | Every command, flag, exit code, manifest field and hook variable |
| Explanation | Why it is shaped this way |
Design records for work that has not shipped live in
rfcs/, not here — they
carry statuses that change, and mixing draft designs into documentation of
shipped behaviour would make both harder to trust.