5 posts tagged with "Billing"

Version v3.1.7 opens the platform's telemetry to your customers: Metrics Export adds Prometheus-format scrape endpoints on the user API, so a customer can point their own Prometheus or Grafana at the panel and chart their instances, managed databases and load balancers with the API token they already have. The second headline is the Import Doctor: virtual machines imported from Hyper-V, VMware or other platforms - which typically blue-screen on first boot because their disk drivers were never armed for our hardware - are now detected automatically and repaired with one click. Around them, a Fix Monitoring action repairs broken telemetry on managed services in one step, Kubernetes plan rotation picked up the fixes from its first weeks in the field, and the user panel's list pages were made consistent end to end.

Metrics Export​

• [Feature] Prometheus Scrape Endpoints - GET /api/metrics returns every instance, managed database and load balancer the account owns as one Prometheus text exposition, with per-resource endpoints alongside it for narrowly scoped scrape jobs. Authentication is the same bearer token used everywhere else on the user API - there is no separate credential to mint. Metric families are stable and customer-facing (hv_instance_*, hv_db_*, hv_lb_*), with resource id and name labels and no internal topology in the output. Instances include Kubernetes worker nodes and VPN gateway backing VMs.
• [Feature] Built for Scrapers, Not Browsers - The endpoints answer HTTP 200 always: a backing store being unreachable surfaces as hv_resource_up 0 on the affected resources, never a 5xx that turns into an error storm in the customer's Prometheus. Scrapes are rate limited per token at 30 per minute, the account-wide endpoint caches its rendered body for 10 seconds to absorb multi-target fan-out, and the whole call runs under a hard time budget so one slow backend cannot stall the response. Subuser tokens see exactly the resources their team permissions grant, nothing more.
• [Feature] Documentation and Examples - The user API documentation gained a Metrics Export section with the full endpoint table and a ready-to-paste scrape_config snippet, and a feature guide ships with this release. The pipeline was validated end to end against a real Prometheus and Grafana stack before release.

Imported Virtual Machines​

• [Feature] Import Doctor - Customers who convert a VHDX or VMDK, write it over their instance disk and boot typically hit INACCESSIBLE_BOOT_DEVICE: installing the virtio drivers inside Hyper-V or VMware stages them but never arms them for boot, because that hardware never presents a virtio disk. The platform now fingerprints every instance disk after each cold start, and when a foreign operating system appears, the instance page shows a banner on both the user and admin panels. One click repairs it offline: the staged virtio storage drivers are armed directly in the guest's registry, stale UEFI boot entries are reset, and the firmware type is matched to what the disk actually uses. Guests where the full repair is not possible fall back to compatible SATA and e1000 emulation so they boot regardless. Detection is automatic; repair only ever runs when someone asks for it, with the guest shut off.
• [Fix] UEFI Firmware on Debian Hypervisors - UEFI guest definitions probed only the Red Hat and legacy Ubuntu OVMF firmware layouts, so on Debian hypervisors (and newer Ubuntu, which drops the legacy names too) every UEFI define failed with a missing-file error until symlinks were made by hand. Firmware is now resolved from ordered CODE/VARS pairs covering all three layouts, requiring both halves of a pair so a partial install can never mix incompatible images.

Monitoring and Managed Databases​

• [Feature] Fix Monitoring - Managed databases and load balancers gained a Fix Monitoring action that repairs the telemetry pipeline in one step: the metrics agent configuration is re-rendered and re-installed, the metrics exporter login and its grants are re-created, and the agent is restarted. It is available on the metrics tab in both panels - once per resource per 24 hours on the user side, unthrottled for admins - and a failed attempt never consumes the user's daily budget. A new monitoring:fix console command batches the same repair across every active managed service, for fleet-wide rollout after an endpoint or credential change.
• [Fix] Customer-Created Read-Only Roles - On PostgreSQL, the customer admin account could create a role but not grant it anything useful: granting membership in the monitoring and read-all roles failed with a permission error, so a read-only or Grafana login ended up empty. On MySQL and MariaDB the grant capability had been removed outright. The admin account now carries the delegation rights it needs on both engines - scoped so the hardening that removed superuser-level capabilities stays in force - and the Fix Monitoring action applies the same correction to existing databases.
• [Fix] Honest Instance Memory Graphs - Instance memory usage was derived from the guest's free-memory figure, which page cache drains toward zero on any warm Linux guest, so memory graphs crept toward 100% regardless of real pressure. The calculation now uses the guest's available-memory figure, which counts reclaimable cache as free - the same number free -m shows in its available column. Guests with older drivers keep the previous behaviour.

Kubernetes​

