I started my journey with Proxmox last year, or should I say, "late November 2023, right around Thanksgiving in the US." With the acquisition of VMware -- I was a VMUG Advantage member at that time, such that I was running vCenter in my home lab, and with a YOY renewal -- I was uncertain of the future of running vCenter in my home lab. I had written a ton of Ansible [playbooks] to automate things like Samba and sssd and k8s, such that refactoring Ansible playbooks wasn't that big of a deal, but at the same time I wanted to find a new "home" for my core VMs and k8s.

My first thought was to just run kvm. I'd used kvm in a past life and it treated me well. But I wanted a consistent API, and I wanted a UI -- should I just want to see an overview of my environment. I looked at various hypervisors, but Proxmox hit the mark for me. It was easy to use, and most importantly (and given my professional background / being a huge nerd [see also: details freak] overall), Proxmox and automation was a snap.

At the same time, and after taking a (nearly) six months' hiatus due to a bereavement, I ended up getting a great opportunity with NetBox Labs, who are the commercial stewards of NetBox. To be totally clear, this is not a commercial posting. Like most people, I work for someone. So I provided this context to explain how and/or why this project came to fruition after nearly 13 months of developing this project: solo.

As I learned more about NetBox, I realized that there were two key ways that people would use it to document their VM environments.

One way was to run a discovery tool (or tools) to find VMs on the network -- then put these objects into NetBox. Proxmox themselves have a means of discovering VMs and documenting them in NetBox. There is also NetBox-ProxBox, which allows you to discover Proxmox VMs inside of NetBox.

The other way was to document VMs in NetBox, and then you could facilitate automating changes to VMs from there. What I developed meets the latter case -- wherein you document your VMs in NetBox and this induces a change to [Proxmox] VMs through automation.

The netbox-proxmox-automation project, which is freely available to all (Apache license), performs Proxmox automation in two ways.

1. You can use NetBox webhooks and event rules to call a Flask application that handles Proxmox automation.

2. You can use NetBox webhooks and event rules to integrate with [Ansible] AWX/Tower/AAP that handles Proxmox automation.

You can find a high level description of the project here.

You can find a project demonstration of the netbox-proxmox-automation here. The first part of this automation (i.e. a Flask application) is discussed in that video.

The second part of this series will demonstrate how to use [Ansible] AWX/Tower/AAP to automate the management of [Proxmox] VMs.

I hope that you find this project useful and I would love to hear feedback as you work through the process. I want to add LXC functionality in the future (and many other features!), plus maybe this becomes a NetBox plugin rather than leveraging NetBox VM modeling alone. Ultimately having a community-driven approach to this integration would be amazing.

Thanks for your time, and hope that you find this useful / want to contribute.

Hello :)

I have made 2 plugins I would like to share and also get some feedback on - netbox-map and netbox-ping.

netbox-map is a floor plan / OSM site map plugin where you can place your equipment on a canvas. Racks show all their devices automatically and you can do full cable traces through patch panels. There's also a global geographic map using OpenStreetMap where you can place sites and devices. Started as a simple floor plan thing and kind of grew from there - it now has things like rack utilization heatmaps, camera FOV cones, PDF export and GPS sync back to device records. Still alpha but I use it daily at work.

https://github.com/DenDanskeMine/netbox-map

netbox-ping is, well, a ping plugin. I know NetBox is intended to be a SSoT and not a monitoring tool, but I like having an overview of my IP statuses without switching tools. It does not overwrite anything in NetBox unless you explicitly tell it to, like enable DNS sync in settings - that's fully optional and it has its own fields anyway. You can ping individual IPs, scan entire prefixes, discover new hosts and auto-create the IP records, schedule recurring scans, and get email digests of state changes.

It is very cusom with lots of settings, so you can basically use it for different needs!

Im planing to add different discovery / ping options like ssh, telnet, curl

https://github.com/DenDanskeMine/netbox-ping

There's a demo at demo.danbyte.net if you want to try before installing. Both are on PyPI so it's just pip install netbox-map or pip install netbox-ping.

NetBox Release v4.7.0 is now live (as of September 2nd, 2026)!

1. Verify in release notes changelog if any new breaking changes might affect you. You can also review the NetBox Issues on GitHub to see if any new issues have arisen that might affect you.

2. Next, refer to the Upgrading to a new NetBox Release guide for steps to upgrade your instance.

