Nexaplane · Proxmox integration

Nexaplane and Proxmox VE

Nexaplane is a multi-tenant cloud orchestration and billing platform for Proxmox Virtual Environment. It runs as a single container beside the clusters you already operate and drives them over the PVE API — nothing is installed on your hypervisors, nothing is patched, and a Proxmox upgrade stays an ordinary Proxmox upgrade. On top of that fleet it adds the parts Proxmox does not ship: tenancy, per-tenant networking, self-service provisioning, metered billing and a white-label customer portal.

Architecture

One service beside the fleet.
Nothing on the hypervisors.

The integration is deliberately shallow where it touches your infrastructure and deep where it touches your business. Everything Nexaplane asks of Proxmox goes through the API Proxmox already publishes; everything your customers see is Nexaplane's own.

The Nexaplane Proxmox integration at a glance
Integrates with Proxmox Virtual Environment, over its REST API
Installed on hypervisors Nothing. No agent, no patched package, no repository of ours on any node
Where Nexaplane runs A single lightweight container, inside your management cluster or outside your fleet entirely
Workloads Virtual machines and LXC containers
Storage Your ZFS, Ceph and LVM pools, presented to customers as tiers you name
Guests Cloud images with SSH keys and network configuration injected at create. Windows guests with UEFI and TPM 2.0
Migration Live, same-cluster, cross-cluster and cross-datacenter, with progress and bandwidth control
Scope Several clusters and standalone nodes, across sites, under one console
Existing workloads Left alone. Nexaplane attaches to the fleet you run rather than replacing it
Read-only mode Nexaplane keeps monitoring a datacenter while making no changes to it
Licensing Per fleet, not per tenant or per customer. Community is free and perpetual on up to 2 hypervisors

The PVE API

What Nexaplane asks
Proxmox to do.

Proxmox is a very good hypervisor manager, and the integration treats it as one. These are the operations that go to your cluster.

Compute

Instances, created and destroyed

  • VM and LXC provisioning from your images
  • Cloud images booting with SSH keys and network configuration already injected
  • Windows guests with UEFI and TPM 2.0 at create
  • Console, media, snapshots and resize

Storage

Your pools, your names

  • ZFS, Ceph and LVM pools
  • Mapped to tiers a customer understands — NVMe or capacity
  • Volumes attach and detach live
  • Storage identifiers stay yours, not your customers'

Movement

Live migration, anywhere

  • Between nodes in a cluster
  • Between clusters, and between datacenters
  • Real-time progress and bandwidth control
  • Clone an instance to wherever you need a copy

The other half

What Proxmox does not ship,
and a cloud business needs.

None of this is asked of your hypervisors. It is the part that turns a fleet into a product — and the reason the integration is worth having rather than a set of scripts around the API.

Tenancy

Every tenant gets an isolated network and a real virtual router of their own — NAT, firewall, VPN, DHCP and DNS — with BGP, OSPF, WireGuard and IKEv2 where their network needs them. Dual-stack IPv4 and IPv6 throughout, load balancers with automatic TLS certificates, and high-availability pairs for both.

Commerce

Plans, quotas, taxes and invoicing are inside the platform. Every resource is metered by the hour, Stripe and PayPal are handled natively, prepaid credits and post-paid invoicing both work, and an account with a zero balance suspends on its own.

The customer's side

A self-service portal carrying your logo, product name, colours and support address — and your resellers' on top of that. Sixteen languages, chosen per person rather than per installation, with Arabic laid out right to left.

Backups you can prove

Policy-driven backups with retention and integrity verification, self-service restore for customers, and recovery rehearsals: a real backup restored into an isolated network, booted, confirmed to have answered, then destroyed. You are left with a date and a boot time instead of an assumption.

Products from hardware

GPUs found across the fleet, grouped by model and turned into sellable flavours with their own capacity and quota weight. Storage tiers you define. Cross-datacenter interconnects sold as a service.

Accountability

An audit trail of every action, per user, and a fleet-wide console showing cluster health, capacity and every customer action in one place — plus the read-only mode for nights when you are working on the fabric yourself.

Scale

One control plane,
many clusters.

A Nexaplane install is not scoped to a cluster. It manages several Proxmox clusters and standalone nodes at once, across datacenters, from one console — which is what makes a second site an expansion rather than a second platform to operate. Tenants can hold networks in more than one of them and reach between them over interconnects, and cross-datacenter disaster recovery is granted as a per-account entitlement rather than being a property of the whole installation.

