Deployment model
Helmhive standardizes the release lifecycle without requiring one repository layout or one infrastructure tool. The control plane owns environments, plans and their hashes, approvals, leases, event history, serialization, and authorization. An adapter owns one typed operation. A workflow is an ordered list of adapter steps captured immutably in the approved plan.
Lifecycle
Section titled “Lifecycle”release → plan → approval → run → verify → succeed or fail → rollback (as a new plan)- Every environment requires approval, and production can never disable it. The approval window defaults to sixty minutes and is set per environment.
- Production plans require an explicit acknowledgment at approval time and at least one verification step after the last mutating step.
- Only one run is active per environment at a time.
- A plan becomes Superseded when its environment changes, Expired when its approval window passes or its environment revision moved before approval, and Reconciliation required when its run does.
Approval authorizes one exact plan
Section titled “Approval authorizes one exact plan”The plan hash covers the release (version, commit, artifacts), the workflow and environment revision, every connection revision, the runner label requirements, the operation, and the rollback target. Approval adds a unique, expiring decision. Queueing and claiming both revalidate the workspace and service, environment and connections, plan hash and approval, rollback eligibility, and exactly one eligible runner. Placement is pinned to the runner whose authority the connections name; two different runners would be ambiguous and the run is refused.
The mutation boundary
Section titled “The mutation boundary”Before its first mutating step, the runner records a mutation boundary naming the step and adapter. Until then, losing the lease or cancelling is safe and certain. After it, any lost lease, cancellation, adapter failure, or lost result puts the run into Reconciliation required: an administrator verifies the remote system and records one immutable decision with evidence. Only an observed success makes the plan succeed. Read-only steps keep a bounded retry policy because they cannot have changed anything.
Trusted release evidence
Section titled “Trusted release evidence”Server-side connectors can attach hashed facts to a plan: the observed repository commit, the CI run that produced the artifact digests, and the registry manifest for each digest. Outside the sandbox, queueing a run requires the complete repository → CI → registry chain for the plan’s commit and digests. Browser input and runner output cannot create these facts.
The execution gate
Section titled “The execution gate”Independently of approval, a server-side gate controlled by the people operating your installation decides what may execute: an explicit allowlist of workspace, service, and environment targets, a set of permitted adapters, and a production switch. In the current release the permitted set is the sandbox marker only and production execution is disabled, so every other method can be planned and approved but not run. Denied queue attempts are audited.
Rollback
Section titled “Rollback”A rollback plan copies a previously successful release verbatim and runs the environment’s current workflow. It needs its own approval under a separate capability, and the target is re-verified at execution. A workflow supports rollback only if every promotion, execute, and test step does.
See the guides under Deployment and the adapter catalogue.