• [Feature] Cluster API Endpoint by Name - New public clusters serve their API endpoint by their System DNS name (k8s-<name>-cp.<your-domain>) instead of a bare IP: the name is baked into the API server certificate at bootstrap, the cluster page shows it, and generated kubeconfigs use it. The name is pinned at creation and never rewritten, since it lives inside a signed certificate distributed to customers. Existing clusters are untouched and keep working by IP.
• [Feature] Webhook Subscriptions API - The user API gained full management of webhook subscriptions (/api/webhook-subscriptions): create, list, update, delete, and per-subscription delivery history. Deliveries are HMAC-signed with a per-subscription secret, endpoints must be HTTPS, and subscriptions can filter to a single cluster. Kubernetes lifecycle events are the first event source.
• [Improvement] Plan Changes Lead Into Rotation - After changing a pool's instance plan, nothing pointed at the rotation that actually resizes the workers, so pools sat reporting drift until someone found the unlabeled icon. The edit form now says what saving will and will not do, a plan-changing save flows directly into the rotation dialog (including the separate downsize confirmation where it applies), and the drift badge itself became a clickable "Rotate now" action. Declining the dialog simply leaves the badge as the reminder.
• [Fix] Rotation Waves Apply Labels and Taints - Workers added by a plan rotation joined without their pool's labels and taints and showed no role in kubectl get nodes. Each rotation wave now applies the pool's labels and taints after the new workers are ready and before the old ones drain - exactly the moment draining reschedules pods onto them - and the role label appears promptly instead of up to a day later.
• [Fix] Rotation Dispatch Self-Heals - A rotation is launched as a detached background process, and that launch can die silently. A rotation still pending after three minutes is now redispatched once by the periodic janitor - rotations are resume-safe by design, and a healthy run is never touched - and every detached launch now leaves a forensic log so a failed spawn is diagnosable rather than a mystery.
• [Fix] Pool Deletion Cannot Strand Workers - Deleting a node pool could remove the pool record while its workers were still protected by scale-down guards, leaving live worker VMs attached to a deleted pool where no cleanup process could reach them. Pool deletion now marks every member for collection with those guards bypassed - they exist to protect a pool that is staying - and refuses to remove the pool record if any live member could not be marked. The cleanup and drain paths also learned to resolve a deleted pool's configuration, so members marked before the deletion still drain correctly.
• [Fix] Placement on Heavily Committed Nodes - A node whose allocated memory exceeded its physical total crashed the placement query for its whole group with a database range error, aborting scale-ups that had healthy capacity elsewhere. Placement and the rotation capacity gate now both measure headroom against the node's effective memory ceiling - the operator-set overcommit limit where one is configured, physical memory otherwise - so a sanctioned overcommit node counts its real headroom and an over-allocated one simply sorts last instead of taking the group down. The placement query also gained the standard maintenance, lock and deployment gates it was missing.
• [Fix] Certificate Auto-Renewal Now Scheduled - The cluster certificate renewal service shipped fully built but nothing ever ran it. It now runs daily, renewing certificates inside a 30-day window ahead of expiry.

Networking​

• [Fix] Private DNS on Dual-Homed Instances - On instances with both a public IP and a VPC interface, the first lookup of a private DNS name could stall for seconds: the VPC link shipped without its search domains, so the resolver had no reason to route private-zone queries to the VPC resolver and raced it against the public nameserver. The deploy payload now carries the VPC's DNS zones as search domains. Already-deployed guests pick this up on their next network configuration rebuild.
• [Fix] Private DNS on VPC-Only Instances - VPC-only instances could lose private-zone resolution entirely: a fallback public nameserver on the same link could permanently win the resolver's affinity, and the VPC's own resolver was not even running until the VPC had at least one zone. The gateway resolver now always runs - from VPC creation, zones or not - and VPC guests use it exclusively on that link, with public resolution forwarded upstream through it.

User Panel​

• [Improvement] Consistent Filtering Everywhere - The service list pages were brought up to one standard: URL-shareable filter state, status and facet filters, and debounced server-side search. Managed database filters that the server always supported are now in the UI; VPN gateway and scaling group search actually filters instead of doing nothing; volume search no longer breaks the table; pagination keeps your filters instead of dropping them. Columns that were already on the wire but never rendered are now shown - private IPs for databases and VPN gateways, location and plan for instances, distribution and region for images.
• [Improvement] Capacity Errors Reworded for Customers - When a deploy or scale-up fails for a capacity reason - no memory, storage or IP headroom where the resource was requested - the customer now sees a clear "contact support" message instead of raw infrastructure wording that named things they cannot see or fix. Admins are emailed the precise original error (throttled per distinct error), see it unchanged in the admin panel, and it is always logged.
• [Improvement] AI Assistant Out of Beta - The AI assistant has run long enough in production to drop the beta label. The badge and the settings-page warning are gone; nothing about its configuration changes.

Billing and WHMCS​