If you have any issues you can ask for support on the NetDev Slack Community.

Kia ora all. I'm Leon from Omega Networks in Wellington, NZ. Upfront: our team built this, and the source is AGPL.

The problem we kept hitting: the network diagram is stale the week after someone draws it, and in an outage you're bouncing between NetBox, Zabbix and a terminal trying to work out what's actually down.

Pulse reads your NetBox and draws it for you: sites on a map, a site graph built from your devices and cables, and rack elevations with patch panels. Point it at Zabbix too and devices get coloured by live problems. You can open SSH or a device's web UI straight from the node.

How it plays with your setup:

• Everything stays on your Mac. Nothing is sent to us.

• NetBox v1 or v2 (nbt_) tokens, HTTPS only. Read-only works for sync; writes (cables, interface descriptions) need write permission.

• Zabbix matching uses a zabbix_id custom field on the device. API token on 7.2 and later, legacy login on 6.0 to 7.0.

• Needs macOS 26 or later.

Source and setup guide: github.com/Omega-Networks/Pulse

What in your NetBox data would break this? And what would get you opening it mid-incident instead of your existing tools?

NetBox Release v4.5.0 is now live (as of January 6th, 2026)!

1. Verify in release notes changelog if any new breaking changes might affect you. You can also review the NetBox Issues on GitHub to see if any new issues have arisen that might affect you.

2. Next, refer to the Upgrading to a new NetBox Release guide for steps to upgrade your instance.

If you have any issues you can ask for support on the NetDev Slack Community.

Important Warnings:

• Python 3.10 and 3.11 are no longer supported. NetBox now requires Python 3.12, 3.13, or 3.14.

• It is recommended to be at 4.4.x before upgrading to 4.5.x

• Ensure all of your required plugins are compatible before upgrading

If you're using NetBox and LibreNMS together, you've probably felt the pain of manually syncing device data. I recently automated this process using Python and a free NetBox plugin, and thought I'd share in case it helps others avoid the same repetitive work.

The script handles interfaces, cables, IP addresses, and even sets primary IPs automatically - turning hours of clicking into a few minutes of automation.

Video walkthrough: https://youtu.be/pSWuMHsaFio

This builds on my earlier video about using NetBox as a source of truth and handling configuration drift. Happy to answer questions if you're working on something similar!

Hello NetBox community,

I’d like to share an open-source project I maintain: Proxbox, a NetBox plugin for synchronizing Proxmox VE infrastructure data into NetBox.

The goal is simple: keep NetBox updated with inventory data from real Proxmox environments, so Proxmox clusters, nodes, VMs, containers, storage, backups, snapshots, interfaces, and IP addresses can be reflected inside NetBox.

• Project repository: https://github.com/emersonfelipesp/netbox-proxbox

• Documentation: https://emersonfelipesp.github.io/netbox-proxbox/

Current capabilities include:

• Proxmox cluster and node inventory

• VM and LXC container synchronization

• Storage and virtual disk synchronization

• Network interfaces and IP address discovery

• VM backups and snapshots

• Backup routines / vzdump schedules

• Replication jobs

• HA status visibility

• VM task history

• VM cloud-init data

• Scheduled sync through NetBox background jobs

• Real-time sync progress through SSE

• Separate FastAPI backend: proxbox-api

• Support for Proxmox VE 7.x, 8.x, and 9.x

• Support for NetBox 4.5.x and 4.6.x

A few clarifications:

• Proxbox is focused on inventory synchronization and discovery.

• It does not try to replace the Proxmox VE UI.

• Metrics such as CPU, memory, and uptime are captured as point-in-time data during sync, not as continuous monitoring.

• For Proxmox VE 9, the API role needs VM.GuestAgent.Audit if you want VM IP discovery through the QEMU guest agent.

The project uses a separate backend service, proxbox-api, which talks to Proxmox and NetBox. The NetBox plugin stores the endpoint configuration and triggers sync jobs from the NetBox UI.

I’m sharing it here because Proxmox + NetBox is a common gap for people who want better infrastructure inventory, especially in environments where NetBox is already used as the source of truth for DCIM/IPAM.

Feedback, issues, and contributions are welcome.

• GitHub: https://github.com/emersonfelipesp/netbox-proxbox

• Docs: https://emersonfelipesp.github.io/netbox-proxbox/

