Free · No signup · No "subscribe to continue"
Most tutorials teach you commands. These guides teach you the mental model first — what problem the tool solves, and why its design makes sense — so the commands stop needing to be memorised.
The guides
Each guide is a curriculum, not a reference. Read it in order once, then come back to the chapters you need.
Package an application with everything it needs to run
Learn Docker in the order that actually makes sense: the problem it solves, the four concepts everything else is built on, your first real Dockerfile, and the six mistakes every beginner makes.
Track every change, and undo any of them
A guide built around the one thing most Git tutorials skip: the object model. Understand what a commit actually is and the scary commands stop being scary.
Describe your infrastructure, then let a plan tell you the truth
From your first resource to a module structure that survives a second environment — including the state management decisions that are painful to change later.
Declare what should be running, and let the cluster keep it that way
The reconciliation loop first, YAML second. Learn why a Deployment exists before you learn its fields, and Kubernetes stops feeling arbitrary.
How these differ
Chapter one is never installation. It is the problem the tool was built to solve, because everything else only makes sense once you have that.
Each guide states the exact version it was verified against. If a command in here fails for you, it is a bug and we want to hear about it.
Official docs describe what the tool does. We wrote down what everybody gets wrong on the way there, which is where the time actually goes.
Start here
From the blog
The order that works, and why starting with the quickstart is usually a mistake. A method drawn from writing these guides, and from getting it wrong first.
Every managed platform quotes a headline price that is accurate and incomplete. We went through a year of real invoices across six vendors and catalogued the line items that show up after you have already migrated.
A better tool is not a reason to migrate. We use four questions to decide whether a stack change is worth the disruption, and they have talked us out of more migrations than into them.
No drip sequence, no upsell, no course. Just the guide.