Why Proxmox, anyway?

The frustrating thing about gomox is that such a tool needs to be written in the first place. Proxmox just doesn’t really have much in terms of third-party tooling, although the deeper I get into its internals the more I start to understand this: it’s a whole lot of crusty Spaghetti Perl.[^2] Maybe that’s being a little unkind/unfair, but it’s definitely not super easy to follow, and so there just hasn’t been a whole lot of community tooling. And what is around can be pretty bare.

And now that I’ve been working with the API for maybe a week, the API has had a silly breaking change occur.

I didn’t actually notice this in my own use so far (maybe I updated my servers after updating the library?), but it’s a little disappointing!

And despite Proxmox’s open-source development model and decent popularity, collaboration and development coordination takes place over old-school, Kernel-style mailing lists, which is more than a little frustrating to contribute to…

Maybe it’s a generational thing, but the Pull Request workflow is so easy to work with! I don’t think every open-source project should centralize on GitHub, but Gitea is a great FOSS forge compatible with the workflow popularized on GitHub.

All of this and sometimes I start to question if I really want to stick with Proxmox. But the likes of libvirt don’t supply the same powerfully simple clustering out-of-the-box. And of course VMware is very non-free!

Harvester (and kubevirt) seem fantastic, but they would barely function on my smallest servers!

Incus (and LXD) are much closer to what I like about Proxmox, but I fear that it would still be both heavier and less useful out-of-the-box than Proxmox…

If my content has been helpful to you, please consider buying me a coffee or