When Proxmox VE upgrade and support services make sense
A planned upgrade and support engagement is usually bought when the internal team lacks spare maintenance windows or hands-on cluster experience, especially when a major move is due. Many teams keep routine patching in-house and only look outside when a specific event forces the question. The first thing to establish is whether your estate is on Proxmox VE 8 and how much time remains before the matching Debian release leaves security support. Proxmox VE versions are supported at least as long as the Debian release beneath them has security support, and the Proxmox VE FAQ states that Proxmox VE 8 on Debian 12 reached end of life in August 2026. Confirm that date against the current FAQ and your own change calendar before you plan around it. The most common trigger is that deadline itself. A Proxmox VE 8 estate has to move to Proxmox VE 9 before its support window closes, and the upgrade touches every node, the cluster configuration and every guest's dependencies. A second trigger is subscription tier. Proxmox VE sells per CPU socket per year, and the tiers differ mainly in ticket counts and response times, so teams often need to decide whether they need paid support at all, and which repository their nodes should use. The enterprise repository requires a valid subscription key, while the no-subscription repository is described for testing and non-production use. Mixing these up on production nodes is an avoidable risk. The third trigger is a stalled or failed upgrade. A cluster that has drifted behind on updates, where some nodes run different package versions or a rolling upgrade was paused halfway, needs someone who can read the cluster state before anything else moves. Ask any partner to confirm how they would verify quorum, storage health and guest status at each step, and whether they would work only on infrastructure you control. DeployOpen works inside your own cloud accounts, data centers or air-gapped networks, so the cluster, backups and credentials stay under your governance throughout the engagement.
Before you request a quote, gather the facts that drive effort. List every node, its CPU socket count, its installed Proxmox VE and Debian versions, and whether it runs HA, Ceph or ZFS storage. Note which repositories each node uses and whether a subscription key is installed. Record your backup tool and last successful restore test, and identify the guests that cannot tolerate an outage. Then decide who has authority to approve a maintenance window and how many windows you can actually release before the deadline. If the answer to the last question is few, an outside team is worth pricing. If you have experienced cluster operators and enough windows, a planned in-house upgrade with a written rollback plan may be the better fit. When you compare options, separate what is one-time from what recurs. An upgrade project is a one-time scope with defined deliverables, usually agreed in writing before work begins. Ongoing support, patch cycles and subscription fees recur. Ask for the upgrade sequence, the verification steps at each node, the rollback criteria, and what happens if a node fails mid-upgrade. Ask which activities the subscription covers and which the partner covers, so that you do not pay twice for the same ticket or leave a gap between them. Ask who holds the administrative credentials after the engagement ends. Your internal team should also confirm what the partner will not do. Support engagements do not replace your change approval process, your incident response plan or your own accountability for the cluster. Ask how changes are recorded, how the partner hands off runbooks, and whether the upgrade evidence can be reused in your audit or compliance file. DeployOpen prepares systems, controls and evidence for assessments, but independent auditors issue any formal attestation.
What a Proxmox VE upgrade and support engagement includes
A Proxmox VE upgrade engagement is usually a sequence of connected work packages, each ending in a document or check you keep. The assessment feeds the upgrade plan, the plan governs rolling node work, and verification and handover make the result repeatable by your own team. All scope and deliverables are agreed in writing before work starts.
Current version and host assessment
We inventory every node's Proxmox VE and Debian package versions, kernel, hardware, storage types (LVM, ZFS, Ceph, NFS or iSCSI), cluster membership and guest counts. You receive a written assessment listing hosts that need work and blockers such as unsupported hardware, custom packages or pending repository changes. Check that the inventory matches what your team believes is running before planning begins.
Major version upgrade plan
The plan sets the target release, such as moving from Proxmox VE 8 on Debian 12 to Proxmox VE 9 on Debian 13, and sets the order of work, change windows, freeze periods and go or no-go criteria. You receive a written plan with a tested rollback path for each node. Confirm the end-of-life date for your current release with the vendor and align the schedule to it.
Rolling node upgrades in clusters
In a cluster we upgrade one node at a time, migrating or stopping guests first, so quorum and high availability behavior stay predictable. Each node receives a documented pre-check, upgrade, reboot and return-to-service step. Ask how guests on shared or replicated storage will be moved and how the team will confirm the cluster is healthy before the next node starts.
Repository configuration and subscription status
We set each node to the enterprise repository when a valid subscription key is in place, or to the no-subscription repository where that is the agreed choice for the environment. You receive a record of repository files, subscription status per node and the update policy. Confirm with your procurement team which subscription tier and socket count apply, since support entitlements differ by tier.
Post-upgrade verification
Verification covers cluster quorum, storage availability, guest start and migration tests, network bridges, API and web access, backup job runs and authentication realms. You receive a signed-off test record that lists each check, the result and any open defects. Agree in advance which checks must pass before the change is closed.
Runbook and handover
The runbook captures the as-built versions, repository settings, upgrade procedure, rollback steps and escalation contacts for your environment. We walk your operations staff through it and record the handover. Ask for the runbook to be stored under your version control and reviewed at each future minor or major release.
Optional retainer support
A retainer covers ongoing work such as patch review, minor release updates, incident support and periodic health checks after the project closes. It is scoped separately and recurs, so it is distinct from the one-time upgrade fee. Ask for the response expectations, named contacts and what is excluded before you sign.
What drives Proxmox VE upgrade cost and duration
This table lists the factors that change how much effort a Proxmox VE upgrade takes and what it costs to support afterward, with a practical way to keep each one under control. Read each row as a question to answer about your own estate before asking for a quote. The main takeaway is that node count, storage type and change approval rules usually matter more than the upgrade commands themselves.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Node count and cluster topology | Each node needs its own upgrade, reboot and health check, and mixed-version clusters need careful planning. Quorum rules mean a cluster of three or more nodes can be upgraded one node at a time without losing service. | Standardize hardware and versions, upgrade one node at a time, and drain guests before each reboot. Ask for a rolling procedure with checkpoints per node. |
| HA configuration and shared storage | HA-managed guests must be moved or stopped safely during reboots, and fencing settings can cause unexpected restarts if mishandled. Shared storage has its own maintenance and upgrade dependencies. | Document HA groups and fencing behavior before the upgrade, test failover in a non-production cluster, and confirm storage backends are compatible with the target version. |
| Storage type (LVM, ZFS, Ceph, NFS, iSCSI) | Local LVM and directory storage are usually simple to maintain. ZFS pools and Ceph clusters add pool, replication and health checks that must be verified before and after each node reboot. | Record the storage layout per node, confirm pool and Ceph health before starting, and plan extra validation time for Ceph or ZFS-backed nodes. |
| Number of guests and dependent automation | More guests mean longer migration and verification windows. Custom scripts, API automation, templates and monitoring integrations can break when API or configuration details change. | Inventory guests by criticality, list every script and API client, and run them against a test cluster on the target version before production. |
| Number of environments (test, staging, production) | A separate test or staging cluster lets the team rehearse the upgrade and catch repository, driver or script issues. Without one, rehearsal often happens on production hardware. | Confirm which environments exist, decide which one is upgraded first, and ask whether the quote includes rehearsal on a non-production copy. |
| CPU sockets and subscription tier | Enterprise repository access and support entitlements are priced per CPU socket per year, so socket count sets the recurring subscription cost. Tier choice also affects response times for support tickets. | Count sockets across all nodes, compare tiers against your support needs, and ask whether the quote separates one-time upgrade work from recurring subscription fees. |
| Compliance evidence requirements | Assessors may expect change records, pre and post upgrade test results, patch levels and access records. Collecting this evidence adds documentation effort to every step. | Agree the evidence list before work starts, use a standard change template, and keep dated screenshots, logs and version inventories as part of the runbook. |
| Current state of the hosts | Hosts with outdated packages, inconsistent versions, failing disks, unsupported hardware or manual configuration changes take longer to diagnose and may need repair before upgrading. | Run a health check on each host, align package versions, back up configuration and guests first, and fix known faults in a separate, earlier change. |
| Client maintenance windows and change approval | Your own maintenance windows, freeze periods and change board cycles often set the calendar duration more than the technical work does. Each approval step can add waiting time between node upgrades. | Ask for the approval calendar early, group node upgrades into approved windows, and prepare change packages in advance so reviews do not stall the schedule. |
How a Proxmox VE upgrade project runs from assessment to handover
The sequence moves a cluster from its current Proxmox VE release to the target release with a documented rollback path, a rehearsed upgrade, and a handover your operators can run without the project team.
Inventory hosts, storage, networks and guests
DeployOpen reviews each node's hardware, installed Proxmox VE and Debian packages, cluster membership, quorum status, and enabled repositories. It maps storage backends (LVM, ZFS, directory, Ceph, NFS, iSCSI or Proxmox Backup Server), bridge and VLAN configuration, guest inventory with HA and backup status, and integrations such as monitoring, provisioning, identity and backup jobs. The client supplies read access to the cluster API and shell access to hosts, plus current backup records and change windows. The step closes with a written inventory that lists each dependency and each known gap, and the client confirms it matches their understanding of the environment before planning starts.
Write the upgrade plan and rollback path
Using the inventory, DeployOpen drafts the upgrade plan: the target release and its Debian base, the node order, the repository change from the current release to the target, preflight checks, the package upgrade steps for each node, and the conditions that stop the rollout. The rollback path covers restoring a node from its backup, reverting configuration, and deciding when a partially upgraded cluster is held rather than pushed forward. The client approves the plan, the change windows, the rollback criteria and any changes to subscriptions or repositories. The step is done when the approved plan names an owner for every action and the rollback has been written down with the restore sources it depends on.
Rehearse the upgrade in a non-production copy
The team builds a test cluster or a restored copy of the production configuration, using the same Proxmox VE release, storage types and network layout where possible. The upgrade runs there first, with the same steps and checks, and any guest that behaves differently after the upgrade is recorded. Where the test copy uses the no-subscription repository, the team notes that difference so production behavior is not assumed from the test result. The client provides a non-production environment or approves the one DeployOpen builds, and reviews the findings. The step closes with a test report listing each deviation, the fix or workaround, and a go or no-go decision recorded in writing.
Upgrade production nodes one at a time
Production nodes are upgraded in the order set in the plan, one node at a time. Before each node, the team confirms cluster quorum is healthy, that HA resources are in a known state, and that a current backup exists for guests on that node. Guests are migrated or stopped as the plan requires, the node is upgraded, rebooted and checked for cluster membership and storage access before the next node begins. If quorum or storage checks fail, the rollout pauses and the approved rollback applies. The client's operations contact approves each node's start and sees the check results. The step is done when every node reports the target release, cluster quorum is intact, and the change log records each node's upgrade.
Verify guests, backups and HA behavior
After the last node is upgraded, DeployOpen checks that every guest starts, reaches its expected network and storage, and runs its application health checks. Scheduled backup jobs are run or confirmed, and at least one restore is tested to show the backup path still works on the new release. HA behavior is verified by reviewing HA group and resource status and, where the client agrees and the environment allows, a controlled failover test on a non-critical guest. Findings are logged against the inventory. The step closes with a signed verification checklist that the client's operations lead accepts, and any open items are assigned an owner and a date.
Hand over the runbook and support model
DeployOpen delivers a runbook that covers the upgraded topology, the node order and procedure used, the rollback steps, repository and subscription settings, backup and restore procedures, and the monitoring checks the operators should watch. The support hand-off states who the client contacts for Proxmox VE issues, which subscription tier and ticket entitlements apply, and whether DeployOpen support or a retainer covers later upgrades. The client's operators walk through the runbook with the team, and the handover is complete when they can perform a node reboot and a restore test from the document alone. Responsibilities for ongoing patching and the next major release are written into the handover.
How the Proxmox VE 8 to 9 upgrade path is planned
Plan the Proxmox VE 8 to 9 move around Debian, because each Proxmox VE release is built on a matching Debian release. Proxmox states that a Proxmox VE version is supported at least as long as the matching Debian release has Debian security support, which is roughly three years. Proxmox VE 8 runs on Debian 12, and Proxmox VE 8 on Debian 12 reached end of life in August 2026. Proxmox VE 9.0 was released on August 5, 2025 on Debian 13. Any node still on Proxmox VE 8 should be treated as a dated platform, and the upgrade date should be set by the support window rather than by the convenience of the next maintenance slot.
Start with the target version. Read the release notes for the exact Proxmox VE 9 release you intend to deploy, including any notes on changed defaults, deprecated packages, storage behavior and API changes. Confirm the current point release, since Proxmox VE 9.1 followed 9.0 on November 19, 2025 and later releases may change the picture again. Then confirm the official upgrade procedure for your exact starting version, because the steps differ depending on which Proxmox VE 8 minor release each node runs. Record the starting version of every node, not only the first one you upgrade, so the runbook matches the fleet as it actually is.
Review the dependencies that the stock upgrade will not check for you. Inventory custom packages and any repositories you added by hand, third-party monitoring or backup agents, storage drivers and multipath or HBA tooling, and kernel modules that your hardware depends on. List every script or tool that calls the Proxmox VE API, including provisioning pipelines and monitoring integrations, and check that each one uses endpoints and token scopes that still exist in the target release. Confirm that your enterprise repository key is valid for the target release, since production nodes depend on it for updates. Each item on this list should have an owner and a pass or fail result before the change window is booked.
Run a test upgrade before any production node is touched. Clone representative hosts or create test VMs that match your hardware profile, storage backend and network layout, then carry them through the full procedure including a reboot and a check of guest startup. A test on a single generic VM will not reveal driver, storage or NIC issues that only appear on your hardware. Measure what you can observe, such as the time to complete each step and the guests that fail to start, and use those observations to refine the rolling plan for the cluster. Keep the clones until the production upgrade has been verified, so you can repeat a failed step without rebuilding the environment.
Decide the cluster sequence and the rollback position before the first production change. Upgrade one node at a time, moving guests off the node and confirming quorum and storage health before continuing. Make sure a verified backup exists for every guest, and confirm that restore works on the target version. Ask your partner or internal team to state in writing which steps are reversible, which are not, and who has authority to stop the rollout. Note that the planning work here is independent of your subscription tier, but the enterprise repository still determines where production updates come from during and after the move.
How rolling upgrades differ for standalone hosts, clusters, HA and Ceph
On a standalone host there is no other node to receive guests, so the upgrade plan is built around the maintenance window. Guests either stop for the reboot or are shut down deliberately beforehand, which makes the outage visible and predictable. The main risk is not the upgrade itself but being unable to recover if something goes wrong during the reboot or the package changes.
Practical checks:
- Confirm a current, restorable backup of every guest and of the host configuration, and test that at least one guest restores on separate hardware or storage.
- Record the running package versions and guest list so you can compare before and after the upgrade.
- Agree the window and the shutdown order with the application owners, including any guests that must start first.
- Check free disk space on the root and boot partitions and confirm the console or out-of-band access works in case the host does not return.
- Review the repository configuration so the host pulls from the intended repository before you run the upgrade.
Before the window opens, confirm with the application owners that the restore test and the rollback plan cover every guest that will be down.
In a multi-node cluster without HA, the nodes share configuration but not automatic failover. Each node can be upgraded and rebooted in turn, but guests on that node will not restart elsewhere unless someone moves them first. The plan therefore centers on relocating guests before each reboot and confirming that the cluster is healthy before moving to the next node.
Practical checks:
- Plan guest moves before each node reboot so that no node is taken out while it still runs workloads that cannot tolerate the outage.
- Confirm the destination nodes have enough free memory and CPU for the guests moved onto them, and that the guest configuration does not depend on hardware only the source node has.
- Watch cluster health with the cluster status view and confirm all nodes show as quorate and online before and after each reboot.
- Upgrade one node at a time and wait until the node has rejoined and its services are stable before starting the next.
- Keep the enterprise repository consistent across nodes so that every node reaches the same package set.
After each node returns, confirm that the moved guests are running as expected and that the cluster has returned to a fully healthy state before continuing.
HA clusters add automatic recovery, which changes the upgrade order. Proxmox VE needs at least three cluster nodes for reliable quorum, and watchdog-based fencing resets a failed node before its guests are recovered elsewhere. A planned reboot during an upgrade can trigger that recovery path, so the HA configuration must be understood before any node is restarted.
Practical checks:
- Confirm the cluster has at least three nodes and that quorum is maintained while one node is out of service.
- Check the HA group settings for each guest, including node priorities and restricted or nofailback options, so recovery goes to the nodes you expect.
- Set the affected guests to a known state before the reboot, either by pausing their HA management or by moving them, so the fencing and recovery behavior is predictable.
- Verify the watchdog and fencing configuration on every node, since a misconfigured watchdog changes what happens during an unplanned failure.
- Set the upgrade order deliberately, starting with nodes that host the fewest HA resources, and confirm the shared storage is reachable from the destination nodes.
Before starting, run a controlled failover test on a non-critical guest to confirm that recovery behaves as the HA group settings describe.
When guest disks live on Ceph or other network storage such as iSCSI or NFS, a node reboot affects more than its own guests. Ceph monitors, object storage daemons and the network paths between nodes all participate in serving disk I/O. Taking a node out of service can reduce redundancy or stall storage if the remaining components are not healthy, so storage and network state are checked before each node is touched.
Practical checks:
- Confirm the Ceph cluster reports healthy status and that data is fully replicated or recovered before taking any node out.
- Check that enough monitors and storage daemons remain available with the node removed, and confirm the replication settings tolerate one node being down.
- Verify network paths for the storage and cluster networks, including bonds and redundant links, so that losing one node does not isolate others.
- Confirm shared storage mounts such as NFS or iSCSI are reachable and stable from the nodes that will remain in service.
- Wait for recovery traffic to finish after a node returns before starting the next upgrade, because rebalancing consumes bandwidth and can slow guests.
Confirm these conditions with your storage administrator or the Ceph documentation for your release, since the exact health states and replication requirements depend on your design.
What usually goes wrong during Proxmox VE upgrades and how to prevent it
Most failed Proxmox VE upgrades trace back to a few preventable gaps: cluster health, repository access, untested recovery, and undocumented dependencies. Each card names the failure, the prevention step, and the record that shows the step was completed before the change window opened.
Quorum lost during rolling reboots
Proxmox VE high availability needs at least three cluster nodes for reliable quorum. In a small cluster, a second node going down during a rolling upgrade can leave the remaining nodes without quorum, which blocks configuration changes and can trigger watchdog fencing on HA-managed guests. Before each reboot, confirm the cluster is quorate and all nodes are healthy, reboot one node at a time, and check status again before moving on. Save the cluster status output before and after each reboot as the change record.
Enterprise repository not configured
The enterprise repository requires a valid subscription key and is the recommended source for production updates. If a node has no key or points at the wrong repository, apt updates stall or the node drifts onto a different package set from the rest of the cluster. Confirm the subscription key is assigned to every node and the enterprise repository is enabled and reachable before the upgrade starts. The proof is the apt source configuration from each node plus a clean update run with no repository errors.
Backups never tested before upgrade
A backup that has never been restored is an assumption, not a recovery plan. Before a major upgrade, restore a representative set of VMs and containers to an isolated network and confirm each one boots and its application data is intact. Include at least one guest that uses each storage type in use, such as ZFS, LVM, NFS or Ceph. The artifact is a restore test record listing guest IDs, restore results, and the application checks performed.
HA fencing during planned changes
When HA is enabled, a node that is rebooted without first moving its HA-managed guests can be fenced by its watchdog, which resets the node and restarts guests elsewhere. This turns a planned maintenance window into an unplanned outage with possible data risk on guests that were not cleanly stopped. Before any node reboot, follow the HA maintenance procedure documented for your Proxmox VE version, confirm each HA resource has moved, and verify fencing behavior on a test cluster first. The artifact is the HA resource state list captured before the reboot.
Scripts and API tokens breaking
Custom hook scripts, backup jobs, monitoring collectors, and provisioning tools often depend on API tokens, command output formats, or file paths that nobody has written down. After an upgrade, one of these can fail silently, such as a backup job that still reports success while writing nothing. Build an inventory of every script, token, and integration with its owner, then run each one against a pilot node after the upgrade. The artifact is that inventory with a pass or fail result per integration.
No agreed rollback path
When an upgrade stalls at 2 a.m., teams without a rollback plan argue about whether to push forward or revert, and the delay often causes more damage than either choice. Agree in writing before the window opens which failures trigger a rollback, who makes that call, and what is restored, such as a boot disk snapshot, a backup, or a reinstall. Confirm with your environment team which rollback methods are realistic for your storage and hardware. The artifact is a signed rollback plan that names the decision owner and references the restore test.
What a Proxmox subscription covers and what ongoing support adds
A Proxmox VE subscription buys vendor support entitlements and access to the enterprise repository. It does not unlock software features. Proxmox states that all subscription tiers include the same software features, and that the software itself can be used without a subscription. The decision a team makes is therefore about how it wants updates delivered and how much vendor help it expects when something breaks, not about which functions it can switch on.
The two package repositories matter most for upgrades. The enterprise repository requires a valid subscription key and is the one Proxmox recommends for production. The no-subscription repository is freely accessible and is described as suited to testing and non-production use. In practice, a production cluster on the no-subscription repository still receives updates, but the operations team must decide how it will validate those packages before they reach nodes. Confirm with Proxmox which repository your subscription level grants and how the sources file on each node should be configured before a major upgrade such as 8 to 9.
Subscriptions are priced per CPU socket per year, according to the Proxmox VE pricing page. Community is listed at 120 euros per socket per year with no support tickets. Basic is listed at 370 euros with 3 tickets and a 1 business day response. Standard is listed at 550 euros with 10 tickets and a 4-hour response. Premium is listed at 1,100 euros with unlimited tickets and a 2-hour response. Socket count is the cost driver, so a dual-socket host costs twice the per-socket figure. These are recurring annual costs for every node in the cluster. Confirm current prices on the vendor pricing page before you budget, because list prices can change.
Vendor support tickets and DeployOpen retainer support answer different questions. Proxmox tickets cover product behavior and defects that the vendor can address. A DeployOpen retainer, where it is agreed in writing, covers the operational work around the platform: planning and running rolling node upgrades, applying patch cycles, reviewing monitoring checks, and keeping runbooks current with what the cluster actually does. Ask for the retainer scope in writing, including which upgrade windows are included, how emergency changes are handled, and whether the subscription tier is bought by you or handled as a separate line item.
When you compare options, ask the vendor or partner to state the subscription tier, socket count, ticket allowance and response times in one quote, along with the retainer hours or task list. Note which costs recur each year and which are one-time, such as the migration of runbooks and the first major upgrade. Plan for a Premium or Standard tier if a single outage would be costly and your staff cannot investigate platform defects alone. Plan for a lower tier or the no-subscription repository only if your staff can test packages in a non-production cluster first and accept the responsibility for that validation.
Which upgrade and support tasks stay in-house and which go to a partner
This table compares ten recurring Proxmox VE upgrade and support tasks by who usually owns them and which skills they need. Read the rows top to bottom: routine work on a stable cluster usually stays with an in-house Linux and virtualization operator, while planning the major version jump and carrying out the first rolling cluster upgrade are the points where teams most often bring in a partner.
| Task | Who usually owns it | Skills required |
|---|---|---|
| Routine patch application on a stable cluster | In-house operator | Debian package management, reading Proxmox VE release notes, node reboot sequencing |
| Change approval and scheduling | In-house operator with change board | Maintenance window planning, rollback criteria, communication with application owners |
| Major version upgrade planning (for example 8 to 9) | Partner or senior in-house engineer | Debian release upgrade path, storage and network inventory, dependency review of custom scripts and integrations |
| Test upgrade on a non-production cluster | Shared: partner builds, in-house validates | Cloned hardware or nested test setup, repository configuration, functional test scripts for guests |
| Rolling production upgrade across nodes | Partner for the first run, then in-house | Quorum-aware node drain and migration, HA state awareness, live guest checks between nodes |
| HA and quorum checks | In-house operator | Understanding of three-node quorum, watchdog status, shared storage health and HA resource states |
| Backup verification and restore testing | In-house operator | Backup job configuration, Proxmox Backup Server administration, test restores of VMs and containers |
| Repository and subscription administration | In-house operator | Enterprise versus no-subscription repository setup, subscription key handling per node, apt source configuration |
| Vendor ticket handling | In-house operator with partner escalation | Clear diagnostics, log collection, understanding of the subscription tier's response targets |
| Runbook maintenance | In-house operator, reviewed after each upgrade | Technical writing, documented node order, rollback steps and verification commands |
What buyers ask before hiring help for Proxmox VE upgrades
How much does a Proxmox VE upgrade cost?
DeployOpen does not publish a price list, so the cost comes from the written scope. The factors that move it most are the number of clusters and nodes, whether the cluster runs high availability with shared or Ceph storage, how many guests and custom integrations must be checked after the upgrade, and how many change windows the work needs. The repository and subscription decision also affects the total. Proxmox VE subscriptions are a separate recurring cost paid to Proxmox Server Solutions and priced per CPU socket per year. Proxmox's pricing page lists Community at 120 euros, Basic at 370 euros, Standard at 550 euros and Premium at 1,100 euros per socket per year. Ask for a quote that separates one-time service work from recurring subscription and retainer fees, and confirm current subscription prices with Proxmox.
How long does a Proxmox VE upgrade take?
Duration is set by the scope, so no fixed figure applies. The main drivers are the node count, whether high availability and shared storage must stay available while each node is upgraded, the storage types in use such as LVM, ZFS, Ceph, NFS or iSCSI, the number of guests that need post-upgrade checks, and how many maintenance windows the client allows. A test run on a copy of the cluster adds time at the start but can reduce surprises in the production window. Deadlines also matter. Proxmox VE 8 on Debian 12 reaches end of life in August 2026, so the planning window should start well before that date. Ask for a schedule tied to milestones and change windows, and confirm the current upgrade notes from Proxmox before setting dates.
What does the client need to provide for a Proxmox VE upgrade?
The client provides access, decisions and evidence. Expect to supply administrative access to every node, the management network and any out-of-band console, along with named owners for the hypervisor, storage, network and application teams who can approve changes. Agree change windows for each node in advance, with a rollback point for each one. Current, tested backups are needed before any node changes, so confirm that backup jobs have restored successfully, whether they use the built-in backup tool or Proxmox Backup Server. Also provide the subscription details: the key, the tier and the nodes it covers. An inventory of guests, storage pools, VLANs, firewall rules and third-party scripts keeps the scope accurate. Put these items in writing before work starts.
Can a small team upgrade Proxmox VE without outside help?
Yes, a small team can often upgrade Proxmox VE itself if it follows the official upgrade procedure and runs a full test first. Start by building a test cluster that matches production as closely as practical, using the no-subscription repository there, and rehearse each step. Check that backups restore, that cluster quorum holds during each node reboot, that HA fencing with watchdogs behaves as expected, and that storage pools, VLANs and bridges return correctly after reboot. Record package and kernel changes, and keep a rollback plan for each node. Confirm the upgrade notes for your exact version path before you begin, because release details change. If the team lacks time or clustering experience, a fixed-scope engagement can cover the same steps.
Does Proxmox VE require a paid subscription to run?
No. The software can be installed and run without a Proxmox VE subscription. The difference lies in repositories and support. The enterprise repository requires a valid subscription key and is the recommended repository for production, while the freely accessible no-subscription repository is intended for testing and non-production use. All subscription tiers include the same software features. They differ in support tickets, response times and access to the enterprise repository. Proxmox lists its tiers per CPU socket per year on its pricing page, with Community at 120 euros, Basic at 370 euros, Standard at 550 euros and Premium at 1,100 euros. Decide the repository policy before the upgrade, because production nodes on the no-subscription repository need their own risk review. Confirm current terms with Proxmox.
What happens to a Proxmox VE environment after handover?
After handover, the client chooses between a retainer and its own team. A retainer covers ongoing support, upgrades and continuous testing, which suits teams that want a provider available for node updates and future major releases. Teams that keep operations in-house receive the runbook, configuration records, test results and rollback notes, along with a walkthrough for the people who will run the next upgrade. Either path needs a named owner, a patch schedule and a settled subscription decision. DeployOpen plans, implements, documents and supports self-hosted platforms inside the client's own infrastructure, so the environment stays under the client's control. Ask in the quote which deliverables are included, what the retainer covers and what is excluded.
How DeployOpen scopes, delivers and supports Proxmox VE upgrades
DeployOpen plans each Proxmox VE upgrade as a fixed-scope engagement, then carries out the work inside your own infrastructure and documents the result. Scope, deliverables and timelines are agreed in writing before work starts. Ongoing support, upgrades and testing are available as a retainer, so the platform stays current after handover.
How we scope
- The written scope names each cluster, node and guest affected by the upgrade.
- Current version, target release and Debian base are checked against vendor release notes.
- Subscription tier, repository access and support entitlements are listed as scope assumptions.
How we build
- Upgrade rehearsal runs on a staging cluster built from production configuration and backups.
- Nodes move one at a time, with guests migrated off each node before its upgrade begins.
- Enterprise repository access is confirmed with a valid subscription key before package updates run.
How we hand over
- Written runbook covers the upgrade steps, rollback points and post-upgrade checks for your team.
- Test results record guest status, HA behavior, backup jobs and storage health after each node.
- Your team receives access and documentation for the repository, subscription and backup settings.
How we support
- Retainers cover ongoing support, upgrades and testing once the cluster is handed over.
- Confirm who opens Proxmox support tickets and who holds the subscription key.
- Support scope follows the agreed retainer, so each request is matched to written terms.
