Build a Network Digital Twin from NetBox with AI (That You Can Actually Run)

A runnable network digital twin is a working replica of your network — real network operating systems, real CLIs, real protocol state — built from the device, interface, cabling, and IP data you already maintain in NetBox — sites without cable/connection records need the links described in the prompt or filled in first. Unlike a model-based twin, you can SSH into it, break it, and rehearse a change on it before production ever sees that change. And as of 2026, you no longer need to hand-assemble an exporter pipeline to get one: an AI agent with read-only access to your NetBox can design, deploy, and validate the twin from a single prompt. This guide covers the three ways to build a network digital twin from NetBox — and when each one is the right choice.

Three Generations of the NetBox Digital Twin

The idea of generating a lab from your source of truth isn't new. Credit where it's due: the pattern was proved in the open-source community, with netreplica/nrx — an exporter that reads a NetBox site and emits Containerlab topology files — and srl-labs/netbox-nrx-clab, the srl-labs worked example that wires NetBox, nrx, and Containerlab into an end-to-end pipeline. By 2024 that stack showed that "SoT in, lab out" was a real workflow, not a slide. What it didn't remove was the manual labor around it.

Generation 2 deserves a fair reading. Platforms like Forward Networks build a mathematical model of your network from collected configuration and state, then run formal analysis over it — every reachable path, every policy interaction, at a scale no emulated lab can match. That is a genuinely hard problem solved well. The trade is fundamental, though: a model has no running NOS code. You can't log in, you can't watch OSPF converge, and you can't paste in the exact change from your change ticket to see what breaks.

Generation 3 closes that gap. NetPilot ships a read-only NetBox connector: the AI agent queries your sites, devices, interfaces, and IP addressing, designs a matching topology, generates per-vendor configurations, and deploys the twin on real network operating systems in the cloud. You get a lab you can actually run — and an agent that already knows what's in it.

Bottom line: a model-based twin answers "can this ever happen?" at production scale; a runnable twin answers "what actually happens when I execute this change?" For pre-change rehearsal, NetPilot builds a running twin of a NetBox site on real NOSes from a single plain-English prompt — prompt to deployed lab in ~2 minutes, SSH access included.

Connect Your NetBox First (Read-Only, About Five Minutes)

Setup happens in the chat composer: click + → Connectors, add a label, your NetBox MCP server's HTTPS URL, and the endpoint's auth token, then hit Add & test connection. NetPilot performs a live handshake against your NetBox MCP endpoint and only enables the connector when the test passes. A few properties worth knowing before you point anything at your source of truth:

• Read-only by construction. The agent is only ever offered a curated allow-list of read tools — exact names, no wildcards, enforced server-side. There is no write path to your NetBox data, so there is nothing to accidentally mutate.
• Tokens are write-only secrets. Your API token is encrypted at rest and never displayed again after you save it. Endpoints must be HTTPS.
• It's your NetBox. The connector talks to your own NetBox instance with a static API token — the data never has to be copied into NetPilot to be useful.

The same flow works for Nautobot — Network to Code's fork of NetBox, forked in 2021 from NetBox v2.10 and independently developed since. Whichever source of truth you run, the loop below is identical. The full connector catalog and security model live on the integrations hub.

The Rehearsal Loop: From "Twin of Site X" to a Pre/Post Change Diff

Here is the end-to-end workflow the connector was built for — rehearsing a real change on a twin of the real site.

Step 1 — Build the twin from NetBox

"Build a lab twin of site DFW01 from NetBox — core and distribution layers only. Keep the real hostnames, interface names, and IP addressing."

The agent queries NetBox through the read-only tools, pulls the devices, links, and prefixes for DFW01, designs the matching topology, generates a per-vendor config for each node, and deploys it on real NOSes. You review the design before anything boots.

Direct CLI is always available once it's up. SSH into any node and check it against what NetBox says should be there:

dfw01-core-01# show ip interface brief
dfw01-core-01# show ip ospf neighbor
dfw01-core-01# show run interface TenGigabitEthernet1/0/1

Step 2 — Capture the baseline

"Capture a pre-change baseline across all twin devices: routing tables, OSPF and BGP neighbors, interface states."

The agent runs the right command per vendor in parallel — show ip bgp summary on Cisco, show bgp summary on Junos, the vtysh variant on FRR — and consolidates the results into one baseline table. If you'd rather pull the baseline by hand, every device is a normal SSH target; the agent's fast path and your terminal see the same boxes.

Step 3 — Apply the change to the twin, not to production

"Apply the change from ticket CHG-4182: migrate the DFW01 distribution uplinks to the new /31 addressing and update OSPF. Here's the config snippet."

The agent pushes the candidate change to the twin exactly as written. Typos, missed no shutdown lines, and wrong-interface mistakes surface here — on disposable infrastructure, with real NOS parsers rejecting real syntax errors.

Step 4 — Diff and verdict

"Compare current state against the baseline. Flag anything that changed that shouldn't have."

You get a pre/post diff with anomalies flagged: an OSPF adjacency that didn't re-form, a route that vanished, a prefix now reachable that wasn't before. Drill into anything suspicious over SSH before you sign off the change window. This is the pre-change validation loop, run against a twin built from your own source of truth instead of a hand-drawn approximation.

