vManager
Proxmox orchestration, built for agentic AI
The first agent-first control plane for Proxmox VE. Give an AI agent a scoped API key and it can discover, provision, network, reconfigure, inspect and retire infrastructure end to end. No human UI required.
A product-faithful demonstration with fictional data: fleet inventory and hierarchy on the left, capacity and node health in the center, and durable task history below.
The API is the product. The UI is optional.
vManager gives software agents a complete operational surface, not a handful of webhooks bolted onto a panel. The web interface is one API client, with no private control path behind it. An AI agent can run the fleet directly, without browser automation or a human clicking through a wizard.
End-to-end operations
Discover inventory and capacity, preview placement, create or resize KVM and LXC guests, allocate addresses, control power, inspect health, reconcile state and retire resources through structured REST calls.
Scoped authority
Named, revocable API keys carry explicit permissions. Per-machine limits and fleet quotas bound what an agent may create, while sensitive powers such as console input and guest execution stay separate.
Work an agent can reason about
Placement failures explain the rejected constraint. Tasks expose durable state and individual steps. Node commands are idempotent, and lifecycle sagas resume after a restart instead of hiding partial work.
Built for fleets that live behind NAT
Most panels need to reach your hypervisors. vManager works the other way round, and that single decision removes a class of exposure other tools ask you to accept.
The node dials out; the control plane never dials in
Each agent opens one outbound gRPC stream to the control plane over mutual TLS and keeps it alive. Hypervisors expose no management port to the internet, require no VPN back to the panel and add no inbound firewall exception to defend during an audit.
Proxmox tokens stay on the node
The agent talks to 127.0.0.1:8006. Hypervisor credentials are never uploaded, never stored centrally, and cannot leak from a database they were never in. The agent's private key is generated on the node and never leaves it.
Lifecycle changes run as sagas
Creating a server is a durable sequence whose reversible steps carry compensation. If a step fails, completed work is unwound; if the control plane restarts mid-flight, the task resumes. Irreversible disk growth is deliberately ordered last.
Reconciliation against the hypervisor
An on-demand reconciliation run compares the registry with what Proxmox actually reports: unknown guests, missing machines, and configuration or power state that no longer matches. Drift is surfaced as a list, not discovered during an incident.
A scheduler that explains itself
Regions and maintenance mode are first-class. Placement weighs available memory, vCPU and storage, and only considers nodes that already hold the requested image. When nothing fits, the response explains which constraint rejected each node.
Addresses from your IPAM
IPv4 and IPv6 are drawn from NetworkList pools inside the creation saga and returned when the machine is deleted. Allocation is idempotent per request, PTR names follow a template, and anti-spoof rules are kept in step automatically.
Networking configured inside the guest
Debian/ifupdown, Ubuntu/netplan, RHEL/NetworkManager, CentOS 7 scripts and Windows netsh. The stack is detected by asking the guest, not by trusting the image name — a hand-built Debian may well be running netplan. Second addresses apply without a reboot.
VMs and containers, one registry
LXC lives beside KVM with the same lifecycle, ownership and task history. Host device pass-through — a shared GPU, for instance — is performed by the agent from its own allow-list, which the control plane cannot widen.
A watchdog that tells the difference
A machine that stopped answering is not the same as a guest agent that was never installed. After a configurable threshold, the watchdog queues evidence-only diagnostics without restarting anything. When the guest agent responds, vManager also reports filesystem usage from inside the VM.
The rest of the day-to-day
The things you stop thinking about once they work.
- Image catalog. Order by code —
debian-13-cloud— instead of a template number that differs on every node. Placements are derived from inventory, so the scheduler only offers nodes that already hold the image. - Memory policy per plan. Fully guaranteed or ballooned, decided by the service plan. The scheduler places against the guaranteed floor and can enforce a separate ceiling on aggregate configured peaks.
- Power operations that mean it. Graceful shutdown through the guest agent, escalating to force on timeout — rather than pulling the plug and hoping the filesystem was idle.
- Fine-grained server settings. CPU emulation mode, machine type and firmware, CPU weight and cap, interface bandwidth, disk IOPS and throughput limits, hot-plug. For settings embedded in Proxmox compound values, vManager patches the relevant property instead of rebuilding the string, preserving the interface MAC and disk volume ID.
- An inventory tree with inherited settings. Stable
urn:identifiers, values inherited down the tree, populated automatically from regions and nodes. - Users and directories. Local accounts with Argon2id, a first administrator that bootstraps itself, and a provider interface for directories to come.
- A REST API for billing, automation and AI agents. The panel is one client, not a privileged control path. Named keys expose the same versioned routes under explicit permissions, so infrastructure operations do not depend on a human interface.
Shipping next
Two pieces are already on the near-term release path. They are shown here as upcoming, not as features in the current release.
VNC and serial console in the browser
A one-time ticket opens the VM screen or serial port in a separate window. The session travels through the agent's existing outbound tunnel, so console access does not add an inbound port to the hypervisor.
Live operations over SSE
A server-sent event stream will replace task polling with live transitions and progress. Panels, automations and agents will be able to follow long-running work without guessing a polling interval.
How it is put together
A modular monolith rather than a constellation of services: module boundaries are drawn with packages and interfaces, so a module can be split out later when there is a real reason — and not before.
Control plane
Go, with PostgreSQL as the single source of truth. Schema migrations are embedded; the node registry, inventory, task queue and one-time tokens all survive a restart of the process.
Agent
Deliberately dumb. It executes idempotent primitives from a versioned contract — repeat a command with the same id and you get the stored result back, not a second machine. All business logic stays in the control plane.
Enrolment
A node joins with a single-use token and pins the CA fingerprint. The agent submits a CSR; the private key is generated on the node and never travels. Silent sessions are reaped centrally.
See it on your own fleet
We will walk you through the API, the current web panel and an agent enrolling from a node behind NAT — and answer what it would take to run it against your hypervisors. The browser console and live SSE task stream are available as an upcoming-release preview.
Request a demo