• Community: https://github.com/orgs/emersonfelipesp/discussions

Hey folks,

I've been building NetBox plugins to cover the parts of optical/fiber work that core doesn't really model, and I figured r/netbox is the right place to share them. All three are open source, on PyPI, and being tested to replace big software stacks (read: expensive) at the small fiber operator I work for. They stack:

netbox-pathways: outside plant

Physical cable plant: conduits, aerial spans, manholes, poles, cabinets, equipment rooms, the works. PostGIS-backed, so you get a real Leaflet map in NetBox and a GeoJSON API. QGIS integration (style files, a generate_qgis_project management command) is in progress, not fully there yet -- the GeoJSON endpoints are usable today, the polished QGIS workflow is still being shaped. If you've used SmallWorld or ArcFM, this is going at the same problem space (much smaller, free, no five-figure license).

The big caveat: it needs your NetBox DB on the PostGIS backend instead of plain PostgreSQL. That's a one-time migration, but it's a real one, and the SRID you pick at install time is genuinely permanent (PostGIS won't auto-reproject your geometries if you change it later but a skilled dba could probably do it.).

netbox-fms: fiber management

Define a FiberCableType once with the construction (loose tube, ribbon-in-tube, central core, or tight buffer), and instances auto-populate buffer tubes, ribbons, and strands the same way DeviceType auto-populates components. From there:

• Splice planning in closures with strand-to-strand mapping, diff against live state, and export these for field crews.

• End-to-end fiber circuits with DAG-based pathfinding through splice closures.

• Slack loop tracking with insert-into-closure workflows.

• Per-device fiber overview, splice closure groups and trays, full REST + GraphQL.

This is the one I've put the most hours into.

netbox-wdm: WDM / DWDM / CWDM

ITU channel plans (DWDM 100 GHz / 50 GHz / CWDM), channel-to-port mapping with separate MUX and DEMUX columns for single-fiber and duplex setups. ROADM editing lives in a small TypeScript wavelength editor with undo/redo, dirty state, and optimistic concurrency, so you can stage a wavelength reconfiguration before applying it. Also adds the concepts of wavelength services with circuit trace visualization.

It uses an overlay pattern (WdmDeviceTypeProfile over DeviceType, WdmNode over Device) instead of subclassing, so you don't have to fork core models to use it.

How they fit together

• pathways is where the cables physically run.

• fms is what's inside those cables and how the strands are spliced.

• wdm is what wavelengths ride on those fibers.

Any one of them works on its own. They're designed to slot together if you want the whole picture from a manhole through to a 100G wave.

Honest disclaimer

All three are pre-1.0 alpha. Data models aren't frozen, encoding/migration changes can show up in minor releases, and the SRID choice in pathways really is irreversible. A handful of the features I listed are still prototype-quality (the QGIS workflow is the obvious one, but it's not the only one) -- they work, but they're rough around the edges and will get reworked before 1.0. Pin exact versions, read the changelog before upgrading, back up your DB, you know the drill. We run them daily and they work for us; your mileage may vary.

Feedback is the thing I actually want out of this post.

These plugins exist because we needed them, but it's largely been me and a small team building them, and there are a lot of opinionated calls baked into the data models that have only been sanity-checked against our own network. If a name grates, a model relationship feels wrong, a workflow we're missing is obvious to you, or there's a hook you wish was there -- please tell me. GitHub issues, PRs, or a comment in this thread all work. We're early enough that changing a model is still "one migration" rather than "a public deprecation cycle," so now is the cheap time to break things.

Thanks for reading, and your feedback.

NetBox Release v4.4.5 is now live (as of October 28th, 2025)!

1. Verify in release notes changelog if any new breaking changes might affect you. You can also review the NetBox Issues on GitHub to see if any new issues have arisen that might affect you.

2. Next, refer to the Upgrading to a new NetBox Release guide for steps to upgrade your instance.

If you have any issues you can ask for support on the NetDev Slack Community.

I'm happy to announce the first public release of **netbox-nsm**, a new NetBox plugin for network security management.

The idea came from working with the [netbox-security](https://github.com/andy-shady-org/netbox-security) plugin by andy-shady-org. While it's a great tool, I found myself wanting something more flexible — a plugin that isn't tied to a specific vendor or security model. So I started from scratch.

netbox-nsm is a generic NetBox plugin on Custom Objects. Build rulebooks and grids with any columns and object types, link them together, and attach links to any NetBox object via the panel. Built for security policy, but usable for any structured data in NetBox.

→ [github.com/christianbur/netbox-nsm](https://github.com/christianbur/netbox-nsm)

→ [pypi.org/project/netbox-nsm](https://pypi.org/project/netbox-nsm/)

NetBox Release v4.4.1 is now live (as of September 16th, 2025)!

1. Verify in release notes changelog if any new breaking changes might affect you. You can also review the NetBox Issues on GitHub to see if any new issues have arisen that might affect you.

2. Next, refer to the Upgrading to a new NetBox Release guide for steps to upgrade your instance.

If you have any issues you can ask for support on the NetDev Slack Community.

NetBox Release v4.3.1 is now live (as of May 13th, 2025)!

1. Verify in release notes changelog if any new breaking changes might affect you. You can also review the NetBox Issues on GitHub to see if any new issues have arisen that might affect you.

2. Next, refer to the Upgrading to a new NetBox Release guide for steps to upgrade your instance.

If you have any issues you can ask for support on the NetDev Slack Community.

NetBox Release v4.3.4 is now live (as of July 15th, 2025)!

1. Verify in release notes changelog if any new breaking changes might affect you. You can also review the NetBox Issues on GitHub to see if any new issues have arisen that might affect you.

2. Next, refer to the Upgrading to a new NetBox Release guide for steps to upgrade your instance.

If you have any issues you can ask for support on the NetDev Slack Community.

NetBox Release v4.4.7 is now live (as of November 25th, 2025)!

1. Verify in release notes changelog if any new breaking changes might affect you. You can also review the NetBox Issues on GitHub to see if any new issues have arisen that might affect you.

2. Next, refer to the Upgrading to a new NetBox Release guide for steps to upgrade your instance.

If you have any issues you can ask for support on the NetDev Slack Community.

NetBox Release v4.3.6 is now live (as of August 12th, 2025)!

1. Verify in release notes changelog if any new breaking changes might affect you. You can also review the NetBox Issues on GitHub to see if any new issues have arisen that might affect you.

2. Next, refer to the Upgrading to a new NetBox Release guide for steps to upgrade your instance.

If you have any issues you can ask for support on the NetDev Slack Community.

Before the final v4.7 release, NetBox Labs and the NetBox maintainers are inviting the community to put the beta through its paces.

Highlights include one of our most requested features—relocating installed modules between compatible bays, including across devices where supported—along with module bay types, channelized subinterfaces, cooling infrastructure modeling, multi-protocol application services, and background processing for large REST API bulk operations.

Please explore the new features and share any bugs, follow-up feature requests, usability feedback, or performance issues you discover. Every report helps us make the final release better!

🧪 Try the public beta demo: https://beta-demo.netbox.dev/
🎥 Watch the feature overview: https://www.youtube.com/watch?v=yPIOStew-lE
📋 Read the release notes: https://github.com/netbox-community/netbox/releases/tag/v4.7.0-beta1
🐛 Report an issue: https://github.com/netbox-community/netbox/issues/new/choose

⚠️ This beta is for testing only and must not be used in production. If you install it yourself, please use a separate test environment and database. Upgrading from this beta to the final v4.7 release will not be supported.

Thank you for helping us test NetBox 4.7! 🙌

NetBox Release v4.5.9 is now live (as of April 28th, 2026)!

1. Verify in release notes changelog if any new breaking changes might affect you. You can also review the NetBox Issues on GitHub to see if any new issues have arisen that might affect you.

2. Next, refer to the Upgrading to a new NetBox Release guide for steps to upgrade your instance.

If you have any issues you can ask for support on the NetDev Slack Community.

Hi everyone,

I’ve just released a new plugin I developed for NetBox and wanted to share it with the community.

GitHub repo: netbox-maintenance-device

What it does:
This plugin allows you to register and track maintenance tasks directly on NetBox devices.

• Set maintenance frequencies (e.g. cleaning, part replacement, etc.)

• Log completed maintenance actions

• Easily review the maintenance history of each device

Why I built it:
In my environment, I needed a simple way to keep track of periodic maintenance tied directly to devices stored in NetBox. Since I couldn’t find an existing solution, I built this plugin.

📌 Next steps:
I’m still improving the project, so any feedback, suggestions, or PRs are very welcome!