NetBox Lifecycle Plugin
The NetBox Lifecycle plugin adds hardware EOS/EOL, license and support contract tracking to NetBox.
Features
- Tracking EOL/EOS data for device types and module types
- Tracking licenses, assignable to devices and virtual machines
- Tracking support contracts, assignable to devices, modules and virtual machines
Requirements
- NetBox 4.5 or later
- Python 3.12 or later
Compatibility Matrix
| NetBox Version | Plugin Version |
|---|---|
| 4.1.x | 1.1.5 |
| 4.2.x | 1.1.5 |
| 4.3.x | 1.1.6 |
| 4.4.x | 1.1.6 |
| 4.5.x | 1.1.8 |
| 4.6.x | 1.1.9 |
Installation
The plugin is published on PyPI as netbox-lifecycle and follows the standard NetBox plugin installation procedure. The steps below assume a NetBox installation at /opt/netbox; adjust paths to match your environment.
-
Install the package into the NetBox virtual environment:
source /opt/netbox/venv/bin/activate pip install netbox-lifecycle
-
Add the package to
local_requirements.txtin the NetBox root directory so it is reinstalled automatically whenever NetBox is upgraded:echo netbox-lifecycle >> /opt/netbox/local_requirements.txt
-
Enable the plugin in the
PLUGINSsection ofconfiguration.py:PLUGINS = [ 'netbox_lifecycle', ]
-
Apply the database migrations:
python3 /opt/netbox/netbox/manage.py migrate
-
Restart NetBox to load the plugin. How to do this depends on how NetBox is deployed.
If you run NetBox in Docker, install the plugin by building a custom image as described in the netbox-docker plugin documentation instead of steps 1 and 2.
Upgrading
Upgrade the package inside the NetBox virtual environment, then apply any new migrations and restart NetBox:
source /opt/netbox/venv/bin/activate
pip install --upgrade netbox-lifecycle
python3 /opt/netbox/netbox/manage.py migrate
Release notes are published on the GitHub releases page.
Configuration
The plugin can be configured via PLUGINS_CONFIG in your NetBox configuration file:
PLUGINS_CONFIG = {
'netbox_lifecycle': {
'lifecycle_card_position': 'right_page',
'contract_card_position': 'right_page',
'license_card_position': 'right_page',
},
}
Available Settings
| Setting | Default | Description |
|---|---|---|
lifecycle_card_position |
right_page |
Position of the Hardware Lifecycle Info card on Device, Module, DeviceType, and ModuleType detail pages. Options: left_page, right_page, full_width_page. |
contract_card_position |
right_page |
Position of the Support Contracts card on Device, Module, and VirtualMachine detail pages. Options: left_page, right_page, full_width_page. |
license_card_position |
right_page |
Position of the Licenses card on Device and VirtualMachine detail pages. Options: left_page, right_page, full_width_page. |
Hardware Lifecycle Info Card
Displays EOL/EOS information for the hardware type on Device, Module, DeviceType, and ModuleType detail pages.
Support Contracts Card
Displays all contract assignments on Device, Module, and VirtualMachine detail pages, grouped by status:
- Active: Contracts currently in effect
- Future: Contracts with a start date in the future
- Unspecified: Contracts without an end date
- Expired: Contracts that have ended (lazy-loaded for performance)
Licenses Card
Displays all license assignments on Device and VirtualMachine detail pages.
Usage
All objects live under the Hardware Lifecycle menu, split into three groups: Lifecycle, Vendor Support and Licensing.
To track hardware EOS/EOL, create a Hardware Lifecycle record and assign it to a device type or module type. The dates then appear on the detail pages of that type and of every device or module built from it.
To track support contracts:
- Create a Vendor for the party you buy support from (Vendor Support > Vendors).
- Optionally create Support SKUs for the support products you purchase (Vendor Support > Support SKUs).
- Create a Support Contract for the vendor with its contract ID and start, renewal and end dates (Vendor Support > Support Contracts).
- Assign the contract, and optionally a SKU, to devices, modules or virtual machines (Vendor Support > Support Assignments).
To track licenses:
- Create a License for the product (Licensing > Licenses).
- Assign it to a device or virtual machine, together with the purchasing vendor and a quantity (Licensing > License Assignments).
- Optionally cover a license assignment with a support contract by selecting it on a Support Assignment.
Data Model
The plugin defines seven models:
HardwareLifecycle- EOS/EOL dates for a single device type or module type: end of sale, end of maintenance, end of security, end of support, the last dates to attach or renew a contract, and links to the vendor notice and documentation.Vendor- a party support or licenses are purchased from.SupportSKU- a support product, tied to a NetBox manufacturer.SupportContract- a contract with a vendor, with contract ID and start, renewal and end dates.SupportContractAssignment- links a contract, and optionally a SKU, to a device, module or virtual machine. It can also cover a license assignment, and can carry its own end date when it differs from the contract.License- a license product, tied to a NetBox manufacturer.LicenseAssignment- assigns a license to a device or virtual machine, with the purchasing vendor and a quantity.
Note the distinction between manufacturers and vendors: SKUs and licenses reference the NetBox manufacturer that makes the product, while contracts and license assignments reference the plugin's own Vendor model for the party that sells it.
API
The plugin follows the standard NetBox REST API conventions (authentication, filtering, pagination) under /api/plugins/lifecycle/:
/api/plugins/lifecycle/hardwarelifecycle//api/plugins/lifecycle/license//api/plugins/lifecycle/licenseassignment//api/plugins/lifecycle/sku//api/plugins/lifecycle/supportcontract//api/plugins/lifecycle/supportcontractassignment//api/plugins/lifecycle/vendor/
The plugin also extends the NetBox GraphQL schema; all models can be queried through the standard /graphql/ endpoint.
Contribute
Contributions are always welcome! Please open an issue first before contributing as the scope is going to be kept intentionally narrow.
Metadata
Release files for netbox-lifecycle 1.1.10
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| netbox_lifecycle-1.1.10.tar.gz | 42.8 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| netbox_lifecycle-1.1.10-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 111.1 kB
Release files / netbox_lifecycle-1.1.10.tar.gz
| Download URL | netbox_lifecycle-1.1.10.tar.gz |
|---|---|
| Size | 42.8 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
0f04d33bb484a41cfc240b757a5d0f3259b843070441080b4ce2d2bc85f24bf8
|
|
BLAKE2b-256 checksum How to use checksums |
6bfb27fbcaa9057456fe544c48631ef778d0e7bb82cfbd1f5e3f858dbe62b37a
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 18, 2026.
Transparency logRelease files / netbox_lifecycle-1.1.10-py3-none-any.whl
| Download URL | netbox_lifecycle-1.1.10-py3-none-any.whl |
|---|---|
| Size | 68.3 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
d18112a1e3ec3872adac504f801c5182cee88927a0d02bf4d803e11b99edce8f
|
|
BLAKE2b-256 checksum How to use checksums |
f3e6f0bef5abe65b93a8a96cc410971509881b15ba230380e6317eb084180976
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 18, 2026.
Transparency log