Introducing NetBox Changes v1.0: Governance at the Layer Where the Change Actually Happens

Policy-enforced approvals, pull-request-style reviews, and an audit record that is the change record, built on the Branching primitive.

Every network team we talk to has a version of the same story. A change gets made. Nobody is quite sure who approved it, or what diff was actually reviewed, or which policy was supposed to gate it. Then either an audit gets ugly or something breaks, and the record everyone goes hunting for turns out to be a screenshot of a Slack thread, an email from someone who left in March, and a Jira ticket that describes what somebody planned to change, not what they changed.

That last one is the part we hear most. Right now, your Change Advisory Board (CAB) reviews a ticket that summarizes the work. They are not reviewing the work itself. The auditors who show up at quarter end have the same problem in reverse: the artifacts they are handed do not line up with the changes that actually happened. A change-control system that engineers route around is a system that does not work, and most of what passes for change control today is exactly that.

This is the problem we built NetBox Changes v1.0 to solve.

Earlier this week, NetBox Branching reached v1.0.3 in open source. Stage a change in a separate workspace, see exactly what it will do, then merge atomically or not at all. The pattern resonated immediately with practitioners when we first released Branching in 2024, and the v1.0.3 release represents years of iteration and production-hardening. Branching does its job: it isolates the change.

The next layer up, the one your compliance, CAB, and platform teams need, is governance. Enforced approvals. Reviewable diffs. Notifications that find the right people. An audit trail that holds up.

Today, NetBox Changes reaches v1.0. Changes is the governance layer that sits on top of Branching: pull-request-style reviews on a structured diff, policy that enforces at merge, built-in notifications, permission-aware navigation, and webhooks that carry enough state for external systems to participate. It is included in Pro and Premium subscriptions at no additional charge.

Three things you get from Changes v1.0: governance without friction that your engineers will use, an audit-defensible record generated as a byproduct of the work, and a stack-native design that fits the tools you already run.

Governance without friction

Changes v1.0 is built so the workflow feels like the code review engineers already do every day, with the guardrails compliance and CAB leaders need underneath.

Setup is guided. A pre-requisite warning system catches misconfigurations before they affect policy enforcement, so administrators see what is missing while they are still configuring. The review itself looks like a pull request: a structured diff of what will change, comments on the change request, and a clear approval state. Notifications go out through NetBox’s notification framework on every meaningful event (submitted, reviewed, approved, rejected, completed), routed by a documented permission matrix to the people who need to see them.

The workflow is recoverable. Rejected change requests can be reopened, or a new one created while the rejected version stays in history. Nothing is lost, nothing is rebuilt from scratch. When a change is ready to merge, the policy engine is the last gate. If the policy requires two reviewers from network architecture and one from security, the merge waits until that is true.

This is the change-control system your CAB will adopt because it is the one your engineers will use, not a parallel approval workflow that runs alongside the work.

Audit-defensible

Every merged change in Changes v1.0 produces a reviewable diff, a named author, the reviewers who approved it, the policies that gated it, and a timestamp. That is audit-grade evidence for SOC 2, PCI, FedRAMP, and internal CAB processes, generated as a byproduct of the workflow rather than stitched together at quarter end. Auditors make the final call on any specific control, as always. What Changes does is put a real, complete record on the table for that conversation.

When a policy changes, Changes re-evaluates open requests automatically. The audit trail reflects current policy, not whatever rule was in effect when the request opened. Webhook payloads include the key object change data, so external systems and auditors can correlate the merged state to the exact change record.

The shift this enables is small to describe and large in practice: audit prep stops being a parallel project. The team that already merges every day generates the evidence as they go, and the auditor reads the same record the engineer reviewed. The change record is the audit record.

Stack-native by design

Changes is a native feature and slots into the NetBox system of record you already run. No schema change. No new data model. No re-platform. It is built to work with the rest of your stack, not around it.

Changes coexists with ServiceNow and Jira Service Management rather than competing with them. Outbound webhooks carry the branch’s latest ObjectChange ID, so an existing CAB can approve against the actual diff rather than a prose ticket description. Inbound Review API endpoints let those external approvals flow back as reviews on the change request. Your ITSM stays the system of workflow and CAB scheduling. Changes brings approval governance to the layer where the change actually happens. The integrations are standards-based webhooks, with no proprietary lock-in.

Looking ahead: automation and AI-assisted change

Changes was designed from the start to be a governance surface for automation, not just for humans. Webhooks carry branch state for external validators (linting, drift checks, connectivity tests), so automated checks can run before a human reviews. A service-user reviewer architecture lets CI systems and automated reviewers vote on merges as first-class participants, and policy rules can require both human and automated approval before a change goes through.

That same architecture is what makes Changes a natural place for AI agents and automated reviewers to operate on the system of record. Most enterprises running AI-agent pilots on the network hit the same wall: security and CAB teams will not permit a direct-write agent on the authoritative record without a sandbox, a reviewable diff, and a policy gate. Branching gives the agent the sandbox, Changes gives it the gate. Teams that adopt both NetBox Branching and Changes are better positioned for agentic infrastructure operations.

Try it out

Changes v1.0 ships as part of NetBox Pro and Premium subscriptions, with no price change. Going forward, Changes is a Pro and Premium feature. If you are already a Pro or Premium customer, Changes is available to you by default. Talk to your account team to enable it. If you are on a Starter subscription today, you are grandfathered in. You keep access to Changes on your current plan, no action needed.

The migration path is gradual. Start with one policy on one object class. Expand as confidence builds. The branch workflow already exists, Changes turns it into the governance gate.