Torollo is an open source visual playground for learning system design, networking, and backend components locally. My short verdict: the idea is excellent for making infrastructure more concrete, the interface is already useful, but the real value depends on one non-negotiable prerequisite: having Docker available on the machine.
I tested it the way I would for a client tool or an internal workshop: cloning the repo, installing, building, launching, creating a mini network scenario, calling the APIs, taking screenshots, then checking the real limits.
What is Torollo?
Torollo presents itself as a Packet Tracer for backend developers. Instead of drawing an architecture in a static tool, you work with building blocks like a VPC, subnets, an Ubuntu server, PostgreSQL, Redis, MongoDB, an Nginx load balancer, or a NAT Gateway.
The promise is straightforward: each visual node maps to a local component driven by Docker. The Node.js backend talks to the Docker daemon via Dockerode, while the React frontend renders the canvas, nodes, network settings, terminals, and database explorers.
| Point tested | Observed result |
|---|---|
| Repository | GitHub Derssa/Torollo, commit 533ece2 at time of test |
| Stack | React, TypeScript, Vite, Node.js, Express, Socket.io, Dockerode |
| Installation | npm ci for backend and frontend, then TypeScript and Vite build |
| Launch | Express backend on 23233, frontend served on 23232 |
| Use case | “Mini Torollo web network” project with VPC, public subnet, private subnet |
| Local Docker | Not available in my sandbox, clean DOCKER_UNAVAILABLE error |
| Automated tests | Backend OK, frontend with 1 timeout out of 107 |
Installing Torollo
The documented path is very short:
npx torollo start
I ran it too. In my Linux sandbox, the CLI stops cleanly before starting because Docker is not installed:
[i] Checking system requirements...
[x] Error: Docker is not installed or not running on your machine.
[!] LINUX DETECTED:
[>] Run: curl -fsSL https://get.docker.com | sh
From the source repo, I followed the developer path to verify the build, the API, and the UI:
git clone https://github.com/Derssa/Torollo /tmp/torollo-scout
cd /tmp/torollo-scout
npm --prefix backend ci
npm --prefix frontend ci
npm --prefix backend run build
npm --prefix frontend run build
One practical detail: /tmp was mounted in a way that blocked execution of the esbuild binary. So I kept the reference clone in /tmp, then copied the project into an executable temp folder to install and build. That is not a Torollo issue, just a classic quirk of containerized test environments.
The frontend build passes, with a Vite warning about bundle size:
✓ 2025 modules transformed.
dist/assets/index-B7zHWCM1.js 1,096.70 kB │ gzip: 302.11 kB
(!) Some chunks are larger than 500 kB after minification.
The TypeScript backend build also passes. On the dependencies side: no LLM key, no OpenAI, no OpenRouter. Torollo is not an agentic tool, it mainly orchestrates local Docker.
Torollo in practice
I launched the backend and frontend, then created a project called “Mini Torollo web network”. I then injected a realistic network configuration: a VPC at 10.0.0.0/16, a public subnet at 10.0.1.0/24, and a private subnet at 10.0.2.0/24.
The API correctly persisted that scenario:
save_network: {"success":true}
get_network: {
"nodes": 6,
"edges": 5,
"labels": [
"VPC prod",
"Subnet public",
"SG web",
"Nginx LB",
"Ubuntu app",
"Redis cache"
]
}
I also tested the interface in a headless browser at 1280 x 720. It correctly renders the project, the VPC, both subnets, their CIDRs, the grid buttons, the routes, the node library, and the Docker status banner.
The important point is how it behaves when Docker is not available. My sandbox has neither a Docker binary nor a /var/run/docker.sock socket. Torollo does not crash blindly. The healthcheck responds in degraded mode:
{"status":"degraded","checks":{"docker":{"status":"unreachable","error":"connect ENOENT /var/run/docker.sock"}}}
And creating an Ubuntu container returns a usable error:
{"error":"Cannot reach the Docker daemon. Make sure Docker is running on your machine, then retry.","code":"DOCKER_UNAVAILABLE"}
Frustrating for a complete test, but actually reassuring from a product quality standpoint: the tool knows how to explain the missing prerequisite instead of hiding the problem.
What I like about Torollo
The biggest strength is learning through hands-on manipulation. When explaining a VPC, a public subnet, a private subnet, a Redis cache, or a load balancer, an interactive canvas communicates more than a static slide diagram.
I also like the local-first approach. No cloud account needed, no surprise AWS bill, no IAM permissions to hand out to students or a junior team. In theory, everything stays on the machine.
Another good point: Docker errors are categorized cleanly. The backend has tests covering DOCKER_UNAVAILABLE, image not found, port already in use, and missing container cases. For a tool that manages containers, that is essential.
Finally, the UI is already quite readable. You can see the project, the VPC, the subnets, the routes, and the node library. Even with Docker absent, I was able to verify that the project model and network configuration were persisted and read back correctly.
The limits of Torollo
The main limitation is structural: without Docker, Torollo loses its superpower. You can build a graph and explore the interface, but you cannot validate terminals, PostgreSQL, Redis, Nginx, iptables, NAT, or real traffic between containers.
The second limitation is maturity. The frontend ran 107 tests, 106 passed, but one PostgreSQL modal test timed out. Not a dealbreaker for a young open source project, but I would not sell it as a critical training tool without another quality pass.
I also spotted a few signs of early-stage development: an old internal name “Akal” showing up in localStorage keys and some types, a large frontend bundle, and a static server that needs careful handling in source mode. Nothing insurmountable, but it confirms this is a promising tool, not a finished SaaS-grade product.
Does Torollo actually work?
Yes, for installation, building, web launch, project creation, network configuration saving, and clean handling of a missing Docker daemon.
I cannot confirm that the Docker orchestration works end to end in this specific test, because my environment does not give access to the Docker daemon. And I would rather say that clearly: I did not validate a real Ubuntu container, a live Redis instance, or actual iptables rules.
What I did observe is still useful: Torollo produces a workable interface, persists a network model, exposes coherent APIs, and fails gracefully when its main runtime is missing.
Should you adopt Torollo?
My verdict: try it, especially for learning, system design workshops, or internal demos.
I would not adopt it yet as a stable component of a training curriculum without testing on a machine with full Docker access and a few reproducible scenarios: Ubuntu server, Redis, PostgreSQL, load balancer, security rules, connectivity testing.
For a freelance security or DevOps engineer, Torollo can become a solid tool for explaining concepts visually. For production, obviously not. For learning, prototyping, and making networking visible, it clearly deserves a try.
FAQ
Does Torollo replace Docker Compose?
No. Torollo is mainly for learning and visualization. Docker Compose remains better suited for defining a reproducible stack in a real project.
Can you use Torollo without Docker?
You can open the interface and interact with part of the model, but the main value disappears. Containers, terminals, and live services all need the Docker daemon.
Is Torollo suitable for beginners?
Yes, as long as Docker is already installed and running. The interface makes networking concepts more concrete, but you still need to know the basics: subnets, ports, services, containers, and databases.