An explainer, played back
Seven short chapters on the idea that your infrastructure can have a commit history. Press play, or click any point on the graph below to jump around.
Open
What happens when your infrastructure gets a paper trail.
01 — Before
An engineer runs a command against a live server. It works. Nobody writes down what changed. Three weeks later, nobody remembers why staging and production have drifted apart.
02 — The idea
You write what the system should look like — a YAML file, checked into Git — instead of a list of commands to get there. That file, and its history, becomes the single source of truth.
03 — How it runs
Software inside the cluster reads the repo, reads what's actually running, and applies only the difference. Nothing outside the cluster ever pushes into it — the cluster pulls from Git.
04 — When things drift
If someone edits production by hand, the next reconciliation pass notices the mismatch — and quietly overwrites it back to whatever Git says. Git wins, every time.
05 — When things break
A bad deploy goes out. Someone runs git revert. The operator picks up that commit on its next pass and redeploys the last known-good state — no SSH, no manual patch.
06 — Recap
Open — GitOps
Space to play/pause · ← → to change chapters · click the graph to jump · the speaker icon turns on spoken narration. Motion is skipped automatically if your system prefers reduced motion.