Philosophy
The core principles that guide every decision at TLD.
These principles aren't just words on a page. They shaped how TLD labs are written, how validators work, and how we think about the right way to teach infrastructure.
Learn by breaking
The best way to understand a system is to watch it fail. TLD gives you deliberately broken environments so that the act of debugging teaches you the internals — not a lecture about them.
When you spend 20 minutes tracking down why a container can't reach the internet and discover it's because the bridge network was misconfigured, you'll never forget how Docker networking works. That's the point.
Infrastructure is disposable
Every TLD lab is ephemeral. You spin it up, you break things, you fix them, and you tear it down. There is no persistent state to protect. This removes the fear of experimentation — the biggest obstacle to learning infrastructure.
Read the docs
TLD labs don't give you the answer. They give you the tools, the environment, and enough context to figure it out yourself — the same way a real on-call incident works. You're expected to read man pages, official documentation, and error messages.
Validators check the outcome, not the method. How you get there is up to you.
Automate everything
Manual verification is unreliable. Every TLD lab has an automated validator — a shell script that checks your solution against the expected state. No human needs to review your work. The validator is the judge.
This also means the platform scales. Anyone can write a lab with a validator and contribute it. The system handles the rest.
No vendor lock-in
TLD runs on your machine using open-source tools. Docker, bash, Go — tools you'll use regardless of which cloud provider or employer you work with. We deliberately avoid proprietary platforms, managed services, or tools that require an account.
Understand before copying
Copying commands from Stack Overflow works exactly once. TLD labs are designed to force understanding — you can't just paste your way to a passing validator. You need to know why the fix works.
Hints are available for when you're stuck, but they lead you in the right direction — they don't hand you the answer.