ProxLB, the open-source project built to distribute and rebalance virtual machines and containers across the nodes of a Proxmox VE cluster, has released version 2.3.0. The update adds new options for excluding specific workloads, changes to how its CP-SAT solver behaves, and fixes related to using tags to pin virtual machines to specific nodes.
ProxLB 2.3 in 30 seconds
- ProxLB 2.3.0 was released on August 31, 2026, as an update focused on small changes and fixes.
- It lets you exclude virtual machines and containers by name via
ignore_guests. - It adds control over how the CP-SAT solver behaves when it can’t find a viable solution.
- It fixes node pinning issues caused by Proxmox converting tags to lowercase.
- ProxLB continues to offer an external, configurable scheduler for Proxmox VE clusters.
The update doesn’t change the project’s philosophy, but it arrives at an interesting moment for Proxmox administrators. The hypervisor itself has been advancing its native dynamic load-balancing capabilities, while external tools like ProxLB aim to cover scenarios that need more specific placement policies.
Developed under the credativ umbrella, ProxLB is described as an advanced resource scheduler and load balancer for Proxmox clusters. It can analyze CPU, memory and local storage to decide how to distribute workloads, and it supports both virtual machines and containers. It also covers affinity, anti-affinity, node pinning and maintenance operations.
It works through the Proxmox API, so it doesn’t need SSH to do its job. It can run as a one-off operation, a background service, or be partially integrated into the Proxmox web interface.
What changes in ProxLB 2.3.0
One of the most practical additions is the new ignore_guests option. ProxLB already let you exclude workloads via tags, but the new version adds the ability to directly specify which virtual machines or containers should be ignored by name.
It might look like a minor change, but in clusters with many workloads there are systems an administrator may want to keep out of any automatic migration policy. That can be due to application requirements, hardware dependencies, licensing, or simply because a given machine needs manual handling.
The second addition affects the CP-SAT solver, optionally based on Google OR-Tools.
ProxLB has this mechanism to calculate machine-to-node assignments through an optimization model. The solver can run in shadow mode, where it calculates a proposal without altering the migrations ProxLB actually performs, or in active mode, where it drives them.
Version 2.3.0 adds solver.fallback_to_greedy, an option related to how the system should behave when the CP-SAT solver fails to find a viable plan in active mode.
This lets you control whether ProxLB should fall back to the greedy balancing algorithm in that situation.
The internal handling of RRD (Round Robin Database) datasets has also been changed, replacing the tuple previously used to return average and maximum values with a generic container called RrdDatasets.
A small fix that affects node pinning
Among the fixes in ProxLB 2.3.0, one is especially curious because it stems from how Proxmox VE handles tags.
ProxLB lets you pin a virtual machine or container to specific cluster nodes using tags. A workload might, for example, get a tag tied to the node it should run on.
This can be useful when there are licensing requirements tied to certain servers, or when a node has specific hardware that isn’t present on the rest of the cluster.
The problem is that the Proxmox API converts the strings used as tags to lowercase. ProxLB could then end up comparing that information against node names that kept their original mixed case.
Version 2.3.0 fixes this by normalizing the names during comparison and then returning the node’s original name when it builds the relationship between workloads and servers.
It’s a good example of the kind of bug that can go unnoticed for quite a while: the problem wasn’t really in the placement policy, but in how two components interpreted the same text string.
ProxLB versus Proxmox’s native balancing
ProxLB’s role has also shifted as Proxmox VE has evolved.
The project now acknowledges the existence of Dynamic Load Balancing (DLB), introduced in Proxmox VE 9.2, which provides a built-in solution for automatically distributing workloads managed by High Availability (HA) across cluster nodes.
That means ProxLB no longer occupies exactly the same space it did when Proxmox lacked a comparable native mechanism.
The difference is mainly one of scope.
Proxmox’s DLB is integrated directly with its HA infrastructure and resource scheduler. ProxLB works as an external layer with more customization options, and it can also act on workloads that aren’t part of the HA system.
ProxLB also takes into account CPU, memory, local disk, allocated resources, overprovisioning and PSI (Pressure Stall Information) metrics, along with affinity, anti-affinity and node-pinning policies.
The project can also determine the best node to place a new machine on, a function that automation tools can later call on.
That doesn’t mean ProxLB is automatically preferable to Proxmox’s built-in balancer. A native feature reduces external components and simplifies maintenance and updates. ProxLB mainly makes sense when the required policies go beyond what the built-in mechanism offers, or when working with older versions of Proxmox VE.
There’s another relevant caution. The project’s documentation currently warns of possible conflicts when combining certain Proxmox HA groups with ProxLB’s own placement logic, so it recommends carefully reviewing this interaction before using both mechanisms together.
Automating cluster maintenance too
Balancing isn’t the only feature available.
ProxLB has a maintenance mode that lets you mark nodes so they stop receiving new workloads and move existing ones to other servers. The system takes available resources and affinity or anti-affinity rules into account before carrying out the migrations.
Maintenance can also be scheduled for specific time windows.
For administrators managing several nodes, this makes it possible to automate part of the process ahead of reboots, system updates or hardware interventions.
ProxLB 2.3.0 can be updated through the project’s Debian repository, .deb packages or container images. The software remains open source, and its code, documentation, issues and development stay public.
The arrival of native dynamic balancing in Proxmox VE 9.2 doesn’t necessarily remove the appeal of tools like ProxLB. It’s more that it’s defining two different tiers: a built-in option for standard scenarios, and external tools for administrators who need more control over where, when and under what conditions each cluster workload moves.
Frequently asked questions
What is ProxLB for Proxmox?
ProxLB is an open-source scheduler and load balancer for Proxmox VE clusters. It analyzes available resources and can redistribute virtual machines and containers across different nodes.
What’s new in ProxLB 2.3.0?
The version adds excluding workloads by name via ignore_guests, an option to control the CP-SAT solver’s fallback behavior, and several fixes — including an issue with uppercase and lowercase letters in the tags used to pin workloads to nodes.
Is ProxLB still useful alongside Proxmox VE 9.2’s Dynamic Load Balancing?
It depends on the scenario. DLB offers native integration with Proxmox HA, while ProxLB keeps additional customization options and can work with workloads that aren’t part of the HA system.
Does ProxLB need to be installed on every Proxmox node?
No. ProxLB works through the Proxmox API and can run from any system that has access to it. The project supports installation via Debian packages, containers, or directly from its source code.
