Hi everyone,
I’ve been building Torollo, an MIT-licensed local lab for practicing system design with real Docker infrastructure.
The idea came from a limitation I kept seeing in system-design exercises: you can draw a perfectly reasonable architecture without proving that the system actually behaves the way the diagram claims.
In Torollo, the visual architecture is materialized as real local Docker containers and networks. Roadmap steps then inspect the running state rather than grading the diagram.
For example, one exercise builds a three-tier application with a load balancer, replicated web servers and PostgreSQL. At one point, the database is supposed to be isolated from the load balancer. If the load balancer can still reach PostgreSQL on 5432, the validator fails. You change the network/security rule, run it again, and it only passes once the runtime matches the expected state.
The current version includes three free labs:
- resilient three-tier architecture
- Redis cache-aside
- Redis queue workers
It runs locally with Node 18+ and Docker:
npx torollo start
No account is required, the core is MIT licensed, and telemetry is off unless explicitly enabled.
One limitation I’m already documenting: advanced subnet/NAT behaviour requires a rootful Docker daemon, since rootless Docker can’t apply all of the host networking rules Torollo uses.
What I’d especially like feedback on from Docker users is the trust boundary: if you were going to let an educational tool control containers and networks on your local Docker daemon, what would you want to be able to inspect, restrict, or disable first?
Short demo / lab:
GitHub:
I’m also interested in cases where the networking model or terminology feels inaccurate compared with how you actually use Docker.