Who Torollo is for#
Backend developers preparing for system design interviews
Torollo's roadmaps cover the architecture patterns that appear most often in backend design interviews: load balancing, database tiering, caching with Redis, and async job queues. Running each step against a live system makes the constraints concrete rather than theoretical.
Skip if:
Skip if you need broad prep across many technology tracks. Torollo ships three intermediate roadmaps. For coverage of Kubernetes, service mesh, or distributed systems patterns, a platform with a wider catalogue is a better starting point.
Engineers learning Docker networking hands-on
Drawing a VPC with private subnets and a NAT gateway in Torollo, then watching real iptables rules get written and a MASQUERADE route appear, is a faster path to understanding Docker bridge networking than reading documentation. In-browser terminals let you verify the routing table directly inside the container.
Skip if:
Skip if your interest is container orchestration or Kubernetes scheduling rather than host-level networking fundamentals. Torollo has no concept of multi-node clusters or cluster-level service discovery.
Instructors running backend architecture labs
Torollo's JSON roadmap format lets instructors write lab exercises without writing code. Students import a zip pack from the Learning page and run the full lab locally, so there are no cloud costs and no concurrent-session limits when a class of twenty runs at once.
Skip if:
Skip if your curriculum covers cloud-specific managed services such as S3, RDS, or Lambda equivalents. Torollo's node palette covers Docker-runnable open source services and does not simulate managed cloud primitives.
Self-hosters building a persistent home lab
The Docker Compose path runs Torollo as a persistent service with project and roadmap progress stored in a named volume. Set TOROLLO_BIND_ADDRESS=0.0.0.0 and add your LAN IP to TOROLLO_ALLOWED_ORIGINS to reach it from any device on your home network.
Skip if:
Skip if your home network is shared with untrusted users. Torollo has no login system; anyone who can reach the port gets full control of the Docker daemon. Put it behind an authenticating reverse proxy before exposing it beyond localhost.
The problem it solves#
Learning backend system design from documentation or static diagrams leaves a gap: you can describe what a three-tier architecture does, but you cannot feel the moment a misconfigured firewall drops traffic or a cache miss cascades into database overload. Cloud sandbox platforms fill this gap partially, but they come with subscription fees, session time limits, and the risk that a reset environment removes the exact mistake you were about to understand.
The specific friction is validation: most tutorials end with a diagram showing what your architecture should look like. Torollo ends with a grader that probes your running containers and reports the difference between what your design specifies and what the network actually does. That gap is where the learning happens.
How it solves it#
Visual canvas backed by real Docker containers
Every node on the canvas corresponds to a running container on your local Docker daemon. Ubuntu servers, Postgres, MongoDB, Redis, RabbitMQ, and load balancers all draw from the same palette, and each one starts a real container when placed. The canvas reflects live container state, not an aspirational diagram.
Guided roadmaps with live validation
Three built-in roadmaps cover deploying a resilient three-tier app, cache-aside with Redis, and workers with a Redis job queue, each at intermediate difficulty. Every step closes only when the grader confirms your containers behave as specified: it checks container status, SQL schemas, Redis keys, HTTP reachability, and firewall restrictions between subnets.
Real networking: VPCs, security groups, NAT gateway
VPCs and subnets map to Docker bridge networks. Security groups write actual iptables rules inside the containers, not a simulated representation. The NAT gateway uses real ip_forward and MASQUERADE routing so private subnets get outbound access through the correct interface. A built-in traffic simulator lets you watch requests flow through your topology.
In-browser terminals into every container
Every Ubuntu server node exposes a root web terminal in your browser via WebSockets and xterm.js. You can inspect running processes, read logs, and test connectivity between containers without leaving the Torollo UI or opening a separate terminal session.
Built-in database explorers
Postgres, MongoDB, and Redis nodes each include a data explorer accessible from the canvas. The Postgres explorer shows schemas, tables, and runs live SQL; the MongoDB explorer handles JSON collection queries; the Redis explorer accepts native CLI commands. No external client is needed to inspect the state of your running containers.
Open JSON roadmap format
Roadmaps are plain JSON files documented in the authoring reference. Drop a valid file into the roadmaps/ directory or import a zip pack from the Learning page and it appears in the catalogue without a repo checkout. Instructors can write and distribute custom lab exercises using this format.
Strengths and trade-offs#
Strengths
- Zero cloud dependencyTorollo runs entirely on your local Docker daemon. No cloud account, no remote infrastructure, no API keys, and no charges when you leave a container running overnight. The backend log lives in ~/.torollo/logs/backend.log and project state in ~/.torollo/projects.json, both under your control.
- MIT license with no ongoing costThe entire codebase is MIT licensed, so you can run it indefinitely on your own hardware, fork it, and modify it without restriction. Unlike subscription-based cloud labs that charge monthly fees, running Torollo has no cost beyond the hardware needed to run Docker.
- Grader checks the live system, not the diagramStep validation probes running containers directly: network reachability between subnets, actual HTTP responses, SQL schema state, Redis key presence. You cannot pass a step by drawing the right shape. When a step fails, the grader reports what was expected and what was observed, making the feedback specific and actionable.
- Built-in environment diagnosticsThe doctor command checks Node.js version, Docker CLI availability, socket permissions, port conflicts, and disk space, and exits non-zero when something would block startup. The --json flag produces a machine-readable report for filing GitHub issues. Setup failures are diagnosable without reading through raw error logs.
Trade-offs
- -No authentication on the APIThe Torollo backend binds to 127.0.0.1 by default and has no authentication. Anyone who can reach the port inherits control of the host Docker daemon. The default configuration keeps Torollo private to localhost, but exposing it on a shared or public network without an authenticating reverse proxy is a genuine security risk the README documents explicitly.
- -Full network engine requires rootful DockerRootless Docker users cannot use VPC subnets, NAT, or cross-subnet security groups because those features require host iptables rules that a rootless daemon cannot write. The doctor command flags this at startup. Switching to a rootful daemon resolves it, but that is not always an option on shared or locked-down machines.
- -Small roadmap catalogue at launchThe current release ships three roadmaps at intermediate difficulty. Beginners looking for introductory content, or engineers wanting to explore Kubernetes, service mesh, or distributed tracing patterns, will find the catalogue thin. The JSON format is open, so community-authored roadmaps can fill gaps, but that requires someone to write them.
- -First-run image download takes several minutesThe initial startup downloads Docker images for every supported node type. On a slow connection this can take several minutes. Subsequent starts are fast, but instructors running Torollo in a classroom setting should pre-pull images before the session or account for the initial wait.
Torollo vs alternatives#
Torollo vs Cloud-Based Backend Lab Platforms
Cloud-based lab platforms like KodeKloud and Killercoda deliver browser-based, pre-configured environments for backend and DevOps learning. Both charge monthly subscription fees and host the compute centrally, meaning lab sessions can time out and your progress depends on an internet connection.
| Feature | Torollo | Cloud Lab Platforms |
|---|---|---|
| License | MIT | Proprietary |
| Hosting | Local Docker | Vendor cloud |
| Cost | Free (self-hosted) | Subscription |
| Session limits | None | Typically timed |
| Catalogue breadth | 3 roadmaps | Hundreds of courses |
| Network authenticity | Real iptables on host | Cloud VMs or simulation |
Torollo's advantage is that execution is genuinely local. When Torollo writes an iptables rule, it writes one on your host. When the grader checks network reachability between subnets, it probes actual Docker bridge interfaces. There is no simulation layer and no cloud VM standing in for your infrastructure, which makes the behavior you observe match what you would see on a real server.
Cloud platforms are a better fit when breadth matters. KodeKloud covers Kubernetes, Terraform, Ansible, CI/CD pipelines, and dozens of other tracks alongside backend fundamentals. Torollo currently ships three roadmaps. If you need structured coverage of a wide curriculum, a subscription platform delivers that out of the box in a way Torollo does not yet.
Torollo vs Cisco Packet Tracer
Packet Tracer is the canonical drag-and-drop networking simulator used in Cisco education programmes. The Torollo README positions it directly as the backend-engineering equivalent of Packet Tracer.
| Feature | Torollo | Cisco Packet Tracer |
|---|---|---|
| License | MIT | Proprietary |
| Execution model | Real Docker containers | Simulation |
| Focus area | Backend services and networking | Network devices and protocols |
| Distribution | npm / Docker Compose | Cisco NetAcad installer |
The key distinction is simulation versus execution. Packet Tracer simulates device behavior inside its own closed-world runtime. Torollo runs real software: a Redis container accepts actual RESP commands, a Postgres node runs real queries. Bugs in your architecture surface as the same errors you would see in production.
Packet Tracer is the better choice for learning Cisco IOS, routing protocols, OSPF, and network device configuration. Torollo has no concept of routers or switches. Torollo is the better choice for learning how real backend services interact: how a load balancer distributes HTTP traffic, how a job queue decouples producers and consumers, and how firewall rules determine which container can reach which port.
Quick start#
Deploy Torollo via Docker Compose for a persistent local server; Docker Engine and Docker Compose v2 are required.
```bash
git clone https://github.com/Derssa/Torollo
docker compose up --build -d
```What it's built on#
- Languages
- JavaScriptTypeScript
- Frameworks
- ExpressReact
- Infrastructure
- Docker
FAQ#
Does Torollo require a cloud account or internet connection to run?
No. Torollo runs entirely on your local Docker daemon. Once the node images are downloaded on first run, it works offline. No cloud account, no remote infrastructure, and nothing leaves your machine unless you explicitly opt into anonymous telemetry, which is off by default and asks once on the home screen.
What Docker setup does Torollo require?
Docker must be running and your user must have access to the Docker socket. Most features work with rootless Docker, but VPC subnets, NAT, and cross-subnet security groups require a rootful daemon because they use host iptables rules. Run npx torollo doctor before starting to check your Node.js version, Docker access, port availability, and disk space.
How many learning roadmaps does Torollo ship with?
Three intermediate roadmaps are included: deploying a resilient three-tier app (roughly 40 minutes), cache-aside with Redis (roughly 45 minutes), and workers with a Redis job queue (roughly 40 minutes). The JSON roadmap format is open and documented, so community authors can publish additional roadmaps that users import from the Learning page without a repo checkout.
Is Torollo safe to run on a shared or remote server?
Not without additional configuration. The API binds to 127.0.0.1 by default and has no authentication layer. Anyone who can reach the port inherits control of the host Docker daemon. For single-user local use this is safe. For a shared or remote setup, put Torollo behind an authenticating reverse proxy before exposing it on the network.
Can instructors use Torollo for classroom labs without cloud costs?
Yes. Torollo runs locally on each student's machine and has no per-seat or per-session cost. Instructors write lab exercises in the JSON roadmap format and distribute them as zip files. Students import the roadmap from the Learning page and run the full lab on their own Docker setup, with no cloud budget required.
Similar open-source tools#
context-mode
Cuts LLM context use by up to 98% per session via local MCP sandbox
FckSignups
Open-source tools that work instantly, no signup required
ship-safe
Security scanner for AI agents, MCP servers, and LLM codebases.
tuicr
Terminal UI for code review with vim keybindings and GitHub-style
agent-toolkit-for-aws
Empower AI agents to build and manage AWS applications
no-mistakes
Automate clean PRs with gated Git pushes