• [Feature] Create-Time Add-Ons - External billing provisioning now accepts additional IPv4 addresses (up to 20) and additional disk (up to 5000 GB) at instance creation. The extra disk is placed on the same storage pool as the primary and the capacity check covers the combined footprint. The WHMCS module exposes both as configurable options; they apply at creation only, by design.
• [Improvement] Hardened WHMCS Module - The module now keeps its own service-to-instance link table (auto-migrated, self-healing from the custom fields it also auto-creates), so suspend, terminate and upgrade no longer depend on an admin having manually created a custom field. Re-running CreateAccount on a linked service refuses to mint a duplicate instance, and terminating a service whose instance is already gone converges cleanly instead of failing forever. The client-area overview page was redesigned to match the panel, with live data, copyable IPs, and one-click SSO into the panel.
• [Fix] Server Host Resolution - A WHMCS server saved with only the IP Address field filled (Hostname blank) could never load plans or hypervisor groups into product configuration. All module variants now resolve hostname-or-IP consistently, honour the configured port, tolerate a pasted URL, and fail with a named message when both fields are empty.
• [Improvement] TLS Posture Made Explicit - The billing API client does not verify the master's TLS certificate, because masters are routinely addressed by IP or carry self-signed certificates and verification would break provisioning on those installs. This trade-off is now documented rather than implicit: where possible, point WHMCS at a hostname with a publicly trusted certificate.

Platform and Admin​

• [Fix] Route Debt Sweep - An inventory pass over every registered route closed a set of long-standing gaps: the kubeconfig acknowledgement button now works, users can delete their object storage access keys (the endpoint existed but was never routed), several links that led to pages that do not exist now redirect to the real pages, and two admin route groups gated on permission slugs that could never be granted are now grantable. Dead controllers, models and page stubs were removed.
• [Fix] Volume Attach Validation - Attaching a volume now verifies the target instance belongs to the same account and derives the instance's hypervisor group correctly (the previous check read a field instances do not have, and failed for every attach). Cluster-managed workers are rejected as attach targets, and subusers now see their account's volumes and instances on the volume pages.
• [Fix] Web SSH Stability - Web SSH sessions on remote or CDN-fronted masters appeared to disconnect frequently: overlapping readiness polls could each open a connection against a one-time token, and a rejected duplicate would paint a disconnect overlay over the live terminal. Polling is now single-flight and a stale socket can never steal the display from a live one.
• [Fix] Encrypted Secret Storage - Columns storing encrypted provider secrets were widened; a secret over 23 characters could previously be truncated at rest.
• [Improvement] PowerDNS Onboarding - Adding a System DNS domain whose zone already exists in PowerDNS now adopts the zone instead of failing, the delegation checker installs its DNS tooling where missing, and a zone error clears automatically once resolved. The wizard's guidance on public-suffix domains was corrected.

Upgrade notes​

• Two migrations run on upgrade: the imported-OS state column and the encrypted secret column widening.
• Deploy the master before the hypervisor agents for the VPC DNS fixes; each side tolerates the other being old. The agent release carries the memory metric fix, the Debian UEFI firmware resolution and the Import Doctor tooling - the agent installs its guest-inspection packages during provisioning or update.
• The read-only role grant fix applies to newly provisioned databases automatically. For existing databases, run php artisan monitoring:fix --type=db once (or use the Fix Monitoring button per database) to roll it out.
• Metrics Export needs no setup: it uses the metrics backends you already configured per hypervisor group. See the new Metrics Export guide for the customer-facing details and a scrape configuration example.

Version v3.1.0 is the Proxmox release. The platform now speaks Proxmox VE natively: point it at any existing PVE 8 or 9 node or cluster with a single API token, and every node is discovered, linked, and managed from the same panel, API, and billing pipeline as your KVM fleet. There is nothing to install inside Proxmox and no agent to maintain - the driver works entirely over the Proxmox REST API, with one optional one-command bootstrap on a node for the features that need host access (VPC WebSSH and exact per-NIC metering). Nothing changes for existing KVM hypervisors, instances, plans, or balances.