A companion loop worth knowing: drift detection. The agent reads intended state from NetBox and compares it against the twin — and, if you opt in to the Nornir connector, against production itself — read-only show commands only, enforced server-side, with device credentials brokered from your Nautobot at call time. NetPilot stores neither credentials nor device inventory.

Model-Checked vs Actually Executed

The honest way to draw the line between generation 2 and generation 3:

Choose a model-based twin when the question is coverage. "Is there any path where this ACL leaks?" is a formal-verification question, and Forward Networks answers it across thousands of production devices continuously — something no emulated lab will do. Model-based platforms also shine at Day-2 operational assurance, which is not what a rehearsal lab is for.

Choose a runnable twin when the question is execution. "What happens when I paste this exact change?" cannot be answered by a model, because the answer depends on running NOS code: config parsers, protocol timers, convergence order, default behaviors that differ between software trains. A runnable digital twin executes the change on the same operating systems production runs, and hands you the CLI to verify it.

These aren't competing answers — mature teams may use both. But if your immediate problem is "rehearse Thursday night's change before Thursday night," you need something you can log into.

When DIY Is the Right Call

If your team is CI/CD-first and wants to own the YAML, the open-source pipeline is a legitimate choice, not a consolation prize. Containerlab is excellent, nrx keeps improving, and the output is a plain topology file that lives happily in Git:

name: dfw01-twin
topology:
  nodes:
    dfw01-core-01:
      kind: nokia_srlinux
      image: ghcr.io/nokia/srlinux
    dfw01-dist-01:
      kind: nokia_srlinux
      image: ghcr.io/nokia/srlinux
  links:
    - endpoints: ["dfw01-core-01:e1-1", "dfw01-dist-01:e1-1"]

Take this path when you want the exported topology as a reviewable artifact in your repo, your pipeline redeploys the twin on every merge, and you have the appetite to maintain image licensing, config generation, and validation scripting yourself. The trade is exactly that maintenance: the NetBox-to-Containerlab digital twin pipeline gives you full control of every layer because it makes you responsible for every layer. The agent-built path trades that control for a twin that designs, deploys, and validates itself from a prompt — with the YAML and configs still visible when you want to read them.

The Connectors Are the Starting Point

NetBox, Nautobot, and Nornir are the curated connectors that ship in-product — the on-ramp, not the boundary. NetPilot is MCP-connectable both ways. Connect your own AI agents to NetPilot's MCP server to build and validate labs on demand — and let NetPilot's agent connect to your stack (NetBox/Nautobot, Git, ServiceNow/Jira, CI/CD) to build pre-change validation labs from your real configs. Included with Signature & Enterprise. Every integration is custom-built to fit your workflow — if it has an API, NetPilot connects to it. The integrations hub has the current picture.

FAQ

Can I build a digital twin from NetBox data?

Yes — for sites with topology recorded: NetBox's device, interface, cable/connection, and IPAM data generates a runnable replica (where cabling isn't modeled, describe the links in the prompt). You have three routes: export it yourself with nrx into Containerlab and maintain the pipeline; feed collected state into a model-based analysis platform; or connect NetBox to NetPilot's read-only connector and let the agent design and deploy the twin on real NOSes from a prompt. The first gives you maximum control, the second gives you production-scale analysis, the third gives you a running lab with the least assembly.

What's the difference between a model-based and runnable digital twin?

A model-based twin (Forward Networks, for example) is a mathematical representation of your network built from collected configs and state — it supports formal verification across thousands of devices but contains no running network operating systems. A runnable digital twin executes real NOS images, so you can SSH in, apply the literal change from your change ticket, and watch protocols converge. Model-based answers "could this ever happen?"; runnable answers "what happens when I actually run it?"

How do I keep a digital twin in sync with NetBox?

Don't sync it — rebuild it. A runnable twin is disposable by design: when NetBox changes, ask the agent to rebuild the twin from the current source of truth, and you're aligned again in minutes. The connector is read-only by construction, so the twin never writes anything back to NetBox. For the reverse question — whether your network still matches your source of truth — run a drift check: the agent compares NetBox's intended state against the twin, or against production via read-only show commands — the production leg requires the separate Nornir connector (opt-in, credentials brokered from your Nautobot).

Can an AI agent build a digital twin automatically?

Yes — this is now a productized workflow, and the ecosystem is converging on it. NetBox Labs ships an official read-only MCP server plus NetBox Copilot (GA February 2026), with write operations reserved for their commercial platform's MCP behind branching and approval gates. Network to Code publishes an official Nautobot MCP server as part of its NautobotAI suite, and Cisco Modeling Labs 2.10 ships a first-party MCP server for Cisco-centric labs. NetPilot runs the loop end-to-end: read the SoT, design the topology, deploy on multi-vendor NOSes, capture the diff — from one prompt.

Copy-paste ready: grab the NetBox site twin rehearsal prompt and the SoT drift detection prompt, paste them into app.netpilot.io, and swap in your own site name.

Ready to run a twin instead of modeling one? See what a runnable network digital twin looks like in practice, connect your source of truth on the integrations hub, and rehearse your next change before production meets it.