Torollo est un playground visuel open source pour apprendre le system design, le réseau et les composants backend en local. Mon verdict court : l’idée est excellente pour rendre l’infra plus concrète, l’interface est déjà utile, mais le vrai intérêt dépend d’un prérequis non négociable, avoir Docker disponible sur la machine.
Je l’ai testé comme je testerais un outil pour un client ou pour un atelier interne : clone du dépôt, installation, build, lancement, création d’un mini scénario réseau, appel des API, captures d’écran, puis vérification des limites réelles.
Torollo, c’est quoi ?
Torollo se présente comme un Packet Tracer pour développeurs backend. Au lieu de dessiner une architecture dans un outil figé, on manipule des briques comme un VPC, des subnets, un serveur Ubuntu, PostgreSQL, Redis, MongoDB, un load balancer Nginx ou un NAT Gateway.
La promesse est simple : chaque noeud visuel correspond à un composant local piloté par Docker. Le backend Node.js parle au démon Docker via Dockerode, tandis que le frontend React affiche le canvas, les noeuds, les réglages réseau, les terminaux et les explorateurs de bases.
| Point testé | Résultat observé |
|---|---|
| Dépôt | GitHub Derssa/Torollo, commit 533ece2 lors du test |
| Stack | React, TypeScript, Vite, Node.js, Express, Socket.io, Dockerode |
| Installation | npm ci backend et frontend, puis build TypeScript et Vite |
| Lancement | Backend Express sur 23233, frontend servi sur 23232 |
| Cas d’usage | Projet “Mini réseau web Torollo” avec VPC, subnet public, subnet privé |
| Docker local | Non disponible dans ma sandbox, erreur propre DOCKER_UNAVAILABLE |
| Tests automatisés | Backend OK, frontend avec 1 test en timeout sur 107 |
Installation de Torollo
La voie documentée est très courte :
npx torollo start
Je l’ai aussi lancée. Dans ma sandbox Linux, la CLI s’arrête proprement avant de démarrer, car Docker n’est pas installé :
[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
Dans le dépôt source, j’ai donc suivi le chemin développeur pour vérifier le build, l’API et l’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
Premier détail pratique : /tmp était monté de façon à bloquer l’exécution du binaire esbuild. J’ai donc gardé le clone de référence dans /tmp, puis copié le projet dans un dossier temporaire exécutable pour installer et builder. Ce n’est pas un problème Torollo, plutôt un classique des environnements de test conteneurisés.
Le build frontend passe, avec un avertissement Vite sur la taille du bundle :
✓ 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.
Le build backend TypeScript passe aussi. Côté dépendances, pas de clé LLM, pas d’OpenAI, pas d’OpenRouter. Torollo n’est pas un outil agentique, il orchestre surtout du Docker local.
Torollo à l’usage
J’ai lancé le backend et le frontend, puis j’ai créé un projet nommé “Mini réseau web Torollo”. Ensuite, j’ai injecté une configuration réseau réaliste : un VPC 10.0.0.0/16, un subnet public 10.0.1.0/24 et un subnet privé 10.0.2.0/24.
L’API a bien persisté ce scénario :
save_network: {"success":true}
get_network: {
"nodes": 6,
"edges": 5,
"labels": [
"VPC prod",
"Subnet public",
"SG web",
"Nginx LB",
"Ubuntu app",
"Redis cache"
]
}
J’ai aussi testé l’interface au navigateur headless en 1280 x 720. Elle affiche correctement le projet, le VPC, les deux subnets, leurs CIDR, les boutons de grille, les routes, la bibliothèque de noeuds et le bandeau d’état Docker.
Le point important, c’est la réaction quand Docker n’est pas disponible. Ma sandbox n’a ni binaire Docker ni socket /var/run/docker.sock. Torollo ne plante pas bêtement. Le healthcheck répond en mode dégradé :
{"status":"degraded","checks":{"docker":{"status":"unreachable","error":"connect ENOENT /var/run/docker.sock"}}}
Et une création de conteneur Ubuntu renvoie une erreur exploitable :
{"error":"Cannot reach the Docker daemon. Make sure Docker is running on your machine, then retry.","code":"DOCKER_UNAVAILABLE"}
C’est frustrant pour le test complet, mais c’est plutôt rassurant côté qualité produit : l’outil sait expliquer le prérequis manquant au lieu de masquer le problème.
Ce que j’aime dans Torollo
Le gros point fort, c’est la pédagogie par manipulation. Pour expliquer un VPC, un subnet public, un subnet privé, un cache Redis ou un load balancer, un canvas interactif parle mieux qu’un schéma figé dans un slide.
J’aime aussi l’approche local first. Pas besoin de compte cloud, pas de facture AWS surprise, pas de permissions IAM à distribuer à des étudiants ou à une équipe junior. En théorie, tout reste sur la machine.
Autre bon point : les erreurs Docker sont classées proprement. Le backend a des tests sur les cas DOCKER_UNAVAILABLE, image introuvable, port déjà pris et conteneur absent. Pour un outil qui manipule des conteneurs, c’est indispensable.
Enfin, l’UI est déjà assez lisible. On voit le projet, le VPC, les subnets, les routes, la bibliothèque de noeuds. Même avec Docker absent, j’ai pu vérifier que le modèle de projet et la configuration réseau étaient persistés et relus.
Les limites de Torollo
La limite principale est structurelle : sans Docker, Torollo perd son super pouvoir. On peut préparer un graphe et tester l’interface, mais pas valider les terminaux, PostgreSQL, Redis, Nginx, iptables, NAT ou le vrai trafic entre conteneurs.
La deuxième limite, c’est la maturité. Le frontend a lancé 107 tests, 106 sont passés, mais un test de modal PostgreSQL a fini en timeout. Ce n’est pas dramatique pour un projet open source jeune, mais je ne le vendrais pas comme outil de formation critique sans refaire une passe qualité.
J’ai aussi vu quelques signes de jeunesse : ancien nom interne “Akal” dans les clés localStorage et certains types, gros bundle frontend, serveur statique à manier avec soin en mode source. Rien d’insurmontable, mais ça confirme qu’on est sur un outil prometteur, pas sur un produit fini façon SaaS.
Est-ce que Torollo marche vraiment ?
Oui pour l’installation, le build, le lancement web, la création de projet, la sauvegarde de configuration réseau et la gestion propre de l’absence de Docker.
Je ne peux pas affirmer que l’orchestration Docker marche de bout en bout dans ce test précis, car mon environnement ne donne pas accès au démon Docker. Et je préfère le dire clairement : je n’ai pas validé un vrai conteneur Ubuntu, un Redis live ou des règles iptables réelles.
Ce que j’ai observé est quand même utile : Torollo produit une interface exploitable, persiste un modèle réseau, expose des API cohérentes et échoue proprement quand son runtime principal manque.
Faut-il adopter Torollo ?
Mon verdict : essayer, surtout pour de la pédagogie, des ateliers system design ou des démos internes.
Je ne l’adopterais pas encore comme brique stable d’un parcours de formation sans un test sur une machine avec Docker complet et quelques scénarios reproductibles : serveur Ubuntu, Redis, PostgreSQL, load balancer, règles de sécurité, test de connectivité.
Pour un freelance sécu ou DevOps, Torollo peut devenir un bon support de vulgarisation. Pour de la prod, évidemment non. Pour apprendre, prototyper et rendre le réseau visible, il mérite clairement un essai.
FAQ
Torollo remplace-t-il Docker Compose ?
Non. Torollo sert surtout à apprendre et visualiser. Docker Compose reste plus adapté pour définir une stack reproductible en projet réel.
Peut-on utiliser Torollo sans Docker ?
On peut ouvrir l’interface et manipuler une partie du modèle, mais l’intérêt principal disparaît. Les conteneurs, terminaux et services live ont besoin du démon Docker.
Torollo est-il adapté aux débutants ?
Oui, à condition d’avoir Docker déjà installé et fonctionnel. L’interface rend les concepts réseau plus concrets, mais il faut quand même connaître les bases : subnet, port, service, conteneur et base de données.