• [Feature] Native Proxmox VE driver - full instance lifecycle on PVE 8.0+ and 9.x: deploy, power, suspend and resume, reinstall, resize, destroy, ISO mounting, cloud-init, GPU passthrough, VM tags, and per-tenant resource pools. Agentless by design; see the section below.
• [Feature] One-token cluster onboarding - give the panel one reachable member IP and one API token, and it discovers every node in the cluster, links them all, verifies SDN and FRR prerequisites, provisions console credentials, and self-checks the token's privileges. Failures are listed per node instead of aborting the lot.
• [Feature] VPC networking on Proxmox SDN - VPCs are realized as PVE SDN EVPN zones, vnets, and subnets, with NAT gateways, hot attach and detach of VPC NICs, and automatic reconciliation. Security groups translate to the PVE firewall with accept and drop rules, IP sets, and per-VM rulesets.
• [Feature] Backups and snapshots - vzdump backup, restore, and delete per instance, optional live-restore, native PVE scheduled backup jobs with full retention control, file-level restore (browse a backup and download individual files), and VM snapshots with optional RAM state, rollback, and delete.
• [Feature] Live migration - move a running VM between cluster nodes from the panel, with an eligibility precheck, local-disk handling, target storage selection, bandwidth limits, and a dedicated migration network option.
• [Feature] High availability via the PVE CRM - instances enroll into Proxmox's own HA stack on deploy, with per-group tuning and placement rules; the panel mirrors CRM state instead of running a second watchdog.
• [Feature] Full guest-service parity - Docker deployments, managed databases (including S3 backups, point-in-time recovery, and replication), load balancers with Let's Encrypt, Kubernetes clusters, WebSSH, SSH key injection, and password resets all work on Proxmox instances through the QEMU guest agent.
• [Feature] Exact bandwidth metering - per-NIC counters are read from the host, so VPC (east-west) traffic and public traffic are billed separately and never double-counted, with reset-safe accumulation across reboots.
• [Feature] Node Issues dashboard - operational failures on a Proxmox node (metering, host access, proxy installs, firewall gaps) surface as first-class admin issues that reopen if they recur, instead of hiding in a log file.
• [Improvement] Fleet-scale collection - metrics, statistics, security-group reconciliation, and HA reconciliation all fan out per node onto a worker pool, so a large cluster is collected in parallel rather than serially.

Native Proxmox VE support​

v3.1.0 introduces a second hypervisor backend alongside KVM. A hypervisor group is now either a KVM group or a Proxmox cluster, and both kinds run side by side on one panel with the same instances, plans, billing, and user experience.

The design principle is API-only: the driver talks to the Proxmox REST API and nothing else. Your cluster keeps looking like a normal Proxmox cluster - VMs created by the panel are plain QEMU VMs you can see in the PVE web UI, tasks the panel starts are ordinary PVE tasks (UPIDs the panel tracks and can cancel), and nothing on the node is patched or replaced.

Onboarding an existing cluster​

Create a hypervisor group of type Proxmox, paste one member's address and one API token, and the panel calls the cluster status endpoint to discover every node. Each node is linked individually, storage is discovered per node with its real PVE plugin type, an @pve console credential is provisioned for VNC, and SDN plus FRR prerequisites are verified so VPC problems are caught at link time rather than at first deploy. The token itself is self-checked: the panel reports the PVE version and the privileges the token actually holds, and flags the guest-agent privilege gap that PVE 9 introduced, right on the node's detail page.

Supported: Proxmox VE 8.0 and later, including 9.x, standalone nodes and clusters. Group names must match the PVE cluster name so the group is an unambiguous mirror of the datacenter, and groups are kept homogeneous - one group is either KVM or Proxmox, never a mix.

Images and deploys​

Operating system images are built once per cluster into a vzdump archive, then every deploy restores that archive into the customer's VM ID. There are no template VMs parked on your nodes and no full-clone storms: what lands is a plain VM, on the storage you chose, with cloud-init applied. Archives are labeled with the upstream image name, can be purged with one command, and image builds are excluded from orphan detection.

Cloud-init works two ways: the default NoCloud seed ISO (full feature set, including multi-user and multi-IP layouts), or PVE's native cloud-init as a per-group opt-in for simple single-user, single-IP instances where a config drive is unnecessary.

Existing VMs on the cluster are not stranded either: the orphan importer can adopt any VM the panel did not create - including raw, ZFS, LVM, and Ceph-backed disks - and attach it to a user as a managed instance.

Storage​

All common PVE storage backends are supported and detected with their real capabilities: directory, NFS, LVM, LVM-thin, ZFS, and Ceph RBD, including onboarding an external Ceph cluster directly from the panel. Extra volumes allocate through the PVE storage API with the correct format per backend, hot-plug with IO limits, and resize live (grow-only, as QEMU requires). Capability gates are honest: operations a given backend cannot do, such as snapshots on plain LVM, are refused with a clear message instead of failing halfway.

Networking, VPCs, and security groups​

VPCs on a Proxmox group are built on PVE SDN: an EVPN controller and zone per VPC with a dedicated VRF VNI, a vnet and subnet per VPC subnet, and a NAT gateway with SNAT semantics that hold cluster-wide. VPC NICs hot attach and detach on running VMs. A reconciler keeps the SDN objects healthy and converges NAT gateway activation, and VPC create and destroy push eagerly so the fabric follows the panel immediately.

