Upgrades & Rollback

Upgrades

Stop the service, swap the binary, start the service. The data/ directory is forward-compatible across point releases by design — schema migrations, when they happen, are documented in release notes. The zen CLI automates the swap:

zen app update \
  --url https://artifacts.example.com/zenvara-linux-x64.tar.gz \
  --sha256 <hash>

--sha256 is optional but strongly recommended — it pins the artifact and prevents man-in-the-middle replacement during the download.

Flow YAML carries version: "1.0.0" for forward-compat; only the major version is checked at load time. A platform upgrade that bumps the major is flagged by the validator output before promotion, so you find these at staging time, not at production runtime.

Two rollback dimensions

The two are decoupled by design — you can roll back a config without touching the binary, or vice versa.

Binary rollback

zen app rollback

Reverts to the previous artifact. The data/ directory is unchanged, so a restart picks up the previous version’s behaviour. Use when an upgrade breaks something. ~2 minutes of downtime, no data loss.

Configuration rollback

When Git versioning is enabled, every connection / environment / flow change is committed automatically. Reverting is one call:

zen versions revert <ref>

…or the version-revert REST endpoint. Use when a config change broke a flow. Zero downtime.

Putting it together

Symptom	Action	Downtime
New binary misbehaves	zen app rollback	~2 min
A flow/connection edit broke a pipeline	zen versions revert	none
Bad data state	Restore from backup	varies

Write and rehearse a runbook entry for “binary rollback” before go-live — it’s on the checklist.