Plan and apply
Nothing reaches a server until somebody has read what it will do.
Every change QuorumKit makes to a server goes through the same two steps. You describe what you want, it renders exactly what that means, and nothing happens until that render is approved.
The plan
A plan is not a summary. It is the change itself, rendered:
- the containers to create, with their images, commands, volumes and limits,
- the configuration files to write, with their contents,
- the firewall rules to open,
- the DNS records to publish,
- and everything to be destroyed, counted separately and never hidden.
"No changes" is an answer
If the current state already matches what you asked for, the plan comes back as no changes. That is a real outcome, not an error — re-planning an unchanged deployment does nothing and says so.
It also means a fix cannot be smuggled in through a re-plan. If a repair needs to happen, it has to be part of the desired state, or the planner has nothing to compare against and correctly does nothing.
The apply
Approving runs the plan node by node. The console shows the phase that is currently running, with that step's own log, and ticks each phase off as it completes. It can be minimised while it runs; it tells you when it finishes.
When a step fails
The run stops where it failed. Nothing rolls forward past an error, and you are told which node and which command. The plan that failed is still there to read.
An apply is not a transaction. Steps that completed before a failure have completed — on real servers, that is the honest model. What QuorumKit guarantees is that it stops, that it tells you precisely where, and that re-planning from the resulting state produces a plan that finishes the job.
Drift
The control plane keeps checking that each server still matches its plan. When something has been changed underneath it — a container removed by hand, a config file edited on the host — the deployment is marked as drifted and the console shows what differs.
Re-converging is the same loop: it plans the difference, you read it, you approve it.
Why it works this way
Every destructive operation in this product is gated by somebody having read a diff. Restores, failovers, destroying a deployment, changing a topology — all of them produce a plan first. It is slower than a button that does the thing, and it is the reason the thing is safe to run against a database somebody's business depends on.