Security groups compile to the PVE firewall: cluster-level groups and IP sets, per-VM rulesets with both accept and drop actions, anti-spoofing IP filters, and firewall flags only on the NICs they belong to. Reconciliation is fingerprint-based, so unchanged nodes are skipped, and a cron backstop repairs drift. The datacenter firewall is enabled safely, preserving management access rather than default-dropping the hosts.

The instance network tab also gains guest IP discovery on Proxmox: addresses are read live from the QEMU guest agent, filtered of loopback and link-local noise, for both admins and users.

Consoles and WebSSH​

Three console paths ship for Proxmox instances:

• VNC (noVNC) through a PVE login ticket with single-use, server-side session tokens. PVE credentials and tickets never reach the browser.
• Serial terminal (xterm.js over termproxy), tenant-scoped.
• WebSSH - a real SSH shell in the browser. Public-IP guests are dialed directly. VPC-only guests are reached through proxmox-ssh-proxy, a small node-side service that enters the VPC's VRF on the host, because the guest's route only exists there.

The proxy is the one place host access is needed, and it bootstraps with one command on one node: the panel mints a short-lived, single-use install command, the script fetches the binary from your panel (never a third-party artifact), installs the service, opens the master's port in the PVE firewall using the egress address the node itself observed, and the panel keeps every node's proxy current automatically from then on. Install state is verified against what is actually on the node, so a half-finished install shows up as fixable instead of hiding.

Backups, scheduled jobs, and file restore​

Per-instance backups run through vzdump with completion tracked to the panel's backup queue, restore (optionally live-restore, so the VM boots while data streams back), redirect-to-storage on restore, and delete. Cluster-level scheduled backup jobs are managed from the panel with the full keep-last, keep-hourly, keep-daily, keep-weekly, keep-monthly, and keep-yearly retention set, targeting specific VMs, a resource pool, or the whole cluster. With Proxmox Backup Server storage, file-level restore lets admins and users browse a backup's filesystem and download individual files without restoring the VM.

Snapshots and Forge​

VM snapshots are first-class on capable storage: create with or without RAM state, list, rollback, and delete, from both admin and user instance pages. Forge (the checkpoint-try-rollback workflow) rides the same mechanism with a reserved snapshot slot, protected from name collisions with user snapshots.

Live migration​

Admins can live-migrate a Proxmox instance between cluster nodes with a precheck that refuses ineligible targets and local hardware blockers, handles local disks, and passes through target storage, bandwidth limit, migration network, and online mode. On PVE 9, conntrack-state migration is available as an opt-in. Migration success updates the instance's node assignment and flushes routing caches; a failed migration leaves the instance exactly where it was.

High availability​

Proxmox groups delegate HA to the PVE cluster resource manager - the layer that actually owns fencing and recovery - instead of duplicating it. Instances enroll on deploy and unenroll on destroy, groups expose HA tuning (and node-affinity placement, using HA groups on PVE 8 and node-affinity rules on PVE 9), and a reconciler mirrors CRM state back into the panel so the instance page shows the real HA state. The KVM HA watchdog is untouched, and a Proxmox-side failure can never stall KVM monitoring.

Guest services: Docker, databases, load balancers, Kubernetes​

Everything that previously required the slave agent's SSH path now runs over the QEMU guest agent on Proxmox instances:

• Docker: deploy, control, status, and logs.
• Managed databases: the full suite - configure, restart, password reset, backup tooling, full and incremental backups to S3, point-in-time recovery, restore, upgrade, replication, and batched health checks.
• Load balancers: configuration, Let's Encrypt issue and renew, and telemetry setup.
• Kubernetes: kubectl execution, control-plane certificate upload and renewal, and admin kubeconfig reissue, routed through the Proxmox adapter for Proxmox-hosted clusters.
• Instance basics: SSH key inject and remove with port detection, password resets, and WireGuard configuration sync.

Large payloads are delivered safely: small files write through the agent directly, larger ones are pulled by the guest from a single-use, checksum-verified URL.

Metering, billing, and scale​

Metrics and statistics feed the same billing pipeline as KVM, with the units and counters aligned so plan enforcement and charts behave identically. Two things are worth calling out:

• Exact per-NIC bandwidth. The PVE API only exposes aggregate VM counters, which cannot split public from VPC traffic. v3.1.0 reads per-NIC tap counters from the host instead, so VPC traffic and public traffic are metered separately and never double-billed, with reset-safe accumulation that keeps mid-day reboots billable.
• Parallel collection. Metrics, instance statistics, HA reconciliation, and security-group reconciliation fan out per node and per group onto a dedicated worker pool. Collection time scales with your largest node, not your node count.

Operational visibility​

