Containerlab's YAML files,
on a canvas that is built in.
Containerlab is the cleanest way to spin up container-native labs from the command line - and it is free and open source. netplex. isn't here to argue with that. It reads the same YAML files and keeps the same lab-as-code way of working, then adds a canvas that is part of the product, real vendor virtual machines without building each image yourself, and a browser as the only thing you install. Containerlab now has a canvas of its own (TopoViewer), so this page is about which setup suits you, not which one has a screen.
Containerlab is command line and YAML first - brilliant for automation engineers. It also has a graphical editor now: TopoViewer, the same canvas in a VS Code extension, a Desktop app and a browser Web GUI (the Web GUI needs Containerlab's optional API server running on a Linux lab host). netplex. keeps the YAML and the CLI and builds the canvas into the product, so there is one thing to run and nothing to assemble. Both are real options - the table below shows where each one leads.
A great tool - if you live in the command line.
Not everyone does.
Topologies start as hand-written YAML
Every topology starts as a hand-written .clab.yml: nodes, kinds, endpoints, link lists. TopoViewer can edit that visually in VS Code, the Desktop app or the browser Web GUI. The Web GUI is a separate piece to set up: a container image plus an API server on the Linux lab host. netplex. has its canvas built in from the first start.
Vendor VMs mean the vrnetlab hassle
Containers are effortless. Real vendor VMs - vMX, vSRX, CSR, XRv - are not: each one is a vrnetlab image you build yourself (with the srl-labs fork of vrnetlab - images from the upstream project will not work).
A Linux host with Docker
Containerlab needs a Linux host or VM with Docker. On macOS it runs inside a Linux VM (OrbStack) or a devcontainer, where many vendor images lack ARM64 builds and VM-based nodes need an M3 chip or newer on macOS 15. On Windows it runs under WSL or a devcontainer. netplex. also needs a server: an x86-64 Linux host or the appliance image. Its difference is that you use it from a plain browser.
Consoles and capture depend on the app you pick
With Containerlab you reach a node through its GUI apps, or with docker exec / SSH and host tcpdump. netplex. puts the console and packet capture for every node and link in the same browser tab as the canvas.
Containerlab vs netplex.
Same YAML. More ways in.
| Feature | Containerlab Free / open source |
netplex. Tier shown per row |
|---|---|---|
| Lab-as-code (YAML) | Yes - the whole model | Yes - .npx + YAML export |
| Deploy / destroy / inspect CLI | Yes - clab deploy/destroy/inspect | Yes - netplex CLI + Python SDK |
| Visual canvas editor | Yes - TopoViewer, in a VS Code extension, a Desktop app and a browser Web GUI (the Web GUI needs the optional API server on a Linux lab host) | Yes - full browser Studio, built in |
| Where the lab runs | A Linux host or VM with Docker | An x86-64 Linux host or the appliance image; you use it from any browser |
| macOS / Windows | macOS via an OrbStack Linux VM or devcontainer (many vendor images lack ARM64; VM-based nodes need M3+ and macOS 15); Windows via WSL or devcontainer | Browser on any OS (the lab host must be x86-64 Linux) |
| Container nodes | Yes - native, its core strength | Yes - any Docker image |
| Full vendor VMs (vMX, vSRX, CSR…) | 27 VM kinds via vrnetlab - you build each image yourself with the srl-labs fork | Drop a qcow2 → vendor profile auto-applied |
| Import existing vrnetlab container images | Native for the 27 VM kinds, but only images built with the srl-labs/vrnetlab fork work | A curated set natively (e.g. MikroTik CHR) - outside that, bring the qcow2, run via QEMU |
| Import your .clab.yml topology | - | Yes - via the netplex CLI / API |
| Link impairment: delay / jitter / loss / rate | Yes - tc / netem | Three presets (Good / Poor / Bad) on every tier; custom delay, jitter, loss and rate on Professional |
| AI agent access (MCP) | No official one; a community (experimental) Containerlab MCP server exists | MCP server (beta), 80+ tools; read-only below Architect |
| Browser consoles + packet capture | Through the GUI apps, or docker exec / SSH with host tcpdump | Browser console and capture on every tier |
| Built-in tool nodes (scanner, multicast, traffic) | No | Yes - network scanner, multicast, traffic generator and bandwidth tester nodes (Professional) |
| Built-in switch and router nodes (no image needed) | No | Yes - a built-in switch and Linux router start instantly |
| Lab backup to GitHub / git | No | Yes - push backups to GitHub, GitLab or any git remote |
| Scheduled backups to SSH / SFTP / SMB / cloud | No | Yes - on a timer, to your own SSH/SFTP or SMB server or cloud storage |
| LXC container nodes | No | Yes - LXC nodes |
| Network-namespace nodes (about 50 ms start) | No | Yes - lightweight namespace nodes, no image |
| MicroVM nodes (Firecracker) | No | Yes - Firecracker MicroVM nodes (beta) |
| Themes and accent colours | Yes | Yes - 6 themes and 9 accent colours |
| Export the topology as PNG / PDF / SVG | Yes | Yes - PNG (1x-3x, transparent), PDF or SVG |
| Presentation mode (laser, spotlight, pen) | No | Yes - laser pointer, spotlight, pen and annotation (Professional) |
| Export to draw.io / Mermaid / Graphviz / SSH config / Nornir | Yes | Yes - draw.io, Mermaid, Graphviz, SSH config, hosts file, Nornir inventory |
| Freeze points and lab branches | No | Yes - freeze a lab, restore it, or branch a new lab from it (Professional) |
| Read-only share link for a live lab | Yes | Yes - a link anyone can watch, nobody can change (Professional) |
| Recently deleted labs (restore within days) | No | Yes - restore a deleted lab within 3 days (labs that had a backup repository) |
| Coloured tags on devices | No | Yes - free-text tags, each with its own colour |
| Start-up configs pasted at first boot, named sets | Yes | Yes - paste once, switch between named sets |
| Windows / Linux desktops in a browser tab | No | Yes - RDP and VNC desktops in the browser |
| Host dashboard (CPU / RAM history and alerts) | No | Yes - 1-hour and 24-hour history, email/webhook alerts |
| Edit the lab as code next to the canvas | Yes | Yes - a JSON code panel kept in sync with the drawing |
| Pull and restore cables while the lab runs | No | Yes - take a link down and bring it back live (Professional) |
| Smart image import (auto-detect, disk guard, boot test) | No | Yes - names the image, refuses when the disk is too full, boot-tests it |
| Push your own code as a device | No | Yes - CLI, VS Code task or git hook |
| IPv6 labs | Yes | Yes - IPv6 addresses and traffic between nodes |
| UI in 5 languages | No | Yes - English, Arabic (right-to-left), Chinese, Spanish and French |
| Restore centre (lab history, file or whole platform) | Partial - 'save' command stores node configs; no restore UI | Yes - restore a lab from history or a file, or the whole platform from a snapshot (admin) |
| Gateway node to the internet or host network | Partial - Bridge kind and mgmt network reach outside; no gateway node | Yes - a Cloud gateway node, NAT or bridge, the only way out of a lab |
| Config drift detection | No | Yes - compares a saved golden config with the running one (Professional) |
| Live traffic animation on cables | No | Yes - links flash as packets flow (Professional) |
| Native console connector (your own terminal) | Partial - VS Code extension offers ssh/telnet actions on nodes | Yes - opens consoles in SecureCRT, PuTTY, Windows Terminal, iTerm2 and more |
| Side-by-side config diff viewer | No | Yes - one diff viewer with a commit picker and restore button |
Checked against Containerlab v0.81.0 (released 11 Oct 2026), containerlab.dev docs, 12 Oct 2026. netplex. rows are checked against the platform source. Rows where Containerlab leads are marked honestly.
Keep your YAML. Try a built-in canvas.
Same lab-as-code workflow, plus a built-in visual canvas and real vendor VMs without building each image.
When Containerlab is the right pick
Containerlab is open source and free, and it now has a canvas too (TopoViewer in VS Code, a Desktop app and a browser Web GUI). It offers custom delay, jitter, loss and rate on its free install; netplex. gives presets on every tier and custom values on Professional. If your entire workflow is clab deploy inside a CI runner and nothing else, Containerlab is already perfect - netplex. speaks the same YAML, so you can try it without rewriting a single lab.
Keep the YAML. Add everything a CLI can't give a team.
netplex. is a server, not a command-line tool. The same lab-as-code you already write can be reached from a browser and from your CI pipeline at the same time.
A canvas over your code
Build by dragging nodes and drawing links, or write .npx/YAML by hand - both are first-class and stay in sync. People who love the command line keep it; everyone else gets a picture they can edit.
Vendor VMs without vrnetlab
Drop a qcow2 into the Library and the image pipeline classifies it, applies the vendor's recommended CPU/RAM/NIC profile and boot-tests it. No per-image build step.
Any browser, any OS
The netplex. host runs the lab; you drive it from any modern browser on any OS. The host itself must be x86-64 Linux (or the appliance image), and needs nested virtualization if that host is itself a VM.
Import your .clab.yml
Point the netplex. CLI or API at an existing topology.clab.yml. Nodes, kinds, links and inline configs map to the .npx model; external config-file references are flagged so nothing goes missing silently.
An MCP server, not just a CLI
You automate with YAML today - an AI agent can also work with the same lab over MCP (beta, 80+ tools). It is read-only below the Architect tier. · beta
Console and capture in the same tab
Open a node's console and capture a link's traffic from the same browser tab as the canvas, on every tier.
Test your app on a real network
Push your code, link it to a database, add delay or packet loss and run your tests, all from your own computer with one netplex dev up. See how →
Your topology file is already valid input.
Nothing to rewrite.
Keep your .clab.yml
Your existing topology.clab.yml stays exactly as it is - it's the input, not something to convert by hand.
Import via CLI or API
Point the netplex. CLI or REST API at the file. Kinds, nodes, links and inline configs map across; external file refs are flagged, not dropped.
Drive it from a browser
Open the canvas, start the lab, console into any node and capture packets - all from a browser.
Kinds mapped
Container types become Docker nodes; vr-* types become QEMU vendor nodes; bridge and ovs-bridge become switch nodes.
Inline configs carry
Startup config embedded inline in the topology imports as an active profile. External config-file paths are surfaced as warnings.
EVE-NG and GNS3 too
The same importer family handles EVE-NG .unl and GNS3 .gns3project - consolidate every lab format into one platform.
Containerlab to netplex.
The questions people actually ask.
Last reviewed October 2026 · Spotted something out of date? Tell us.
Keep the CLI you love.
Give the lab a front door.
Start on the free Associate tier. Import a .clab.yml, open the canvas, and hand your team a browser link instead of a Docker setup guide.