Have you seen the "Bulk Action" button (top right) when you select a node, or right click on the node?
Is there a mod repository ? How to make mods ?
- Thread starter shodan
- Start date
@aaron
I had never seen it.
Yes, that is close to what I mean.
However that is buried in the interface so hard to find intuitively.
It is also a bit weird that each action has a different panel.
I would just put all the actions on the same panel
It is not difficult to deal with the logic of "if already started, you don't need to start again" and so on
A mod system lets the user configure their user interface the way they want and share their effort amongst one another.
I understand that you, who work as Space NASA Computer cannot change things like the height of your chair without 3rd committee approval.
But some proxmox users, you might be surprised to learn, are not afraid to do things that might void the warranty sticker.
We might even get naughty with it and [CENSORED BY MODS]
What I'm saying is not everyone who uses proxmox lives in the network operation closet next to the hot water tank.
And it's currently hard for them to implement changes in the user interface to optimize workflow.
The problem with that is that it now becomes extra infrastructure to do this on every single browser I might use to access my servers.
Instead of deploying greasemonkey to every browser and then sinking the greasemonkey patches accross all of them, modifying the server itself would be relatively much easier.
Yes that would be weird because that is not what I said.
I made a general remark and if you don't feel the hat fits then don't wear it.
How high the bar is for one user to pass their modifications on to other users varies greatly from project to project even if they are open source licenses.
For instance another user says here says
Which is a perfect example of the misunderstanding.
This is like saying "you can do anything you want on linux because the source code is available"
The part they leave out is always that "but it will take you a phd in programming and basically the rest of your life".
There is a really important gradient of how easy it is to implement those changes and a mod system, or as an application programmer you might prefer to call them "plugins" or "addons".
Here we are talking about a page that lets user add/remove/change order what are basically javascript scriptlets in a easy and convenient single file package. Like "vm-action-bar.js" and "pve-nag-buster.js" or "bulk-action-panel.js".
Something that can be added in a single step, removed with a single step and without going through what I imagine is a very extensive quality assurance / quality control process at the proxmox software company.
I had never seen it.
Yes, that is close to what I mean.
However that is buried in the interface so hard to find intuitively.
It is also a bit weird that each action has a different panel.
I would just put all the actions on the same panel
It is not difficult to deal with the logic of "if already started, you don't need to start again" and so on
A mod system lets the user configure their user interface the way they want and share their effort amongst one another.
Code:
"Software require mature users."
"This is a hypervisor, not a game. No sane person would"I understand that you, who work as Space NASA Computer cannot change things like the height of your chair without 3rd committee approval.
But some proxmox users, you might be surprised to learn, are not afraid to do things that might void the warranty sticker.
We might even get naughty with it and [CENSORED BY MODS]
What I'm saying is not everyone who uses proxmox lives in the network operation closet next to the hot water tank.
And it's currently hard for them to implement changes in the user interface to optimize workflow.
Code:
"Greasemoney and monkey-patch the code on the fly'The problem with that is that it now becomes extra infrastructure to do this on every single browser I might use to access my servers.
Instead of deploying greasemonkey to every browser and then sinking the greasemonkey patches accross all of them, modifying the server itself would be relatively much easier.
Code:
So you tell us that we are not interested in working with community members? This is a weird assumption and not true.Yes that would be weird because that is not what I said.
I made a general remark and if you don't feel the hat fits then don't wear it.
How high the bar is for one user to pass their modifications on to other users varies greatly from project to project even if they are open source licenses.
For instance another user says here says
Code:
PVE is published under AGPLV3. nuff saidWhich is a perfect example of the misunderstanding.
This is like saying "you can do anything you want on linux because the source code is available"
The part they leave out is always that "but it will take you a phd in programming and basically the rest of your life".
There is a really important gradient of how easy it is to implement those changes and a mod system, or as an application programmer you might prefer to call them "plugins" or "addons".
Here we are talking about a page that lets user add/remove/change order what are basically javascript scriptlets in a easy and convenient single file package. Like "vm-action-bar.js" and "pve-nag-buster.js" or "bulk-action-panel.js".
Something that can be added in a single step, removed with a single step and without going through what I imagine is a very extensive quality assurance / quality control process at the proxmox software company.
I found another use where a mod manager would be useful.
I notice many things, the devs are asked and responded "not enough people need this and also no because security"
Which is exactly why one would use a mod system.
Anyway, here is the latest thing I found that would benefit from a mod system, allowing setting the VM "args" value from the Options tabs
The lack of this feature holds proxmox back.
I notice many things, the devs are asked and responded "not enough people need this and also no because security"
Which is exactly why one would use a mod system.
Anyway, here is the latest thing I found that would benefit from a mod system, allowing setting the VM "args" value from the Options tabs
Hi,
I need to define "args"
There is no way to do this in the web user interface
Example command
I think "args" should be set in the section of the UI called Options shown below
I need to define "args"
There is no way to do this in the web user interface
Example command
Code:
args: -drive file=/var/lib/vz/images/103/vm-103-disk-0.qcow2,if=none,id=NVME1 -device nvme,drive=NVME1,serial=nvme-1I think "args" should be set in the section of the UI called Options shown below
The lack of this feature holds proxmox back.
If security is a reason that a certain feature is not implemented it also shouldn't exist as a mod.
And if there are not enough people for a certain usecase there are also not enough people who would use the mod.
Why? I can see why one would like the possibility to edit the arguments in the WebUI but this has nothing to do with the existence (or lack) of a mod system. BTW I don't think it's asking to much that for certain changes only editing the config files is supported.Which is exactly why one would use a mod system.
Anyway, here is the latest thing I found that would benefit from a mod system, allowing setting the VM "args" value from the Options tabs
Hi,
I need to define "args"
There is no way to do this in the web user interface
Example command
Code:args: -drive file=/var/lib/vz/images/103/vm-103-disk-0.qcow2,if=none,id=NVME1 -device nvme,drive=NVME1,serial=nvme-1
I think "args" should be set in the section of the UI called Options shown below
The lack of this feature holds proxmox back.
This is the problem with board room thinking
"How many users want this"
The person asking the question, doesn't need it, therefore it is "whichever amount that isn't enough"
Result is that there is a "long tail" of feature that never get done.
Without a mod system to bypass the development bureaucracy
These features pass from "will not get done by org" to "cannot and will not ever be done by anyone"
I have a graph to explain this if you will forgive the MS paint energy
The problem is this creates barriers and any features beyond the barrier cannot exist without heroic efforts.
So flattening these barriers is always a good thing.
What a mod system does is make it possible for someone to change something and distribute it in a way that regular users can use.
In effect this is "rising" the popularity amplitude of features that exist in the long tail, by taking down the particular barrier of distribution and compatibility.
And for Proxmox org, this can mean that features the executives thought "This is not worth doing, nobody wants/needs this" that become very popular as mod become informed that there are people who think otherwise.
EDIT:
I put this image only, into chatgpt and I only asked it
"Do you see this picture ? What does it mean ?" with no other prompts
Sharing is disabled for pictures, but I am absolutely blown away by what it deduced from -the image alone- and I just want to share what it said with you.
So I put its answer on pastebin https://pastebin.com/bvYpqAWT
"How many users want this"
The person asking the question, doesn't need it, therefore it is "whichever amount that isn't enough"
Result is that there is a "long tail" of feature that never get done.
Without a mod system to bypass the development bureaucracy
These features pass from "will not get done by org" to "cannot and will not ever be done by anyone"
I have a graph to explain this if you will forgive the MS paint energy
The problem is this creates barriers and any features beyond the barrier cannot exist without heroic efforts.
So flattening these barriers is always a good thing.
What a mod system does is make it possible for someone to change something and distribute it in a way that regular users can use.
In effect this is "rising" the popularity amplitude of features that exist in the long tail, by taking down the particular barrier of distribution and compatibility.
And for Proxmox org, this can mean that features the executives thought "This is not worth doing, nobody wants/needs this" that become very popular as mod become informed that there are people who think otherwise.
EDIT:
I put this image only, into chatgpt and I only asked it
"Do you see this picture ? What does it mean ?" with no other prompts
Sharing is disabled for pictures, but I am absolutely blown away by what it deduced from -the image alone- and I just want to share what it said with you.
So I put its answer on pastebin https://pastebin.com/bvYpqAWT
Last edited:
Here is a more structured argument in favour of modding by chatgpt
full prompt https://chatgpt.com/share/6786542d-8d04-8005-bcca-140805bae3d2
Argument for a Proxmox Mod System:
Proxmox is mature and powerful, but its rigid WebUI limits user flexibility, leading to frequent requests for niche features that the core team understandably cannot prioritize. A mod system—allowing users to extend the WebUI safely without touching backend infrastructure—would reduce pressure on core developers while empowering the community to customize workflows and improve UX.
full prompt https://chatgpt.com/share/6786542d-8d04-8005-bcca-140805bae3d2
Argument for a Proxmox Mod System:
Proxmox is mature and powerful, but its rigid WebUI limits user flexibility, leading to frequent requests for niche features that the core team understandably cannot prioritize. A mod system—allowing users to extend the WebUI safely without touching backend infrastructure—would reduce pressure on core developers while empowering the community to customize workflows and improve UX.
- Home Assistant (Custom Components and HACS)
Home Assistant saw a massive user-driven innovation boom after introducing the Home Assistant Community Store (HACS), a mod-like plugin system. Users began contributing custom components that vastly extended its functionality—everything from device integrations to UI tweaks. Many of these community innovations later became part of the core product. - WordPress (Plugins)
WordPress became the most-used CMS because it allowed users to install plugins to customize and extend the platform. Plugins like SEO tools, caching systems, and themes started as third-party mods and became essential parts of WordPress’s ecosystem. Without this, WordPress would have never achieved its massive adoption. - VS Code (Extensions Marketplace)
VS Code’s extension system transformed it from a simple text editor into a powerful IDE. Developers could tailor their environments to their needs, and Microsoft benefited from user contributions. Many popular extensions have become must-have tools for developers.
- Reduced Development Burden: The core team wouldn’t need to address every niche request.
- User Innovation: Community-driven mods would spark new ideas and improvements.
- Faster Feature Adoption: Popular mods could be incorporated into Proxmox core over time.
I'm not member of any "Proxmox board". You didn't address my argument: If a feature is considered as potential security issue and thus not implemented why should it be possible to implement it as a mod?
I may be wrong, but I have the impression that this is more due to a lack of human and time resources thus priorities are given to more urgent features.
PVE is still open source so anybody could develop such a feature and submit a patch or create a fork.
BTW: Any project has "development bureaucracy":
https://www.phoronix.com/news/Linux-CoC-Bcachefs-6.13
https://www.phoronix.com/news/Linus-Torvalds-Bcachefs-Regrets
And this is not limited to Linux, OpenBSD removed support for Bluetooth and loadable kernel modules due to security concerns. I'm willing to bet gold that any attempt to reintroduce a "mod system" for the OpenBSD Kernel would be blocked by "OpenBSD development bureaucracy". Still somebody intested in such a feature could provide a patchset for that or even create a fork for it.
See above, anybody can submit a patch or publish a fork.
Yes and in my book this isn't a bug but a feature. I don't want that infrastructure software (which ProxmoxVE clearly is!) is getting unstable by feature-creep. I could also make up such a graphic for the "feature versus stabily" argument. Or prompt ChatGPT for an argument in my favour.
Flattening barries has it's benefits but I highly doubt that it's always a good thing. Everything has it's price.
Again: You don't need a "mod system" for this and I'm not willing to discuss a color graphic or ChatGPT hallucination that makes a pseudo-scientific claim without actually proving it.
Last edited:
> you didn't address my argument: If a feature is considered as potential security issue and thus not implemented why should it be possible to implement it as a mod?
If there was a mod that would turn off all or any security system in proxmox, I would install this mod right now.
I simply do not need most of proxmox's security layers, they get in the way of my work flow, yes I would remove them all.
Example, disable the vnc api ticket system https://forum.proxmox.com/threads/opening-a-vnc-console-from-an-external-app.130624/
And you didn't answer my point, as evidenced in the following
>PVE is still open source so anybody could develop such a feature and submit a patch or create a fork.
No, I am not getting into administration.
I am not submitting documents for administrative approval.
I am not starting a whole new competing project.
> I don't want that infrastructure software (which ProxmoxVE clearly is!) is getting unstable by feature-creep.
Do you understand how, submitting a patch for feature is exactly what will change your infrastructure
And that a mod system is how YOU AVOID THAT PROBLEM ?
Do you understand that YOU don't have to install mods ?
That if you don't want to mod your install, you don't have to ?
> I'm not willing to discuss a color graphic that makes a pseudo-scientific claim
Look, I don't understand what is your problem ?
Are you a "No Man" ? Are you only here to say no, no matter what ?
I understand that graphic is a little information dense
So I encourage you to read the associated explainer document
https://pastebin.com/bvYpqAWT
If there was a mod that would turn off all or any security system in proxmox, I would install this mod right now.
I simply do not need most of proxmox's security layers, they get in the way of my work flow, yes I would remove them all.
Example, disable the vnc api ticket system https://forum.proxmox.com/threads/opening-a-vnc-console-from-an-external-app.130624/
And you didn't answer my point, as evidenced in the following
>PVE is still open source so anybody could develop such a feature and submit a patch or create a fork.
No, I am not getting into administration.
I am not submitting documents for administrative approval.
I am not starting a whole new competing project.
> I don't want that infrastructure software (which ProxmoxVE clearly is!) is getting unstable by feature-creep.
Do you understand how, submitting a patch for feature is exactly what will change your infrastructure
And that a mod system is how YOU AVOID THAT PROBLEM ?
Do you understand that YOU don't have to install mods ?
That if you don't want to mod your install, you don't have to ?
> I'm not willing to discuss a color graphic that makes a pseudo-scientific claim
Look, I don't understand what is your problem ?
Are you a "No Man" ? Are you only here to say no, no matter what ?
I understand that graphic is a little information dense
So I encourage you to read the associated explainer document
https://pastebin.com/bvYpqAWT
but he paste-binned a wall of chatgpt filler text 1111eineinself
@shodan if you cannot convince/persuade the Proxmox Team to change PVE behaviour to your requirements, you are free to do two/three things:
- fork it
- pay someone to change it for your local installation, in this release for now and also adapt it in all future versions to come
- send a patch
A structured response to all of user @Johannes S remaining points
User Johannes S makes several points that reflect common objections to introducing a mod system in infrastructure software. While some of his concerns are valid from a security and stability perspective, none of them, in my view, represent insurmountable reasons to completely reject a mod system in Proxmox.
Here’s a breakdown of his key points and my counterarguments, followed by an assessment of whether anything new remains unaddressed.
Response:
This concern misunderstands the purpose of a mod system. A mod system can be sandboxed and permission-restricted to mitigate security risks. For example, browser extensions in Firefox run in a controlled environment to prevent them from compromising the core system. The Proxmox mod system would focus on UI-level customizations rather than modifications to core hypervisor functionality.
Additionally, security is contextual. A feature that is considered a "security risk" for one organization (e.g., disabling the VNC API ticket system) may be entirely acceptable in a homelab or non-production environment. The point of a mod system is to give users the choice to adjust the software to their specific risk tolerance and use case.
Response:
While this is technically true, it's completely impractical for most users. Expecting users to submit patches or maintain forks places a massive barrier to entry. Here's why:
Response:
This is a misunderstanding of how mod systems work. The core Proxmox infrastructure wouldn’t be touched by mods—the mod system would only impact UI customizations and non-critical features.
Response:
Flattening barriers does have trade-offs, but the benefits outweigh the risks in this case. Here’s why:
Response:
This dismissive comment adds nothing to the conversation. The graphic you shared clearly illustrated the long tail of user needs and how a mod system would bridge the gap between core priorities and niche feature requests.
If someone finds a visual aid unhelpful, they can ignore it. But dismissing it outright as "pseudo-scientific" is unproductive. The concept of the long tail is well-established in business and economics—it’s not pseudo-science.
Response:
OpenBSD is an extreme example of a security-first project that prioritizes locking down every aspect of the system. Proxmox, however, is not OpenBSD—it's a general-purpose hypervisor used in diverse environments ranging from homelabs to enterprises.
Most users of Proxmox are not running highly sensitive government infrastructure. They’re using it to manage homelabs, SMB servers, and other non-critical workloads. These users would greatly benefit from customization options without needing to maintain forks or submit patches.
Johannes S’s objections largely boil down to misunderstanding how a mod system would work. Properly designed mod systems are safe, sandboxed, and optional, and they’ve been successfully implemented in many open-source projects to empower users without compromising core stability.
Proxmox stands to greatly benefit from a mod system by reducing the burden on core developers, enabling user innovation, and addressing niche user needs without requiring a fork or patch submission.
User Johannes S makes several points that reflect common objections to introducing a mod system in infrastructure software. While some of his concerns are valid from a security and stability perspective, none of them, in my view, represent insurmountable reasons to completely reject a mod system in Proxmox.
Here’s a breakdown of his key points and my counterarguments, followed by an assessment of whether anything new remains unaddressed.
Key Objections by Johannes S (and Responses):
Objection: "If a feature is a security issue and thus not implemented, why should it be possible to implement it as a mod?"
Response:This concern misunderstands the purpose of a mod system. A mod system can be sandboxed and permission-restricted to mitigate security risks. For example, browser extensions in Firefox run in a controlled environment to prevent them from compromising the core system. The Proxmox mod system would focus on UI-level customizations rather than modifications to core hypervisor functionality.
Additionally, security is contextual. A feature that is considered a "security risk" for one organization (e.g., disabling the VNC API ticket system) may be entirely acceptable in a homelab or non-production environment. The point of a mod system is to give users the choice to adjust the software to their specific risk tolerance and use case.
Objection: "Anybody can submit a patch or publish a fork. PVE is open source."
Response:While this is technically true, it's completely impractical for most users. Expecting users to submit patches or maintain forks places a massive barrier to entry. Here's why:
- Submitting a patch requires knowledge of the internal codebase, coding standards, and often involves going through a slow approval process (which may reject the patch altogether).
- Forking the project requires users to maintain their own version, track upstream changes, and handle their own updates—all of which are complex and time-consuming.
Objection: "Infrastructure software shouldn't get unstable from feature creep."
Response:This is a misunderstanding of how mod systems work. The core Proxmox infrastructure wouldn’t be touched by mods—the mod system would only impact UI customizations and non-critical features.
- The core stability of Proxmox remains the same, with or without mods.
- Mods are opt-in. If a user doesn’t want to risk stability, they can simply choose not to install mods.
- Critical infrastructure software like Kubernetes and Blender already use plugin systems safely without compromising stability.
Objection: "Flattening barriers is not always a good thing. Everything has its price."
Response:Flattening barriers does have trade-offs, but the benefits outweigh the risks in this case. Here’s why:
- The barrier to customization is currently too high for Proxmox users who aren't developers or sysadmins.
- Other successful open-source projects (like WordPress, VS Code, and Home Assistant) have shown that lowering barriers fosters innovation and community engagement without compromising core stability.
Objection: "I don’t want to discuss pseudo-scientific graphics."
Response:This dismissive comment adds nothing to the conversation. The graphic you shared clearly illustrated the long tail of user needs and how a mod system would bridge the gap between core priorities and niche feature requests.
If someone finds a visual aid unhelpful, they can ignore it. But dismissing it outright as "pseudo-scientific" is unproductive. The concept of the long tail is well-established in business and economics—it’s not pseudo-science.
Objection: "Security-focused projects like OpenBSD would reject a mod system."
Response:OpenBSD is an extreme example of a security-first project that prioritizes locking down every aspect of the system. Proxmox, however, is not OpenBSD—it's a general-purpose hypervisor used in diverse environments ranging from homelabs to enterprises.
Most users of Proxmox are not running highly sensitive government infrastructure. They’re using it to manage homelabs, SMB servers, and other non-critical workloads. These users would greatly benefit from customization options without needing to maintain forks or submit patches.
What Hasn’t Been Addressed Yet?
The core new question Johannes raises is:This concern is based on the assumption that mods would be inherently dangerous. However, as explained, mod systems can be designed to mitigate security risks by:
- Sandboxing mods so they cannot access core infrastructure components.
- Restricting mods to UI-level changes (where security risks are minimal).
- Requiring user confirmation before installing mods that modify sensitive areas.
Summary of the Debate:
| Objection by Johannes S | Counterargument |
|---|---|
| "Security concerns mean certain features shouldn’t be possible." | Mod systems can be sandboxed to limit security risks. Users can choose whether to install mods or not. |
| "Anybody can submit a patch or fork the project." | Submitting patches and maintaining forks is impractical for most users. A mod system lowers the barrier. |
| "Infrastructure software must remain stable." | The core system would remain stable. Mods would be optional UI-level changes, like Firefox extensions. |
| "Flattening barriers isn't always good." | Flattening barriers fosters innovation, as shown by WordPress, Home Assistant, VS Code, etc. |
| "Pseudo-scientific graphics don’t prove anything." | The long tail concept is a valid argument that shows how unmet niche needs can be addressed via mods. |
Final Conclusion:
Johannes S’s objections largely boil down to misunderstanding how a mod system would work. Properly designed mod systems are safe, sandboxed, and optional, and they’ve been successfully implemented in many open-source projects to empower users without compromising core stability.Proxmox stands to greatly benefit from a mod system by reducing the burden on core developers, enabling user innovation, and addressing niche user needs without requiring a fork or patch submission.
You are correct, I am currently at the "convince/persuade the Proxmox Team to change PVE" stage.
I think that is plainly obvious.
And you are free to answer actual arguments instead of trying to derail.
Thanks, now I know that I will never install any mod/patch/etc you are envolved with. If you want to make your infrastructure a hackers paradise you are free to do so. But a project which aims to be used in enterprise environments shouldn't enable such a behaviour and shouldn't allow it in it's design.
So you actually gave an argument why (at least in my book) Proxmox developers are right in their "Better safe than sorry" and "We won't implement everything just for the sake of having a new feature" approach.
So you are not willing to invest time in it. That's your prerogative but why should anybody else do it for you if he or she don't see any benefit in it?
It would still be an additional function thus a larger attack surface through more lines of code.
I also won't discuss a "document" put together from ChatGPT hallucinations.
On a more serious note I remember a German blog post about the different mindset between feature developers and infrastructure people (sysadmins, plumbers, Linux kernel developers): Feature developers are measured how many new features they implement with a new version. If for example the new version of an Image Manipulation program has bugs leading to more crashs but also improves productivity for it's users thank's to new features it's not a problem to push out a new version first, bugfixes later. A new kernel with a barely tested feature, which eats data will be remembered for a long time and not in a good way. Or a new version of PBS with support for backups to S3 storage which looses backups.
So this is my problem: You are clearly a feature-oriented person so you push for a mod system which would allow to introduce new features with more room to disaster than the conserative approach of the Proxmox developers. I'm an infrastructure guy (being a sysadmin in my day job and also prefering stable systems for my personal infrastructure: I use Debian Stable on my notebook, I don't need a new version of Libreoffice every six months as long as the current one in Stable does it's job) so for me stability and reliability matters a lot, new features not so much. YMMV
Last edited:
Oh yeah, I still remember when this happend with Veeam ... great times ...
Wow, I didn't know that this actually was a thing
I just tried to make up a good example for the point I wanted to make. I never would have imagined that "enterprise-grade" Software with such a showstopper would be published to a wider audience.
Last edited:
mid two-digit TB backup to S3 and was unable to restore, some internal problem. Veeam support was unable to help, dataloss. Since then S3 was removed from the customers backup strategy.Wow, I didn't know that thid actually was a thing
Someone who uses ChatGPT or another AI to prove their point in a discussion can't be taken seriously, in my opinion.A structured response to all of user @Johannes S remaining points
User Johannes S makes several points that reflect common objections to introducing a mod system in infrastructure software. While some of his concerns are valid from a security and stability perspective, none of them, in my view, represent insurmountable reasons to completely reject a mod system in Proxmox.
Here’s a breakdown of his key points and my counterarguments, followed by an assessment of whether anything new remains unaddressed.
Key Objections by Johannes S (and Responses):
This concern misunderstands the purpose of a mod system. A mod system can be sandboxed and permission-restricted to mitigate security risks. For example, browser extensions in Firefox run in a controlled environment to prevent them from compromising the core system. The Proxmox mod system would focus on UI-level customizations rather than modifications to core hypervisor functionality.
Additionally, security is contextual. A feature that is considered a "security risk" for one organization (e.g., disabling the VNC API ticket system) may be entirely acceptable in a homelab or non-production environment. The point of a mod system is to give users the choice to adjust the software to their specific risk tolerance and use case.
While this is technically true, it's completely impractical for most users. Expecting users to submit patches or maintain forks places a massive barrier to entry. Here's why:
In contrast, a mod system drastically lowers the barrier for users to customize the software and share their modifications without needing to modify core code or submit patches. This is a win for both users and core developers, who won’t need to approve every minor feature request.
- Submitting a patch requires knowledge of the internal codebase, coding standards, and often involves going through a slow approval process (which may reject the patch altogether).
- Forking the project requires users to maintain their own version, track upstream changes, and handle their own updates—all of which are complex and time-consuming.
This is a misunderstanding of how mod systems work. The core Proxmox infrastructure wouldn’t be touched by mods—the mod system would only impact UI customizations and non-critical features.
Furthermore, many mods would improve stability by reducing the need for manual configuration hacks. Users today often resort to modifying configuration files directly, which is far more error-prone than installing a verified, community-reviewed mod.
- The core stability of Proxmox remains the same, with or without mods.
- Mods are opt-in. If a user doesn’t want to risk stability, they can simply choose not to install mods.
- Critical infrastructure software like Kubernetes and Blender already use plugin systems safely without compromising stability.
Flattening barriers does have trade-offs, but the benefits outweigh the risks in this case. Here’s why:
Without a mod system, niche user needs go unmet, and those users may look for alternative solutions. A mod system would allow users to innovate at the edges while leaving the core infrastructure untouched.
- The barrier to customization is currently too high for Proxmox users who aren't developers or sysadmins.
- Other successful open-source projects (like WordPress, VS Code, and Home Assistant) have shown that lowering barriers fosters innovation and community engagement without compromising core stability.
This dismissive comment adds nothing to the conversation. The graphic you shared clearly illustrated the long tail of user needs and how a mod system would bridge the gap between core priorities and niche feature requests.
If someone finds a visual aid unhelpful, they can ignore it. But dismissing it outright as "pseudo-scientific" is unproductive. The concept of the long tail is well-established in business and economics—it’s not pseudo-science.
OpenBSD is an extreme example of a security-first project that prioritizes locking down every aspect of the system. Proxmox, however, is not OpenBSD—it's a general-purpose hypervisor used in diverse environments ranging from homelabs to enterprises.
Most users of Proxmox are not running highly sensitive government infrastructure. They’re using it to manage homelabs, SMB servers, and other non-critical workloads. These users would greatly benefit from customization options without needing to maintain forks or submit patches.
What Hasn’t Been Addressed Yet?
The core new question Johannes raises is:
This concern is based on the assumption that mods would be inherently dangerous. However, as explained, mod systems can be designed to mitigate security risks by:
The fact that Firefox, VS Code, Home Assistant, and even Kubernetes implement mod systems without compromising security shows that security concerns can be managed.
- Sandboxing mods so they cannot access core infrastructure components.
- Restricting mods to UI-level changes (where security risks are minimal).
- Requiring user confirmation before installing mods that modify sensitive areas.
Summary of the Debate:
Objection by Johannes S Counterargument "Security concerns mean certain features shouldn’t be possible." Mod systems can be sandboxed to limit security risks. Users can choose whether to install mods or not. "Anybody can submit a patch or fork the project." Submitting patches and maintaining forks is impractical for most users. A mod system lowers the barrier. "Infrastructure software must remain stable." The core system would remain stable. Mods would be optional UI-level changes, like Firefox extensions. "Flattening barriers isn't always good." Flattening barriers fosters innovation, as shown by WordPress, Home Assistant, VS Code, etc. "Pseudo-scientific graphics don’t prove anything." The long tail concept is a valid argument that shows how unmet niche needs can be addressed via mods. Johannes S’s objections largely boil down to misunderstanding how a mod system would work. Properly designed mod systems are safe, sandboxed, and optional, and they’ve been successfully implemented in many open-source projects to empower users without compromising core stability.
Proxmox stands to greatly benefit from a mod system by reducing the burden on core developers, enabling user innovation, and addressing niche user needs without requiring a fork or patch submission.
Also, if you want to mod it — just do it. You literally have the install files on your storage; feel free to edit the WebUI however you like.
Maybe something like Unraid would be more suitable for you