A new Node Issues dashboard (admin, under Proxmox) surfaces operational failures on a node as structured issues: what failed, on which node, how many times, first and last seen. Issues reopen automatically if the condition recurs after being marked solved, and each issue carries a retry action. Long-running PVE tasks are tracked by UPID and can be cancelled from the panel, and a stuck panel task cancels its PVE counterpart when marked failed.

Security hardening in this release​

The Proxmox driver went through dedicated security review during the cycle. Notable fixes shipping in v3.1.0: a WireGuard configuration path that could execute as root in the guest was closed, WebSSH sessions no longer expose PVE authentication cookies, console ACLs are revoked rather than accruing, ISO URL fetching is SSRF-hardened, console routes are tenant-scoped with negative-authorization tests, and backup restore and file-restore endpoints verify the backup belongs to the instance before acting.

Version v3.0.0 is a foundation release. The platform - both the master and the hypervisor agent - now runs on Laravel 13 on PHP 8.3, and this build adds a broad round of precision and edge-case hardening across the systems that run quietly in the background. It also ships two ways to drive the platform programmatically: the Hypervisor.io OpenTofu / Terraform provider, so your instances, networks, and clusters can be managed as code, and a remote Model Context Protocol (MCP) server, so AI agents can operate the same account conversationally. Nothing changes for your existing instances, plans, balances, or configuration.

• [Feature] OpenTofu / Terraform provider - manage your account as Infrastructure as Code. The iaas provider (now released at v0.2.1, source hypervisor-io/iaas) exposes 56 resources and data sources - instances, VPCs and subnets, Kubernetes clusters, managed databases, load balancers, storage, DNS, VPN, S3, and more - over the user REST API, with full CRUD, import, and reference-driven dependencies. Authentication is your existing IP-locked API token, and both users and admins can use it. See the section below.
• [Feature] MCP server - hand your account to AI agents. A remote, stateless Streamable HTTP Model Context Protocol server exposes the platform as 364 tools (302 user + 62 curated admin) over the same REST API, with Bearer API-token pass-through auth, confirm-gated destructive operations, idempotency keys, and async convergence. Any MCP client can drive it. See the section below.
• [Platform] Laravel 13 across the stack - master and the hypervisor agent both move to Laravel 13 on PHP 8.3, on stable, security-audited dependencies. A pure runtime modernization; your data and settings are untouched.
• [Improvement] Billing precision - hourly billing is refined for long-running resources, unusual calendar edge cases, storage metering cadence, and exact fractional-credit accounting.
• [Improvement] Backup & restore robustness - incremental chains, in-place volume restore, and retention pruning were hardened for edge cases across Ceph and block backends.
• [Improvement] Migration & networking polish - cold and live migration edge cases, reverse DNS for uncommon IPv6 forms, upload/download rate-limit symmetry, and quota handling under concurrency were all tightened.
• [Improvement] Metrics accuracy - the usage pipeline that feeds billing now handles counter-reset edge cases more precisely.

Infrastructure as Code (OpenTofu / Terraform)​

v3.0.0 introduces the Hypervisor.io OpenTofu / Terraform provider - the whole platform, declared in HCL and converged with tofu apply.

You write the resources you want; the iaas provider translates them into calls against the user REST API using your existing IP-locked API token, and OpenTofu tracks the state. It covers 56 resources and data sources - instances, VPCs and subnets, security groups, Kubernetes clusters and node pools, managed databases, load balancers, storage volumes, DNS, VPN gateways, S3 buckets, projects, and the catalog data sources you reference for plans, images, and regions. Every resource supports full create / read / update / delete, tofu import <addr> <uuid> to adopt existing infrastructure, and normal Terraform references so one resource can depend on another.

Both users and admins can use it: a user manages their own resources with a user token; an operator uses an admin-scoped token for the broader surface. Because the token is validated against the IP it was registered with, run tofu from a stable egress IP (a CI runner, bastion, or workstation).

The provider is released at v0.2.1. Declare it with source hypervisor-io/iaas and let OpenTofu fetch it:

terraform {
  required_providers {
    iaas = {
      source = "hypervisor-io/iaas"
    }
  }
}

• Provider and full documentation: the repository is github.com/hypervisor-io/terraform-provider-iaas and the reference docs walk through getting started, the resource catalog, and common patterns.
• Publishing to the public OpenTofu / Terraform registry is being finalized; that hypervisor-io/iaas source is the install path once it lands, and you can build the provider from the repository in the meantime.

AI agents (Model Context Protocol server)​

v3.0.0 also ships the Hypervisor.io MCP server - the same platform, exposed to AI agents. Where the OpenTofu provider is the declarative path, the MCP server is the conversational one: point any MCP client at it and an agent can create instances, assign VPCs, and manage the rest of your infrastructure in natural language.