Licensing follows the same shape: Nexaplane is licensed per fleet, by hypervisor count, not per tenant and not per customer. Adding customers to a cluster you already run costs nothing more. The Community tier is free and perpetual on up to two hypervisors — the same build paying licensees run, and running paying customers on it is permitted.

Developer first

Everything the console does,
the API does.

There is no second-class API. Provisioning fleets, changing network rules, wiring billing into your CRM — the same documented REST endpoints the console itself calls.

POST /api/v1/instances

curl -X POST https://cloud.yourcompany.com/api/v1/instances \
  -H "Authorization: Bearer np_live_9a8b..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "web-node-01",
    "plan": "np-compute-4",
    "image": "ubuntu-24.04-lts",
    "region": "ca-central-1",
    "network": "tenant-prod",
    "billing": { "type": "hourly" }
  }'

Note what the request does not contain: a node name, a storage identifier, a VMID. Your customers — and your own automation — work in plans, images, regions and networks, and Nexaplane resolves those onto the Proxmox fleet. That indirection is the integration. It is also what lets a VM move between nodes, clusters and datacenters without anything a customer holds becoming wrong.

Adopting it

You don't rip anything out first.

Nexaplane attaches to the fleet you already operate. Existing virtual machines keep running as they are, on the storage they are on, managed the way you manage them today — and the tenant-facing platform is built beside them. There is no cut-over weekend, no rebuild of the cluster, and no moment where the thing paying your bills depends on something you have not run before.

That is also why the free tier is shaped the way it is. Community covers up to two hypervisors, perpetually and with no maintenance fee, and it is the same build the paid tiers run — so the honest way to evaluate the integration is to point it at a real pair of nodes and use it. A 45-day evaluation on up to three nodes exists separately for trialling the paid tiers.

Running the edge as well as the fleet? NuajProtect filters hostile traffic before it reaches the hypervisors, and Nexaplane can sell that protection on as a tier of your own — margin rather than a referral. It is licensed separately and is not included with Nexaplane.

Questions

About the integration.

Does Nexaplane install anything on my Proxmox hosts?
No. Nexaplane runs as a single lightweight container beside the fleet — inside your management cluster or outside it — and drives Proxmox over the PVE API. There are no agents baked into your hypervisors, no patched packages and no repository of ours on any node, which is what makes a Proxmox upgrade an ordinary Proxmox upgrade.
Can Proxmox be made multi-tenant?
Yes. Nexaplane adds multi-tenancy on top of Proxmox Virtual Environment: every tenant gets an isolated network and a real virtual router of their own — NAT, firewall, VPN, DHCP and DNS — behind a self-service portal, without changing how the hypervisors themselves are run.
What does Nexaplane use the Proxmox API for?
Everything it asks the hypervisors to do: creating and destroying VMs and LXC containers, attaching and detaching volumes on your ZFS, Ceph and LVM pools, snapshots, resize, console access, and live migration between nodes and clusters. Tenancy, networking, billing and the customer portal are Nexaplane's own — it does not ask Proxmox for those, because Proxmox does not have them.
Do I have to rebuild my cluster or move my existing VMs?
No. Nexaplane attaches to the fleet you already run and leaves what is on it alone. Existing workloads keep running exactly as they are while you build the tenant-facing side beside them, which means the migration is additive: nothing is ripped out first, and there is no cut-over weekend to survive.
Does Nexaplane work across several Proxmox clusters and datacenters?
Yes. One Nexaplane manages several clusters and standalone nodes across sites, with cross-cluster and cross-datacenter live migration, cross-datacenter interconnects for tenants, and disaster recovery granted as a per-account entitlement. The fleet console shows cluster health and capacity for all of it in one place.
How do I bill customers for Proxmox virtual machines?
Billing is part of the platform rather than a second system to run. Plans, per-account limits, taxes and invoicing are built in, every resource is metered by the hour, Stripe and PayPal are handled natively, and accounts suspend on a zero balance. What a tenant provisions in the portal is what they are billed for.
Can Nexaplane watch a datacenter without changing anything in it?
Yes — there is a read-only mode for exactly that. Nexaplane keeps monitoring the site and makes no changes to it, which is what you want on the nights you are working on the fabric yourself.

Next

See it against
your own fleet.

The fastest way to judge an integration is to point it at real nodes. Community is free and perpetual on up to two hypervisors — or ask us for a walkthrough first.