NetBox 4.7 is GA: Cooling Joins the Power Model
NetBox has modeled power end to end for as long as it has modeled infrastructure. You can trace a circuit from the panel to the feed to the outlet to the port on the device. There has been no equivalent for cooling. That information has lived in facilities spreadsheets, mechanical drawings and ad hoc custom fields.
That worked when cooling was purely a facilities concern. It is harder to sustain now. Racks are getting denser, liquid-cooled equipment is arriving on floors built for air cooling, and deciding where a chassis can go is now a thermal question as often as a power one. Answering it means pulling information out of systems the network team does not own.
NetBox v4.7, generally available today, closes that gap. Cooling is modeled the same way power already is, from the chiller down to the intake on the device, so the racks a coolant loop feeds are recorded rather than reconstructed. The release also brings the hardware model in line with what is installed in the rack, and reworks how NetBox handles sustained writes from automation.
One record for power, space, and heat
The cooling model deliberately mirrors the power model, so the concepts are ones you already use. CoolingSource is the cooling equivalent of a power panel: a chiller, cooling tower, dry cooler, CRAC or CRAH, scoped to a site or location. CoolingFeed is the equivalent of a power feed, a coolant loop delivered from a source to a rack with its rated capacity and max flow rate. On the device side, CoolingIntake and CoolingOutflow parallel power ports and outlets, and each intake can reference the outflow that serves it. CDUs, manifolds and rear-door heat exchangers are modeled as ordinary devices carrying those components, the way a PDU already is.
Modeling the full plant is optional. Devices, device types and module types carry a cooling method of air, liquid, hybrid or immersion, and racks and rack types carry a cooling capability and a capacity rating. Those fields alone are enough to filter the estate for racks that can take a liquid-cooled chassis, and to record a hybrid GPU server as hybrid rather than choosing one method.
NetBox records design intent, not live conditions. The model holds no temperature, pressure or flow readings. It sits alongside a building management system rather than replacing it.
CoolingFeed detail
The model matches the rack
Three changes close gaps between what NetBox recorded and what was physically installed.
Channelized interfaces are modeled natively. A channels field declares how many channels a breakout port carries, and each channel is a subinterface bound to its parent. The cable terminates on the parent and NetBox traces a distinct path for each channel, so a 400G port broken out to four 100G links is recorded as four channels rather than four separately named interfaces. Per-channel tracing requires the cable to be assigned a profile, which maps connector positions onto channels.
Module bays declare what they accept. The new ModuleBayType records which kinds of modules a bay can accommodate, an SFP28 cage or a PCIe x16 slot, and propagates from templates. Where a bay and a module type both declare types, NetBox verifies they overlap before permitting installation.
Installed modules can be relocated to another bay, including a bay on a different device, carrying their components, labels and child modules with them, re-resolved for the destination. Moves across devices are permitted where the components carry no active topology or device-scoped configuration.
Separately, device types and module types now carry an end-of-life date, so hardware refresh planning can be driven from the model.
Channelized interfaces
Fits how you build and run it
The rest of 4.7 is about how NetBox behaves when automation is doing the writing.
- Throughput for pipelines. Bulk writes can run as a background job by appending ?background=true, which returns a job to poll rather than blocking, so large imports avoid proxy and gateway timeouts. A failed bulk write identifies each offending object by its index in the submitted list, so a client can correct and resubmit only those objects. Bulk operations remain all-or-none, and validation runs in the worker, so the job status confirms the result.
- A faster foundation. Nested groups are backed by a PostgreSQL ltree column in place of django-mptt. Config context is pre-rendered and cached on every device and virtual machine, and invalidated automatically when a context changes or a device moves in or out of one.
- Event rules and plugin extensibility. Event rule conditions can compare pre-change and post-change snapshots using new changed, unchanged and regex operators, which makes conditions such as “fire only when status changes to active” possible. Application services can expose the same port on multiple protocols. Plugins gain new extension points, on Django 6.1.
NetBox is now published to PyPI, so pip install netbox works. This packaging is experimental in 4.7 and is not recommended for production. The release archive and Git checkout remain the supported installation methods. Feedback from staging is welcome.
Before you upgrade
4.7 raises the minimum requirements. PostgreSQL 15 or later is required, and the upgrade script aborts on PostgreSQL 14, where 4.6 only warned. Redis 6.0 or later is required. 4.7 also introduces breaking changes.
See the upgrade guide and the release notes for more information.
Plan a longer maintenance window than usual. The migration which replaces django-mptt with ltree blocks reads as well as writes, can run for several minutes on a large database, and is not reversible in practice.
Try it out
As always we are excited to hear what you achieve with these new features.