It is a remote, stateless Streamable HTTP server, so there is nothing to install locally - connect over HTTP and authenticate with a Bearer API token that is passed straight through to the platform, IP-locked exactly like the provider's. It exposes 364 tools - 302 user tools plus 62 curated admin tools - covering instances, VPCs and subnets, Kubernetes, managed databases, load balancers, storage, DNS, VPN, S3, and the catalog lookups agents need to reference plans, images, and regions.

Because agents act on their own, the server is built to be safe by construction:

• Confirm-gated destructive operations - deletes and other irreversible actions require an explicit confirmation step before they run.
• Idempotency keys - a retried call does not double-create, so a flaky connection cannot spawn duplicate instances.
• Async convergence - long-running operations return a task the agent can poll to completion instead of blocking.
• A curated admin allowlist - the 62 admin tools are a deliberately safe subset; billing, user deletion, and hypervisor destruction are not exposed.

The server is backed by the same tested Go client as the OpenTofu provider, so both consumers reach the API through one audited code path.

• Server and full documentation: the repository is github.com/hypervisor-io/iaas-mcp-server and the reference docs cover connecting a client, authentication, and the tool catalog.

The user / admin REST API is the single source of truth for all three surfaces - the API itself, the OpenTofu provider, and the MCP server - and a manifest-driven CI gate keeps them in lockstep, so no endpoint can ship without matching provider and MCP coverage.

Version v2.2.5 turns the platform into a place you can ship code, not just run servers. The headline is Git Push-to-Deploy: customers connect GitHub, GitLab, Bitbucket, or Gitea, point the platform at a repository, and every push is built and rolled out to their instance with zero downtime - no Dockerfile required, thanks to automatic build packs. Pull requests get their own disposable preview environments, complete with status comments posted back to the PR. Around the headline, the release adds live master updates so operators can upgrade the platform from a banner in the admin panel and watch it happen, unicast VXLAN so VPC networking works in datacenters without multicast, per-interface VPC speed controls, a new bandwidth overage billing option that charges for extra traffic instead of cutting customers off, and a platform-wide security hardening pass.

• [Feature] Git Push-to-Deploy - Deploy applications directly from a Git repository to an instance through the Docker Manager. Pick a repository and branch, choose how it builds, and the platform clones, builds, and runs it. From then on, every push to the branch deploys automatically.
• [Feature] Four Git Providers - Connect GitHub through a guided GitHub App flow with repository and branch browsing built into the panel, or connect GitLab, Bitbucket, and Gitea. Private repositories are supported through access tokens or SSH deploy keys, including custom SSH ports and users for self-hosted servers.
• [Feature] Automatic Builds with Build Packs - Applications build with Nixpacks or Railpack, which detect the language and framework and produce a container image with no Dockerfile in the repository. A plain Dockerfile and a static-site build pack are also available. Builds run inside an isolated helper container, so no build tooling is ever installed onto the instance itself.
• [Feature] Zero-Downtime Rolling Deploys - A new deployment starts the new container, waits for it to come up healthy, switches traffic over, and only then removes the old one. Traffic is routed through a managed reverse proxy with automatic HTTPS certificates.
• [Feature] Pull-Request Preview Environments - Every pull request can get its own live preview deployment on its own URL. The preview is updated on each new commit, the deployment status is posted back to the pull request as a comment, and the environment is torn down when the PR closes. A previews list in the panel shows what is running and allows manual teardown.
• [Feature] Dedicated Build Hosts - Builds can be offloaded from the application instance to a separate build host. Each user gets their own deploy keypair, and the panel includes a guided onboarding flow with a connection test before the host is used.
• [Feature] Deploy Controls and Logs - Webhook deploys are signature-verified, a deployment can be skipped by putting [skip ci] or [skip cd] in the commit message, and full build and deploy logs are available in the panel with credentials automatically redacted.
• [Feature] Live Master Updates - When a new platform version is available, an update banner appears in the admin panel. One click starts the upgrade, and a live console streams the update progress in real time until it completes. The dashboard now also carries a version pill showing the running release.
• [Feature] Unicast VXLAN for VPC Networking - Each hypervisor group can now run its VPC overlay in unicast mode instead of multicast. Unicast mode works in datacenters and on networks where multicast is not available, which removes the most common blocker to enabling VPC networking. Existing groups keep multicast by default.
• [Feature] VPC Interface Speed Controls - Operators can set default inbound and outbound speed limits for VPC network interfaces per hypervisor group, and override them per instance plan. Customers see the effective limits on their instance's network details.
• [Feature] Bandwidth Overage Billing - Instance, managed database, load balancer, and VPN gateway plans gain a Charge Overage option. When a customer exhausts the plan's bandwidth allowance, traffic keeps flowing and the extra usage is billed per gigabyte at the rate set on the plan, charged through the hourly billing cycle. The existing cut-off behavior remains available for plans that prefer it.
• [Feature] Expanded Instance Charts - Instance monitoring gains disk I/O, disk usage, and network packet and error charts alongside the existing CPU, memory, and bandwidth graphs.

