Supported way to extend the PVE web UI for a third-party package?

[Chiranth]

Hello,
I am a storage backend providor for PVE on the supported PVE::Storage: Plugin contract, presenting vDisks over iSCSI.
That side has worked well and is in production with customers.

We also have a prototype that adds a native-feeling UI on top of it (a tab with vDisk aliases, snapshot/rollback, resize and performance).
Since we couldn't find an official UI-extension hook, it currently works by patching two pve-manager files at install time — adding a <script> tag to index.html.tpl and a register_method for a /nodes/<node>/datacore/... route in PVE/API2/Nodes.pm — with a dpkg trigger to re-apply after upgrades.

We understand the long-standing guidance that features should be added "directly, no plugin," and we're weighing whether to productize this. Before we decide, two questions:

1. Is there any supported or planned mechanism to extend the PVE web UI (add a view/tab) or register a nodes/<node>/... API2 route from a third-party package — anything analogous to the storage plugin contract, but for the frontend?
2. If not, is in-place patching of index.html.tpl / Nodes.pm considered an acceptable approach (several community projects do this), or does it put a node in an unsupported state from your perspective? Is there a pattern you'd recommend instead?

Thanks.

 

[cheiss]

Hi,

GUI support for storage plugins is currently being worked on: https://lore.proxmox.com/pve-devel/20260623143402.772452-1-m.carrara@proxmox.com/
It's however hard to say when this will land, as that depends on many factors.

Feel free to chime in on the mailing list of course, early feedback from potential users is always highly appreciated!
(This in turn can also help advancing such a feature.)

 

[Chiranth]

Thanks a lot, Cheiss.

This is highly relevant for us, as we maintain a custom storage plugin. I'd be happy to test this series against our plugin and provide feedback.

I have two questions:

1. Scope

This series does a great job of automatically generating the storage configuration form. However, the larger gap for us is the operational UI—for example, plugin-specific views and actions such as snapshot/rollback, volume resize, per-volume status, and the corresponding backend API endpoints to support them.

Is a supported extension mechanism for such functionality on the roadmap, or is it within the broader vision of this schema-driven approach?

2. Interim Approach

Until native support becomes available, would it be considered acceptable to integrate our UI by patching:

• index.html.tpl with a single <script> tag, and
• PVE/API2/Nodes.pm with a single register_method exposing a /nodes/<node>/... route?

The changes would be applied in an idempotent, marker-guarded manner, automatically reverted during uninstall, and re-applied via a dpkg trigger after upgrades.

Or would you advise against this approach, even as a temporary workaround?

 

[bbgeek17]

• index.html.tpl with a single <script> tag, and
• PVE/API2/Nodes.pm with a single register_method exposing a /nodes/<node>/... route?

You run the risk of breaking customer's GUI by introducing patches to the core software product that may conflict with future updates.

---

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox