# netbox-proxbox v0.0.24

v0.0.24

| Field |Value |
| --- | --- |
| Canonical URL | https://emersonfelipesp.com/netbox-proxbox/releases/v0.0.24 |
| GitHub URL | https://github.com/emersonfelipesp/netbox-proxbox/releases/tag/v0.0.24 |
| Tag | v0.0.24 |
| State | latest |
| Author | emersonfelipesp |
| Created | 2026-08-20 00:04 UTC |
| Published | 2026-08-20 00:05 UTC |
| Target | develop |
| Synced | 2026-08-20 01:30 UTC |
| Assets | 0 |

## Release notes

# Version 0.0.24

netbox-proxbox `0.0.24` pairs with `proxbox-api 0.0.20`,
`proxmox-sdk 0.0.13`, and the backend's REST dependency
`netbox-sdk 0.0.10`. The plugin now declares **two NetBox support tiers**: a
**stable** tier covering `4.5.8` through `4.6.99`, and a new **experimental**
tier covering `4.7.0` through `4.7.99`.

Current backend-runtime pairing: netbox-proxbox 0.0.24 <-> proxbox-api 0.0.20 <-> proxmox-sdk 0.0.13 <-> netbox-sdk 0.0.10. This netbox-sdk version is proxbox-api's REST dependency only and does not provide the semantic MCP bridge.

| NetBox | netbox-proxbox | proxbox-api | netbox-sdk | proxmox-sdk |
|---|---|---|---|---|
| >=4.5.8 | v0.0.24 | v0.0.20 | v0.0.10 | v0.0.13 |

## Experimental NetBox 4.7 support

This release is the first to load and run on NetBox `4.7`. It is deliberately
shipped as an **experimental** tier, not a certified one.

| NetBox line | Tier | Status |
|---|---|---|
| `4.5.8` - `4.6.99` | stable | certified and CI-gated |
| `4.7.0` - `4.7.99` | experimental | loads and runs; emits a startup warning |

- **What you get.** The plugin installs and runs on NetBox `4.7.0` - `4.7.99`.
  The version gate no longer rejects the 4.7 line outright.
- **How it announces itself.** Running on an experimental NetBox emits a Django
  system-check **`Warning`** (`netbox_proxbox.W001`), never an `Error`, so
  startup is not blocked. The `PLUGINS_CONFIG` opt-out silences that maturity
  notice only; it does not suppress unrelated checks.
- **What was required to get there.** View actions are declared as
  `ObjectAction` classes rather than the legacy attributes 4.7 removed,
  `from_db()` accepts the keyword arguments Django now passes, and the default
  VM-role seed migration was fixed for ltree-backed NetBox hierarchies. The
  shared compatibility contract moved to v2.
- **Evidence.** The Django test matrix runs `v4.7.0-beta1` as a **required**
  leg alongside `v4.5.8`, `v4.5.10`, `v4.6.0`, and `v4.6.6`, so admitting 4.7
  is demonstrated to be a pure widening rather than a regression trade.

### Known limitations of the experimental tier

- NetBox `4.7.0-beta1` is a pre-release. Its schema and internals can still
  drift before GA, so treat 4.7 as evaluation-grade rather than production.
- The 4.7 leg exercises netbox-proxbox itself. A combined cell covering every
  companion plugin at once is not possible yet, because released 4.7-capable
  companion artifacts do not exist.
- Production deployments should stay on the stable `4.5.8` - `4.6.99` tier.

## Compatibility and correctness

- Certifies NetBox `4.6.6`, including the PDM registry override required by its
  current plugin loading contract.
- Preserves serializer source identity and corrects storage-node capacity,
  detail-template, InfluxDB, and sync-state behavior against real Django/NetBox
  models.
- Treats an empty configured encryption key as uninitialized and safely creates
  the key when a primary endpoint secret is first stored.

## Release integrity

- Builds one wheel and one sdist from the exact tagged commit and publishes them
  to the Gitea Package Registry, which remains the artifact of record.
- Validates the tag against a strict version pattern before anything is built,
  and verifies the package is present in the registry after upload.
- Subscribes to the tag `push` event only. Gitea emits both `create` and `push`
  for a tag, and subscribing to both would start two immutable uploads for one
  version.
- Creates the public GitHub Release for final tags only. A release candidate
  never produces one, because that event is the sole trigger for the public PyPI
  upload and an rc must not reach PyPI as though it were final.
- Builds the public-index distributions from the same tagged commit, so what
  reaches TestPyPI and PyPI corresponds to the published source rather than a
  separately fetched copy. Uploads never use `--skip-existing`, so a failure
  always advances to a new immutable version rather than silently succeeding.
- Pushes tags and creates releases only against the single authorised GitHub
  repository.

### Known limitation: publication hardening is deferred

This release publishes through in-repository jobs on the existing shared
runners — the same path used by `0.0.23` and every currently published version.
The locked release control plane developed during this cycle is **not** in this
release, because the isolated runner fleet it requires does not exist yet.

Specifically, this version does **not** yet have: credential-free target builds,
an exact-byte sealed handoff to a separately administered isolated publisher,
supervisor-signed runner attestation, or egress-denied build isolation. Those
controls are implemented and reviewed in-tree, and re-land once the isolated
runners are provisioned.

This is a deliberate, tracked deferral rather than a regression: `0.0.24` ships
at the same publication posture as every release before it.

## Upgrade

Deploy `proxbox-api 0.0.20` first, then install `netbox-proxbox 0.0.24`, run
the normal NetBox migration and static-collection steps, restart NetBox and its
workers, and verify the Proxbox plugin API and synchronization health.

## Assets

No binary assets attached.

Source archives:

| Format |URL |
| --- | --- |
| zip | https://api.github.com/repos/emersonfelipesp/netbox-proxbox/zipball/v0.0.24 |
| tar.gz | https://api.github.com/repos/emersonfelipesp/netbox-proxbox/tarball/v0.0.24 |