As we hinted in our AutoCon2 recap blog post, connecting design to topology is a big theme for network practitioners right now. While working with our NetBox Service Provider Working Group at the end of 2024, a recurring request was the ability to map arbitrary relationships between NetBox objects—think “What does this application or service actually touch?” or “Which customer is consuming which resources?” Custom fields quickly become unwieldy, and developing a custom plugin can be too heavy a lift.
Introducing NetBox Service Mappings
Enter NetBox Service Mappings, a feature we’re working on now designed to address that exact gap. NetBox Service Mappings will be a meta object type in NetBox that allows you to define arbitrary relationships across NetBox objects, including plugin objects—even other Service Mappings. This offers more flexible data modeling without forcing you into tricky custom code or an explosion of JSON-based custom fields.
Imagine an application that relies on multiple interfaces, a cluster of VMs, or specific tenant data. With NetBox Service Mappings, you can declare all those resources as a cohesive unit in one place, making it easier to see dependencies, spot what’s impacted during changes, and keep your “network design” in lockstep with what’s physically (or virtually) in place.
The Power of “Design-Driven” in Practice
We particularly enjoyed Jeremy Schulman’s AutoCon0 session “Design Driven Automation,” in which he stressed the value of ensuring that every new service or application aligns closely with how your infrastructure is built—and improvements in modeling should be available to people running brownfield networks too. Jeremy’s work with NetBox at Major League Baseball is characteristically future-looking, and NetBox Service Mappings is our first big move towards a future in which instead of repeatedly reinventing how relationships are stored or forcing “pet” workflows, you can let the design drive the topology (and your automation).
Use cases range from service providers delivering port leases to customers to on-prem ops teams linking an “Application X” to every relevant NetBox object it touches. This design-centric approach helps you maintain that critical “source of truth,” whether you’re dealing with IPAM, DCIM, or extended use cases that have historically been shoehorned into custom fields. NetBox Service Mappings are also the perfect abstraction for modeling customer-facing services that could be exposed to end users or delegated to service desks.
NetBox Service Mappings – Status Check
NetBox Service Mappings is currently in our Experimental product stage but has already gathered momentum from early design partners in our Service Provider working group, and across the NetBox community. They’re helping us refine how these relationships get defined and extended, with an eye on permissions, performance, and extensibility. We’ll be turning toward implementation soon, and you’ll see Service Mappings land in NetBox this year.
If you’ve ever felt like Custom Fields weren’t enough and Plugins were too much, or found yourself doing a lot of external orchestration just to keep your design in sync, we think Service Mappings might be the feature you’ve been waiting for.
Get Involved: Early Feedback Sessions
We want your input. If you have a compelling use case—or simply want to kick the tires—please reach out to product@netboxlabs.com with a short description of what you’re trying to achieve. We’ll select a few participants for deeper feedback sessions when we move to the Private Preview stage.