Self-Hosted containerlab With an AI Chat Interface (Air-Gapped)

containerlab is the cleanest way to run real multi-vendor network labs in containers, declarative topology files, real network-OS images, fast spin-up. Its core workflow is code first: you write YAML, you run clab deploy, you SSH in. That's perfect for DevOps engineers and CI pipelines. People search "containerlab GUI" and "containerlab web interface" because they want a friendlier layer over the same engine, and the project now ships its own GUI as a VS Code extension, desktop app and web app. What it leaves to you is writing the topology and every device config.

This tutorial shows how to add that layer, specifically an AI chat + live-topology interface, over your own self-hosted containerlab host, running fully on-prem with no cloud.

containerlab is code first

A containerlab topology is a YAML file:

name: three-router-ospf
topology:
  nodes:
    r1: { kind: linux, image: frrouting/frr:latest }
    r2: { kind: linux, image: frrouting/frr:latest }
    r3: { kind: linux, image: frrouting/frr:latest }
  links:
    - endpoints: ["r1:eth1", "r2:eth1"]
    - endpoints: ["r2:eth2", "r3:eth1"]

Then sudo clab deploy -t three-router-ospf.clab.yml, then SSH into each node and configure OSPF by hand. It works beautifully, and every topology and every config is something you write yourself.

What a GUI + AI layer looks like

The agent layer on top of your host has three parts:

1. An MCP server on the containerlab host that exposes the lab, deploy, inspect, run commands, over an authenticated API.
2. An AI agent that turns plain-English intent into the topology YAML and per-vendor configs, calls the MCP server to deploy, and validates the result.
3. A live topology viewer that renders the running lab and gives you device CLI in the browser.

NetPilot On-Prem is this layer, packaged to run on your own network. You keep containerlab as the engine. You gain a chat interface, AI-authored YAML, and a GUI on top.

How it connects

NetPilot doesn't replace your containerlab host, it connects to it. The NetPilot MCP server runs on the containerlab VM and exposes the lab to the backend over an authenticated HTTP API:

The agent runs on a local LLM you operate, so the whole path — intent, YAML generation, deploy, validate — stays inside your LAN.

Walkthrough — plain English to a deployed lab

Instead of hand-writing the YAML above, describe it:

"Three FRR routers in a line running OSPF in area 0, /30s between them, and a loopback on each advertised into OSPF. Deploy it and confirm full adjacencies."

The agent writes the .clab.yml, generates the per-router OSPF config, deploys it through the MCP server, and reads back the adjacency state to confirm it converged — then shows you the live topology.

Full containerlab and CLI access stays underneath. Nothing is hidden behind the agent:

# Inspect the running lab with native clab
sudo clab inspect -t three-router-ospf.clab.yml
 
# SSH into a node and verify OSPF by hand
ssh admin@clab-three-router-ospf-r1
vtysh
show ip ospf neighbor
show ip route ospf

Then iterate conversationally — "add a fourth router and make it an ABR into a new area 1" — and the agent edits the topology and configs and redeploys. You're getting the GUI/AI ergonomics and the raw clab workflow, not one or the other.

Self-hosted and air-gapped

Because the agent, the containerlab host, and the model all run on your network, the whole thing can be fully air-gapped:

• NetPilot On-Prem installs from a signed offline bundle.
• Device images are bring-your-own (BYOI), staged on the containerlab host and never pulled at runtime. FRR and Nokia SR Linux are built in, and Cisco, Juniper, Arista, Palo Alto, Fortinet, Aruba, Dell, and MikroTik are BYOI. MikroTik RouterOS (CHR) and SONiC (community VS) are preloaded on every lab VM, replaceable with your own versions.
• The local LLM keeps every inference on the LAN.

No telemetry, no phone-home, no outbound connectivity at runtime, the same offline guarantee you already get from self-hosted containerlab, now with an AI agent and a GUI on top.

FAQ

Does containerlab have a GUI?

containerlab has its own GUI, built on TopoViewer, as a VS Code extension, desktop app and web app. To add an AI chat layer on top, NetPilot On-Prem connects over an authenticated MCP server, lets you describe topologies in plain English, deploys them, and renders the live topology with in-browser device CLI.

Can I add AI to a self-hosted containerlab?

Yes. NetPilot On-Prem runs an AI agent on a local LLM that connects to your existing containerlab host over MCP. It writes the YAML and per-vendor configs, deploys via clab, and validates, while you keep full clab and SSH access underneath. Fully on-prem, no cloud.

Is the containerlab AI layer air-gapped?

It can be. NetPilot On-Prem installs from a signed offline bundle, runs the model locally, and makes no outbound calls at runtime, the agent, the containerlab host, and the LLM all run on the same LAN.

Copy-paste ready: The all-vendors OSPF area 0 prompt in our example library is a good lab to deploy on your own containerlab host through the agent.

Related reading: On-Prem AI Network Lab is the full air-gapped deployment. Run a Network AI Agent on a Local LLM covers the model, and Building an Air-Gapped Network Lab covers the offline lab itself.

Want an AI + GUI layer over your containerlab host? The On-Prem AI Network Lab page covers the deployment, contact sales to scope it for your network.