Hybrid Cloud

Most teams start with self-hosted infrastructure. You buy servers, rack them, install Proxmox, and run your workloads. That works great until Black Friday hits, a product launch goes viral, or a customer onboards with twice the expected load. You can't rack new servers in an afternoon.

flex.plane lets you manage your Proxmox clusters and cloud providers like Hetzner from a single control plane. Same API, same portal, same workflow. When your on-premises capacity runs tight, you burst workloads into the cloud. When the peak passes, you scale back down.

See how it works

Every piece of infrastructure in flex.plane belongs to a zone. A zone can be a Proxmox cluster in your data center or a cloud region at Hetzner. The orchestrator treats them the same. When you create a VM, you pick a zone, and flex.plane handles the rest regardless of what runs underneath.

This means your team does not need separate tools for different providers. No switching between the Proxmox UI and the Hetzner console. No learning two different CLIs. One GraphQL API. One portal. One set of roles and permissions.

# Create a VM on your Proxmox cluster
mutation {
  createVM(
    zone: "eu-central"
    name: "web-server"
    options: {
      image: "ubuntu-2404"
      computeProfile: "medium"
      interfaces: [{ network: "100" }]
    }
  ) { id name host { name } }
}

# Create a VM on Hetzner Cloud with the same API
mutation {
  createVM(
    zone: "hetzner-nbg"
    name: "burst-worker"
    options: {
      image: "ubuntu-2404"
      computeProfile: "cx42"
    }
  ) { id name }
}

Handle load peaks with cloud bursting

Your Proxmox clusters handle daily workloads. That is what they are built for. But when demand spikes, you need more capacity than your hardware can deliver. Cloud bursting lets you spin up additional VMs at a cloud provider to absorb the extra load, then tear them down when the peak passes.

This is not about replacing your servers. It is about complementing them. Your core infrastructure runs on hardware you own and control. The cloud is your overflow valve. Some common scenarios:

• Seasonal traffic: E-commerce platforms during holiday sales, tax software during filing season
• Product launches: Marketing campaigns that drive unpredictable traffic
• Batch processing: End-of-month reports, data migrations, ML training jobs that need temporary compute
• Customer onboarding: A new large customer comes online before you can expand physical capacity

The economics are straightforward. Running VMs on your own hardware is cheaper per hour than any cloud provider. But buying hardware for peak capacity that sits idle 90% of the time is wasteful. Cloud bursting gives you the best of both: low baseline costs on your own servers, elastic overflow when you need it.

Use your self-hosted infrastructure for the heavy lifting

Proxmox is flex.plane's primary and most complete provider. Your self-hosted clusters give you the full feature set: live migration, snapshots, edge gateways, Kubernetes clusters, custom networking, and fine-grained storage control. This is where your steady-state workloads run.

The Proxmox provider communicates with your nodes through the agent, which handles authentication and image management on each host. The orchestrator never stores your Proxmox credentials. It does not need to. The secure mesh network and the agent handle that transparently.

Extend to cloud providers when you need more

Cloud zones give you on-demand capacity without buying hardware. Today, flex.plane supports Hetzner Cloud as an additional provider. VM lifecycle, networking, and basic monitoring work through the same API your team already uses.

Not every feature is available on every provider. Self-hosted Proxmox gives you the full platform. Cloud providers offer a subset based on what their APIs support:

The pattern is deliberate. Run your core workloads on Proxmox zones where you have full control. Use cloud zones for burst capacity, geographically distributed endpoints, or workloads that benefit from cloud elasticity.

Add more providers

The provider model is extensible. Each provider implements a standard interface, so adding support for a new cloud provider does not require changes to the API, the portal, or any existing workflows. A new provider slots in as another zone option and works with the same compute profiles, roles, and VDC isolation your team already uses.