[Feature] High availability for PegaProx

[helppp]

Got an idea? Nice! 💡 We love hearing what features would make PegaProx better for you.

A friendly reminder: PegaProx is built by volunteers in our spare time. We can't promise timelines or guarantee every feature will be implemented — but every suggestion helps shape the roadmap!

Want to help move things faster?

• 💖 Become a Sponsor — sponsored features get prioritized
• ⭐ Star the project — helps with visibility
• 🤝 Even better: submit a PR with your idea!

Using PegaProx now for a few days and impressed with the project so far, think much more people need to know about this(Thank you for the project)! And with this high availability feature I think it can surpass products like vmware vcenter.

---

Describe the feature

Implement high availability for PegaProx. For example a simple unicast IP on two appliances with VIP on both of them, CARP principle or checking with LLDP between them/ipv6 link-local/etc. Between the two a config sync and if needed the actual data (next step perhaps), but simple config sync would be a great first step.

Use Case

Redundancy for management environment

Alternatives considered

You can run the docker, but running the application redundant is always better since there is redundancy by-design instead of redundancy on a lower layer.

How important is this for you?

Nice to have - but I think also for many companies, making the application high available without HA on VM/docker layer

Checklist

• [ √ ] I have searched existing issues and discussions to make sure this hasn't been requested before

[mkellermann97]

Thanks @helppp, and genuinely appreciate the kind words. Honest scoping: PegaProx today assumes a single active instance — the encrypted DB, the scheduler/alert/replication background loops and the console WS servers all expect to be the only one running, so a naive two-node config-sync would risk double-firing scheduled jobs. The realistic shape is active/passive: a CARP-style VIP fronting one live node + DB/state replication + leader-election so only the active node runs the loops — config-sync is a fair first slice, but the state and coordination are the actual meat. Noted for the roadmap and flagged to @MrMasterbay to scope; no timeline, but it's squarely the kind of thing that pushes toward the vCenter-replacement bar you mentioned. Big-ticket items like this are exactly what sponsoring buys dev hours for — opencollective.com/pegaprox 🙏 — Marcus

[mkellermann97]

Thought hard about this one and we're going to pass on app-native HA — honestly it'd mean a real architecture rebuild. PegaProx is single-active by design: the encrypted DB, the scheduler/alert/replication loops and the console WS servers all assume exactly one live instance, so a true active/passive setup needs state replication + leader-election layered under all of that — a lot of surgery for the payoff.

The pragmatic bit: you can get the same DR outcome for a fraction of the effort by treating the PegaProx box as just another VM and replicating the appliance itself. PegaProx already does scheduled snapshot / cross-cluster replication, so a ~15-minute job gives you a warm standby with ~15-min RPO and zero architectural changes — if the primary dies, boot the replica, point DNS at it, done. (You called it yourself — replicating the VM is the 10x-simpler answer.)

So closing as not planned, but that route is the real-world answer and it's already in the product. Cheers for the thoughtful write-up — opencollective.com/pegaprox keeps it all going 🙏 — Marcus

[helppp]

The thing is, if I would treat pegaprox like any other vm this would not work I think. When the hypervisor where pegaprox runs goes down, it will not take any action. Unless I would create a custom script to mimic this. When pegaprox would support HA, this would be covered in the HA functionality. Proper HA is covered in the application, not the hypervisor layer, this is always much slower because of duplicates and such (look at ceph and zfs replication). Just like with vmware vcenter, it would be great if you could re-consider this feature because I really think it would make pegaprox much more interesting and serious.

Again, a big compliment for all the work so far, please consider this at my feedback to make the project even better - really think it would be great.

[mkellermann97]

Really appreciate you pushing on this — and I think the missing piece is good news for you. The host-failure case you describe is actually covered at the hypervisor layer, automatically: run the PegaProx appliance as a Proxmox-HA-managed VM (PegaProx itself sets that up under Cluster → HA), and when the node it's on dies, Proxmox HA restarts it on a surviving node on its own — no custom script, no manual DNS flip. The reason that's enough here is that PegaProx is a control plane, not a data plane: your actual VMs keep running untouched while it's briefly down, so a ~1-2 minute HA restart is a perfectly fine RTO for a management UI — nothing in your workload path is waiting on it. App-native CARP/VIP + state-replication HA would mean a real rebuild (single-active DB, scheduler/alert/replication loops, leader election), and it's genuinely hard to justify that surgery when Proxmox-HA-the-appliance already handles the exact outage you're worried about. On the vCenter comparison — honestly flattered, but that's a two-decade product from a large company; PegaProx is three of us, under a year old and still in beta, so we're deliberately taking the 80/20 wins, and this is one where the platform already gives you the 80. Keeping it closed for that reason, but the appliance-HA route is a real, supported answer today — happy to point you at the HA setup if you'd like a hand. opencollective.com/pegaprox keeps the dev hours coming 🙏 — Marcus

[helppp]

The thing is, I use LVM as local storage and pegaprox to replicate via LVM. To integrate the nodes into pegaprox I needed to tear down the cluster so they are two separate nodes. Is your solution based on one/two clusters where pegaprox runs on other nodes?

If you could lend me a hand at the solution, I would appreciate it. Would be great if this is possible somehow, thanks! This project with three people is insane good work, hats off!