Introducing NetBox Designs: Standard Builds Without the Manual Entry

Most network and infrastructure teams already know what a standard rack, store, or cell site should look like. The standard lives in a spreadsheet or a diagram, and every new build still goes into the system of record by hand. One rack can mean a site, the rack itself, dozens of devices and modules, and hundreds of interfaces, cables, prefixes, and IP addresses, entered one object at a time.

Hand entry has no way to enforce a standard. Every mistake lands in the system of record, and the automation that renders config from it inherits each one. Copies of the same standard drift apart. Some teams build their own answer with templates, variables, and a rendering engine that writes into NetBox, but that pipeline depends on the one or two engineers who maintain it.

NetBox Designs turns a standard build into a reusable design on the NetBox Labs platform. An operator picks a design from the catalog, fills in a few variables, and reviews a plan of every object before applying it, so a rack that took hundreds of hand entries becomes one reviewed apply. For infrastructure leaders, rollouts keep pace with the buildout and the standard holds as more people deploy it.

This session follows one build end to end and shows how teams write designs for the builds they repeat most.

This session will cover:

• Starting from the design catalog. Choosing a reference design such as a chain store or an NVIDIA GB300 NVL72 rack pair, which reuses the device designs it references so every build gets the same definition of each device.
• Writing your own designs. Drafting a design from a plain-language description with a Claude skill, then refining it into the team’s standard.
• Deploying from a form. Filling in a design’s variables and reviewing a plan of each object the apply will create, update, or delete before anything is written.
• Applying through NetBox Branching. Sending the apply to a branch for the team to review and merge, with a record of who deployed which design and with which variables.
• Checking for drift. Running an on-demand drift check that lists each field where a deployment no longer matches its design, with both values.

Key Takeaways

• A model for turning the rack, store, or site your team builds most often into a reusable design that anyone on the team can deploy
• A review workflow where NetBox Designs plans each build and checks it against the data model before anything is written, with a NetBox Branching review where branching is enabled
• A way to trace any deployment back to the design and variables it came from, and to see where it has drifted since
• A first candidate for a design, chosen from the small builds your team already repeats

This session is for network architects, infrastructure engineers, and NetOps leaders at retailers, telcos, MSPs, and AI datacenter builders who roll out near-identical sites, ready to stop entering each one by hand.