Skip to main content

NetBox Lifecycle Plugin

PyPI CI

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.

  1. Install the package into the NetBox virtual environment:

    source /opt/netbox/venv/bin/activate
    pip install netbox-lifecycle
    
  2. Add the package to local_requirements.txt in the NetBox root directory so it is reinstalled automatically whenever NetBox is upgraded:

    echo netbox-lifecycle >> /opt/netbox/local_requirements.txt
    
  3. Enable the plugin in the PLUGINS section of configuration.py:

    PLUGINS = [
        'netbox_lifecycle',
    ]
    
  4. Apply the database migrations:

    python3 /opt/netbox/netbox/manage.py migrate
    
  5. 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:

  1. Create a Vendor for the party you buy support from (Vendor Support > Vendors).
  2. Optionally create Support SKUs for the support products you purchase (Vendor Support > Support SKUs).
  3. Create a Support Contract for the vendor with its contract ID and start, renewal and end dates (Vendor Support > Support Contracts).
  4. Assign the contract, and optionally a SKU, to devices, modules or virtual machines (Vendor Support > Support Assignments).

To track licenses:

  1. Create a License for the product (Licensing > Licenses).
  2. Assign it to a device or virtual machine, together with the purchasing vendor and a quantity (Licensing > License Assignments).
  3. 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)

Source distribution for netbox-lifecycle 1.1.10
File Size Uploaded
netbox_lifecycle-1.1.10.tar.gz 42.8 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for netbox-lifecycle 1.1.10
File Interpreter ABI Platform
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 log

Release 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
Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page