Torollo

449 stars
MIT
Active this month
Last commit 27 days ago

Last verified Oct 21, 2026

Build real backend architectures on a local canvas where every node is a live Docker container, with roadmaps that grade each step against your running system.

Visit website GitHub449 Deploy on Hostinger

Read the full breakdownWho it is for, how it works, trade-offs, the quick start and the FAQ

who it's for

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

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 Torollo solves it

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 · trade-offs

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.

versus alternatives

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.

install · quick start

Quick start#

bash

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
```

tech stack · detected from GitHub

What it's built on#

Languages: JavaScriptTypeScript
Frameworks: ExpressReact
Infrastructure: Docker

frequently asked

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.

also worth a look

Similar open-source tools#

Kamal

Alternative toFly.io

Zero-downtime Docker deploys to any server, no managed platform.

14,675 GitHub stars
Licence MIT

CapRover

Alternative toHeroku

Self-hosted PaaS: deploys any language, automatic HTTPS, zero fees.

15,187 GitHub stars
Licence Apache-2.0 with additional terms

Dokploy

Alternative toHeroku

Self-hosted PaaS to deploy apps and databases across multiple servers

37,935 GitHub stars

Forgejo

Alternative toGitHub

Self-hosted Git forge for teams that want platform independence

5,688 GitHub stars
Licence GPL-3.0

OneDev

Alternative toGitHub

Git, CI/CD, issue tracking, wikis, and AI agents on your own server.

15,318 GitHub stars
Licence MIT

Statlite

InSecurity & Monitoring

Self-hosted Spring Boot monitoring, no Prometheus or Grafana needed

177 GitHub stars
Licence MIT

by category

Open source tools in these categories#

463

Developer Tools

REA (Reverse Engineer Anything), superpowers, Skills for Real Engineers 88

DevOps & CI/CD

Nvm, Uptime Kuma, Netdata

Hostinger

Run Torollo on your own server

Self-host Torollo on a Hostinger VPS.

Deploy on Hostinger

Featured

Inbox Zero

Alternative toSuperhuman

AI email assistant that drafts replies and clears your inbox

12,712 GitHub stars
Licence AGPL-3.0
#Email

Omnara

Alternative toClaude Managed Agents

Open-source agent deployment API. Self-host or use Omnara Cloud.

2,957 GitHub stars
Licence Apache-2.0
#AI Agents

rakazo

Alternative toGrok Bot

AI teammates you own: your keys, your model, your machine.

4,904 GitHub stars
Licence Apache-2.0
#AI Agents

Feature your project

The projects we add and every new guide. Free, unsubscribe any time.

Find open source alternatives to paid software

Torollo vs Cloud-Based Backend Lab Platforms

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 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