Version v2.2.4 is our first stable, generally available release. After a long beta cycle that delivered VPC networking, load balancers, object storage, managed databases, and managed Kubernetes, the platform now graduates to stable. This release is headlined by Integrated Payments and Billing, a complete, built-in way to take real money from customers without bolting on an external billing system. Customers top up their account credit directly with a card or wallet, receive automated tax-compliant invoices by email, and can request refunds, all from the same panel they already use to run their infrastructure. Operators get connectable payment gateways, configurable tax rules, promotions, know-your-customer verification, and a revenue dashboard with exportable reports and a daily income summary email. The release also brings self-service plan changes with automatic proration, a major expansion of the AI Assistant so customers and operators can now create and manage resources in plain language, and a comprehensive Admin REST API for automation and integration.

• [Feature] Integrated Payments and Billing - A complete built-in billing system. Customers add funds to their account balance and that credit pays for hourly Cloud Service usage. No external billing platform required. Works alongside the existing WHMCS, Blesta, and HostBill integrations for operators who prefer them.
• [Feature] Payment Gateways - Connect Stripe, Razorpay, or PayPal and start accepting payments in minutes. Multiple gateways can run side by side, and customers pick their preferred option at checkout. Payment confirmations are verified securely before any credit is granted.
• [Feature] Automated Invoices - Every successful top-up generates a sequential, tax-compliant invoice. The invoice is emailed to the customer with a PDF attachment and is always available to view or download from the billing area.
• [Feature] Tax Rules and Tax Profiles - Operators define tax rules by region. Customers fill in a tax profile with their business and tax-identification details, with built-in validation for European VAT identification numbers so business-to-business transactions are handled correctly.
• [Feature] Refunds - Customers can request refunds against eligible transactions, and operators approve and process them from the admin billing area. Credit and revenue records stay consistent throughout.
• [Feature] Promotions - Issue promotional codes that grant bonus credit or a discount at top-up time. Codes are validated live in the top-up flow before a customer pays.
• [Feature] Know-Your-Customer Verification - Optionally require identity verification before a customer can add funds or cross a spending threshold, so operators in regulated markets can meet their compliance obligations.
• [Feature] Revenue Dashboard and Reports - A dedicated billing dashboard summarizes top-ups, consumption, taxes, and refunds. Detailed revenue and transaction reports can be exported for accounting, and a daily income digest email lands in the operator's inbox every morning.
• [Feature] Billing Module SDK - A documented module framework lets developers add new payment gateways and ship custom billing front-end panels without modifying the core application.
• [Feature] Self-Service Plan Changes - Customers can upgrade or downgrade an instance to a different plan directly from the instance settings. The instance is resized and the hourly rate is re-rated automatically, with the change prorated to the hour so the customer is only ever billed for what they used at each rate.
• [Feature] AI Assistant, Now Manages Your Whole Stack - The built-in assistant moves well beyond answering questions. Customers can now ask it, in plain language, to create and manage instances, private networks and subnets, NAT gateways, load balancers, VPN gateways, managed databases, and Kubernetes clusters and node pools, with guided step-by-step flows that confirm the details before anything is built.
• [Feature] AI Assistant for Operators - Administrators get a parallel set of assistant capabilities covering the platform itself: creating and modifying hypervisors and hypervisor groups, storage and backup configuration, service plans and plan groups, DNS providers, security groups and IP sets, object-storage servers and plans, currencies and credits, and users, roles, email templates, images, and access keys.
• [Feature] Comprehensive Admin REST API - A large, consistent administrative API now covers compute, networking, storage, backups, billing, Kubernetes, databases, DNS, users and roles, and platform settings. Build custom automation, dashboards, and integrations against the same operations the admin panel uses.
• [Improvement] Usage Report Export - The Cloud Service usage report can now be exported for offline analysis and accounting. This fulfills the export option that was previously marked as coming soon.
• [Improvement] Streamlined Admin Navigation - The admin sidebar has been reorganized so the most-used sections sit at the top, and section headings are now searchable, making it faster to jump straight to a feature on a busy install.
• [Improvement] Consolidated Billing Settings - All billing thresholds, currency display preferences, and suspension rules now live in a single settings surface, removing a long-standing source of confusion where related settings were split across two places.
• [Improvement] AI Assistant Conversation Memory - Multi-turn conversations now correctly carry context from one message to the next, so follow-up questions and step-by-step deploy flows continue smoothly instead of starting over each turn.
• [Improvement] AI Assistant Pricing Clarity - Credit balances and resource pricing shown by the assistant are now always denominated in the customer's selected currency, so estimates match what the customer sees everywhere else.