Every infra lesson is a running system you can break

Most infra tutorials show you a diagram. This breaks something while you watch.

The Services lesson gives you a pod's IP and tells you to curl it. Then it deletes the pod. Your requests hang. Now it explains why Services exist.

The permissions lesson has you chmod 777 a file, then runs it as another user. It fails with Permission denied. Now it explains why the group bit mattered.

That's learninfra.dev: 120+ lessons across Linux, networking, Kubernetes, system design, and AI infra, where every page is a live system. No cluster, no containers, no account. It all runs in your browser.

Why I built it

I learn fine from docs, but I learn best from breaking things.

The problem is that breaking things usually needs infrastructure. A cluster to wreck, a VM to lock yourself out of, a network to misconfigure. That's slow to set up, easy to get wrong, and a bit scary on a machine you care about. So most people read about failure instead of causing it.

I wanted the other version: a place where you can delete the pod, drop the packet, or run out of GPU memory, and nothing real is on the line.

How every lesson works

The format is always the same:

1. Watch it run. The system does its normal thing.
2. Predict what happens next. You commit to a guess before you see it.
3. Break it on purpose. Delete the pod, change the record, raise the batch size.
4. Fix it with the real command. Drills rehearse the exact keystrokes, like kubectl run --dry-run=client -o yaml, dig +short, or chmod 750.

Each lesson ends with a cheat sheet and a playground with unsolved challenges, so you can try the idea again without hand-holding.

The Kubernetes track is mapped to CKAD, CKA, and CKS competency, if you're studying for one of those. But it's one track of five. Linux, networking, system design, and AI infra work the same way.

There's no backend, so how does it work?

Each track has a small simulation engine that runs in the browser: a fake kubelet, a fake shell, a packet simulator, a GPU planner.

Worlds are plain JSON, and every run is fully deterministic: no randomness, no real clock. Same steps in, same state out, every time.

That's what makes the next part possible.

If the text and the sim disagree, the build fails

This is the part I'm proudest of.

A test suite replays every lesson step and asserts that the simulation state matches what the narration claims. If the text says the pod goes Pending and the sim says Running, the text is wrong. That's the rule, and CI enforces it.

A simulation is only useful for learning if it doesn't lie to you. A tutorial that quietly drifts out of sync with its own demo teaches you the wrong thing with total confidence. I didn't want to write that tutorial, so the build won't let me.

A linter also checks every lesson against the same structure before it ships, so the quality bar doesn't depend on my mood that day.

Try one lesson

It's free, and there's no sign-up: learninfra.dev

If you only do one, make it Pods. It takes about 20 minutes, and afterwards, you'll never put a pod IP in config again. If Kubernetes isn't your thing, pick whichever track you're weakest in. That's usually where breaking things teaches the most.

Still early

I would like to know what falls short. Tell me:

• Which lesson confused you
• Which sim lied to you
• What topic is missing

Drop it in the comments. I read all of them and will fix the misleading simulations.