Infrastructure

Managed Proxmox

Assistance-operated virtualization on dedicated physical hardware

Managed Proxmox

Managed Proxmox is an Assistance-operated virtualization platform for teams that want predictable VM and container infrastructure on physical servers / dedicated physical hardware. It is a platform choice when the customer needs more control than a public-cloud managed service, but still wants Assistance to operate the virtualization layer, backups, monitoring, and change workflow.

This documentation is both a buyer/user guide and an operator runbook. It explains how to evaluate fit, what must be true before Assistance accepts operational responsibility, which decisions affect reliability, and where customer ownership remains required.

Documentation map#

Evaluation and fit

Physical-server prerequisites

Platform architecture

Storage and networking

Backups and restore testing

Monitoring, alerts, and security

Onboarding, takeover, and migration

Day-2 operations and support

Choose Managed Proxmox when#

  • you need dedicated physical hardware for cost, isolation, licensing, latency, procurement, private-network, or existing-VM reasons;
  • VM-based workloads are easier to migrate than a full Kubernetes or application modernization project;
  • development, staging, CI, internal services, legacy systems, or steady production workloads need predictable capacity;
  • existing VMware, Hyper-V, bare-metal, or unmanaged Proxmox workloads need a clearer operator and safer runbooks;
  • the customer wants Assistance to operate the Proxmox cluster without giving up application, data, approval, and business ownership.

Avoid or reassess Managed Proxmox when#

SituationBetter next step
Workloads need rapid cloud-region elasticity or managed cloud primitivesEvaluate customer-cloud services or Managed Kubernetes.
The application is already containerized and platform automation is the main needCompare with Managed Kubernetes before choosing VM operations.
No one can approve hardware, facility, connectivity, access, backup, or support decisionsResolve governance first; Assistance cannot safely operate an undefined physical boundary.
The primary requirement is a legal compliance guaranteeScope controls, evidence, and legal responsibilities separately. This page is not a compliance attestation.
Restore objectives are business-critical but untestedScope restore exercises and application-level validation before go-live.

What Assistance operates#

AreaAssistance responsibility
Physical platformHardware sizing guidance, host baseline, storage layout, network topology, remote-management assumptions, and capacity review
Proxmox runtimeCluster configuration, VM/LXC templates, upgrade planning, patch workflow, permissions, and operational runbooks
ReliabilityBackup policy implementation, restore exercises when scoped, maintenance windows, incident triage, and recovery notes
SecurityAdministrative access model, TLS, firewall baseline, least-privilege recommendations, vulnerability review, and audit evidence where scoped
ObservabilityHost health, storage pressure, VM availability signals, backup status, alert routing, and support handoff notes
ChangesPlanned VM, network, storage, upgrade, access, and maintenance changes with approval and rollback notes

What the customer owns#

AreaCustomer responsibility
ApplicationsWorkload behavior, guest OS and application configuration inside customer-owned VMs unless separately scoped
DataClassification, retention rules, legal requirements, restore acceptance, and application-level validation
Access approvalsUser lifecycle decisions, identity source of truth, internal approvals, and access reviews
Business decisionsLaunch timing, downtime acceptance, customer communications, and risk tradeoffs
Hardware or billing modelProcurement, colocation, connectivity, and provider contracts unless Assistance ownership is explicitly contracted

Standard lifecycle#

  1. Assessment — inventory workloads, resource needs, storage, network dependencies, backup expectations, compliance drivers, support needs, and current pain points.
  2. Platform design — confirm physical server sizing, storage, network, tenancy boundary, VM/LXC conventions, monitoring, support tier, and change approvals.
  3. Build or takeover — provision the Proxmox environment or baseline an existing one before Assistance accepts operational responsibility.
  4. Workload migration — move pilot workloads with rollback plans, restore validation, and customer acceptance checks.
  5. Operate — manage updates, capacity, backups, incidents, access, documentation, and planned changes inside the agreed boundary.

Common change requests#

Use the agreed support channel for new VMs, resource changes, VLAN/firewall updates, DNS records, backup scope changes, restore requests, host maintenance, storage expansion, user access, and Proxmox version upgrades. Emergency requests cover host failures, storage exhaustion, unavailable workloads, suspected compromise, and backup or restore failures affecting covered systems.

Getting started#

Request a Managed Proxmox assessment with workload inventory, capacity targets, physical-hardware constraints, network requirements, backup expectations, support needs, migration source, and migration or go-live deadlines.

Request Managed Proxmox assessment →