KoaVM
What's new

What's new.

Every KoaVM version, newest first. The same notes are on the panel's What's new page, which updates with one click. How to update →

1.18.0

Clusters and shared storage

For administrators

  • Incus clusters with shared storage (Ceph, iSCSI/Fibre Channel SAN with lvmcluster, TrueNAS): add each cluster server as a node and the panel works out on its own that it is a member (Nodes page: “member … · cluster …”, pool marked “shared”).
  • VPSs on the shared pool move between cluster members without copying the disk: live in a few seconds, otherwise stopped and started again in under a minute. Shared pool space is counted across the whole cluster.
  • High availability without data loss for VPSs on the cluster's Ceph: no copies, the reserve node is another member. The failure is also confirmed by the cluster (the other members mark the server OFFLINE); before restarting the VPSs the panel fences the failed server off Ceph (blocklist), and when it comes back it stops leftover processes and removes the blocklist.
  • A plan with a shared storage pool places its VPSs only on nodes that have that pool (before, where the pool was missing, they landed on the local pool).
  • Fixes: real memory reading and the nodes' SSH host key are refreshed when a node's SSH port changes.

For customers

  • If your VPS is protected and on shared storage, its page says that it restarts after a failure without losing data.
1.17.0

GPUs for VPSs

For administrators

  • GPUs for VPSs: whole GPU (passthrough), vGPU with a profile (NVIDIA vGPU, Intel GVT-g) or SR-IOV virtual functions. GPUs are never overcommitted.
  • Nodes › GPU: the cards Incus sees on the node, with model, driver, vGPU profiles, VFs and who uses them. A card goes to VPSs only once you enable it (the server video card cannot be enabled). “Check the node” checks IOMMU, vfio-pci and IOMMU groups and says what to do if something is missing.
  • Plans with a GPU: how many, which type, which model (or any enabled one) and the profile for vGPUs. The panel creates the VPS on a node with the same GPUs free; the RAM of VPSs with a GPU stays pinned and must fit in the node's real RAM.
  • VPSs with a GPU move cold to a node with the same GPU free; with high availability the reserve node's GPU is taken when the VPS restarts. Plan changes keep the same GPU.
  • Rescue mode: Windows VPSs (no agent in the rescue system) are ready as soon as SSH answers, instead of waiting 4 minutes with exit blocked.

For customers

  • If your VPS has a GPU, its page shows which one.
1.16.0

High availability for VPSs

For administrators

  • High availability: protected VPSs are copied every 10 minutes (configurable) to a reserve node and, if their node suddenly goes down, they restart there from the latest copy with the same IP. Turn it on in the plan (“High availability” option) or on a single VPS (“High availability” box on its page); ZFS nodes and VPSs on the default pool only.
  • The panel picks the reserve node: a node where the VPS's IP can follow it (the same block linked to both nodes, or a provider IP the panel moves), with room for all the VPSs that would restart together, in the same city if there is one. If no node is suitable the box says why. You can also pick it by hand.
  • A node is “down” only if neither Incus nor SSH have answered for 3 minutes, the panel can see the other nodes and at least one other node, which could see it before (baseline check every 20 minutes), confirms it can no longer reach it. By default you get an alert and the VPSs restart when you confirm (High availability page › Restart them); automatic mode is in the settings. Higher-priority VPSs restart first, while there is room.
  • Fencing: protected VPSs don't start by themselves when their node boots again (the panel starts them when needed). When a node that was down comes back, the panel stops the old copies of the VPSs restarted elsewhere, removes their network and keeps them for 7 days to recover the data of the last minutes.
  • “Switch to the reserve node” moves a protected VPS without losing data (for maintenance and to test HA); then protection is reversed towards the previous node. New High availability page with nodes, protected VPSs, old copies and events; a shield next to protected VPSs in the list; alerts for node down, restarts and late copies.

For customers

  • If your VPS is protected by high availability, its page says so and shows how many minutes of data you can lose at most: if the server fails, the VPS restarts on another server with the same IP.
1.15.0

Rescue mode and files from backups

For administrators

  • One-click rescue mode: the VPS restarts into a small Debian system with its own network (same IPs, IPv6 too), SSH root access with a temporary password and its disk attached but not mounted. “Leave” (or after 24 hours by itself) and it boots its own system as before, without running the first boot again. The first time on a node the panel prepares the rescue system disk by itself (Debian 13 from cloud.debian.org).
  • Files from backups: “Browse files” next to a backup prepares a copy of the backup on the node and mounts it read-only inside the VPS. From the panel you download files (up to 2 GB) or put them back into the VPS, in their place or next to them with a new name. It works with ZFS replicas, full backups and the chunked archive; the copy is only attached once the VPS has booted and is deleted when you close it, after 24 hours or when the VPS shuts down or restarts.
  • During rescue mode no snapshots, backups (automatic ones are skipped), moves, reinstalls or plan changes: the VPS shows “In rescue” in the list too. API v1 has GET and POST /vps/{id}/rescue and POST /vps/{id}/rescue/exit.

For customers

  • The VPS does not boot any more, you lost the password or broke fstab? “Boot into rescue mode” restarts it into a Linux system with its own network: you log in with SSH as root and the VPS disk is there, ready to mount. When you are done, “Leave” and the VPS is back as it was.
  • Deleted a file? “Browse files” next to a backup: move through the backup folders and download the file or put it back into the VPS, without restoring everything.
1.14.0

Disk and CPU limits per plan and disk charts

For administrators

  • Every plan can have brakes against the “noisy neighbour”: disk read and write in MB/s and in operations per second (both too: whichever is reached first applies), maximum CPU use (the share of each vCPU the VPS can use, even on an idle node) and CPU priority (normal, low, high). Disk limits apply to each disk of the VPS. They also apply to existing VPSs: when you save the plan they get them within seconds, even while running.
  • The custom resources of a VPS can have limits of their own; a plan change puts back those of the new plan, without a restart. Also through the API (GET /plans, POST /vps/{id}/resources).
  • The panel applies the limits on the node over SSH: every VPS of the node goes in its own group (cgroup) and the limit applies within 30 seconds, also after every start. In Settings › Nodes and overbooking you choose where: only on the nodes that need it, on all of them or never. Disk limits do not apply to disks on dir pools.
  • On the node card, “Top users” shows the VPSs that used the most CPU and disk in the last 10 minutes, with a link to the VPS, its limits and how much of them it uses: to find right away the one slowing the others down.
  • New “Disk at its limit” alert (VPS group, off by default): a VPS keeping a disk at the maximum of its limit for longer than the minutes you choose.
  • Fixed: growing the main disk of a running Linux VPS (plan change or custom resources without a restart) made the whole change fail. Now CPU, RAM and network change anyway, the disk grows right away and its size is updated as soon as the VPS is stopped.

For customers

  • The VPS page has a disk chart for the last 24 hours: reads and writes in MB/s and in operations per second, measured on the server.
  • If the plan has disk or CPU limits you see them under the charts, with the limit line in the disk chart.
1.13.0

Two-step verification

For administrators

  • Two-step verification for administrators, customers and team members: besides the password, a 6-digit code from the authenticator app on the phone (Google Authenticator, Microsoft Authenticator, Aegis, 1Password…). It is turned on from My account by scanning a QR code; it comes with 10 recovery codes to save, each working once.
  • Settings › Security: make it required for administrators and/or customers. Whoever doesn't have it can only turn it on after entering the password. The card shows how many people already have it.
  • In Clients & plans the “2FA” mark and the shield button to remove it from someone who lost their phone (also from the customer's team members, and through the API: DELETE /api/v1/clients/{id}/2fa). For an administrator: “sudo koavm user-2fa-reset --email …” on the panel server.
  • Emails when verification is turned on, turned off or removed and when someone signs in with a recovery code. API keys, billing sign-in links and sign-in with Prime Software ID don't change. The secrets key (totp.key) goes into the panel copy.

For customers

  • Two-step verification: turn it on from My account with the authenticator app on your phone. After your password the panel asks for the app code; without your phone you use one of the recovery codes.
  • On the Team & API page the “2FA” mark next to people who have it on; the owner and team administrators can remove it from someone who lost their phone.
1.12.0

More storage pools per node

For administrators

  • A node can have more than one storage pool. The panel reads by itself the pools Incus has on the node and shows them on the node card (“Storage pools”: space, assigned disk, VPSs); a new pool takes VPSs once you tick its “For VPSs” box. The pool chosen when you connect the node stays the default.
  • A VPS goes on another pool chosen at creation (“Storage pool” field, or "pool" in the API), from its plan's preferred pool, or with “Change pool” on the VPS page: Incus copies the disk with its snapshots while the VPS is off and starts it again. Assigned disk, overbooking and the real-use brake are counted per pool; a move made by hand with Incus is picked up within 30 seconds.
  • Connecting nodes: if the public address doesn't answer, the error says so (no longer the last address tried, such as the br-vps network) and the panel skips private addresses when it has a public one. “Check the server” tries port 8443 from the panel; with ufw or firewalld the setup opens 8443 only for the panel IP, plus 51888/udp, br-vps and VPS forwarding.
1.11.0

Alerts when a VPS disk fills up

For administrators

  • The panel measures the space inside running VPSs every 10 minutes with the Incus agent (df on the real file systems: ext4, XFS, Btrfs, ZFS). It is the space the OS sees: the volume on the node, with ZFS and LVM thin, also counts files that were already deleted.
  • New “Disk almost full” alert (VPS group) when the space or the inodes of a disk go over the threshold, 90% by default (Alerts › Thresholds, where measuring can also be turned off). On the VPS page you pick for that VPS the general threshold, its own threshold or “never”. The message says the free space and, if the disk is growing, when it fills up at that rate.
  • VPS page: “Disk space” card with each disk, growth in the last 24 hours, forecast, chart of the last 7 days and “Measure now”; the disk ring shows the real space inside the VPS. VPS list: “Disk” column (the fullest disk, sortable) and “Disk full” filter.

For customers

  • On the VPS page, “Disk space” card: the used and free space of each disk inside the VPS, how fast it grows and a chart of the last 7 days.
  • You can ask for an email when a disk goes over the threshold you choose (50 to 99%): it is sent once and armed again when the disk goes back below.
1.10.0

OpenStack among the migration sources

For administrators

  • Migration › Connect a source › OpenStack: Keystone v3 API with an application credential (with the admin role the VMs of all projects are visible) and, optionally, SSH access to the compute nodes. With compute nodes VMs move as from libvirt, cold or near-live, with the same MAC and the same IP if it is in a panel block; disks on Ceph are copied near-live too.
  • VMs without a connected compute node are copied through the API: Nova snapshot or Cinder volume (boot from volume and attached volumes too), downloaded from Glance checking the checksum and written on the KoaVM node. Cold copies shut the VM down in OpenStack first; near-live copies it while running. Images, snapshots and temporary volumes are removed at the end; if something goes wrong the VM is started again in OpenStack.
  • On KoaVM the VM arrives adjusted like imported VPSs: cloud-init configures the network on first boot, with the KoaVM IP (new if the OpenStack one is not in a panel block); users, passwords and keys stay as they were; UEFI or BIOS is detected from the image or the disk. With “suspend at the source panel” the VM is shut down and locked in OpenStack.
  • SSH import: the panel tracks the disk writes while copying (kernel events), so the passes after the first re-read only the written pieces and the disk stays frozen for a few seconds even if it is large or slow (before, the last pass re-read the whole disk). Without tracking everything is re-read as before; if the disk were thawed by the time limit before the end, the import stops instead of delivering an inconsistent copy.
  • Imported and OpenStack VPSs with SELinux enforcing (AlmaLinux, Rocky, RHEL): the panel agent did not start (console, password and checks from the panel did not work). It now starts as an unconfined service and SELinux stays enforcing.
  • Hostname on AlmaLinux, Rocky and RHEL VPSs: with a name without domain (e.g. “web1”) the system took the instance name (vps-1234); it now takes the chosen one.
  • Import: a pass could be reported as “not finished” even when it had gone well (the last line arrived after the command ended); an import interrupted by a panel restart left the disk export running on the node and the VPS could not be deleted; a new import from the same VPS now removes the leftovers of the interrupted one.

For customers

  • On AlmaLinux, Rocky and RHEL VPSs a hostname chosen without domain (e.g. “web1”) is now kept, instead of the instance name.
1.9.0

VPSs imported from any provider

For administrators

  • Migration › Import from another provider: a Linux VPS at Vultr, Hetzner, DigitalOcean, OVH, Contabo or any other provider can be moved to KoaVM with SSH access only. The panel logs into the VPS (with the password, used only once to put its key there, or with the panel's key), checks the system, disk, filesystem, cloud-init and databases without changing anything and estimates how long the copy will take.
  • The copy is made from inside the running VPS in three passes: the whole disk, then only the changed pieces, then a last pass with the filesystems frozen for a few seconds (consistent like a snapshot); running databases can be stopped during the last pass. The disk travels encrypted inside SSH from the VPS to the panel and from the panel to the node, which do not need to trust each other.
  • On the node the VPS starts again with a new IP: the old network configuration is set aside, cloud-init takes KoaVM's configuration, disks that were not copied are removed from fstab, and a fallback UEFI loader is added. Users, passwords, SSH keys and software stay as they were. You choose the client (also a new one), plan, node and hostname; when the copy is finished the panel's key is removed from the source VPS, which can also be shut down.
  • Until the last pass the import can be cancelled; if something goes wrong the VPS on KoaVM is removed, the IP is freed and the source VPS stays as it was. Failed imports can be retried from the same list.
  • VPSs: filters by node, plan (also “custom”), client and system, besides search and status, with how many VPSs each has; the plan is shown in a column with the resources; click the columns to sort (name, client, node, plan by size, IP, status, CPU, creation date). Filters and order stay in the page address and for the next visits.
  • If the panel is updated while a page is open, a notice with “Reload” appears and the next click loads the page with the new interface (before, the old one stayed until a reload). While the panel restarts, reads are retried for a few seconds instead of showing “NetworkError”.

For customers

  • If the panel is updated while a page is open, a notice with “Reload” appears; while it restarts, pages retry on their own instead of showing “NetworkError”.
1.8.0

Nodes as a list

For administrators

  • Nodes: at the top right you choose between the card view and a list view, like the Finder. The list has one row per node with location, threads, assigned RAM, disk and vCPUs, running VPSs, drives and RAM and status; click a column to sort, and the disclosure triangle opens the node's full card under the row. The chosen view is remembered.
1.7.1

Pages stuck on "Loading…"

For administrators

  • Pages with lists (VPSs, customers and plans, migration, nodes and the others) stayed on "Loading…" without calling the server when opened in a background browser tab or a window that wasn't visible. Now the first load always runs and the page refreshes as soon as it becomes visible again.

For customers

  • Pages with lists stayed on "Loading…" when opened in a background browser tab: now they always load.
1.7.0

Alerts for drive and RAM failures

For administrators

  • The panel checks every node every 15 minutes: SMART data of each drive (health, wear, spare, temperature, reallocated or unreadable sectors, media errors, self-test), ZFS pools and system RAID, RAM errors counted by ECC and the kernel log (disk I/O errors, processor hardware errors). If smartctl is missing it installs it by itself.
  • New alerts: drive failing or to keep an eye on (one per drive), pool or RAID with problems, disk I/O errors, uncorrected or increasing corrected RAM errors. They close by themselves when the problem goes away.
  • Nodes › Drives and RAM: status of each drive with model, serial number, wear, temperature and power-on hours, pools, RAM, latest error lines of the log and "Check now". A drive that disappears from the server stays marked as "not answering".
1.6.1

Demo on its own domain

For administrators

  • koavm demo --domain: the demo now gets ready also when it has its own name (before it stopped with «name not served by this panel»).
1.6.0

Demo panel without servers

For administrators

  • New koavm demo command: a complete trial panel with 4 nodes and 13 VPSs simulated in memory, without servers or Incus. You can create, start, stop, resize and move VPSs between nodes, take backups and snapshots, use private networks, firewalls, load balancers, routers, DNS and the console; settings, real nodes, passwords and API keys stay locked. It starts over every 3 hours. It is the demo on demo.koavm.com: see Installation › A demo panel.
1.5.2

Fast writes per node

For administrators

  • Nodes › Fast writes: confirmed writes (databases) don't wait for the disk for all VPSs on a node, including those on plans without fast writes. Useful on nodes with desktop-class drives without power-loss protection: in our tests from about 500 to about 4,000 confirmed writes per second. If the node loses power suddenly every VPS loses the last few seconds of data. It applies within seconds, without restarts.
1.5.1

VPSs on a single chip

For administrators

  • On servers with several chips in the processor (for example first-generation AMD EPYC: 4 chips of 8 threads and 32 GB) the panel keeps each VPS on a single chip, with vCPUs and RAM close together: in our tests RAM with several threads is 50% faster and without dips.
  • The panel picks the chip from the assigned RAM and the overbooking, and only for VPSs that fit, so one chip does not fill up while the others are free. It applies to new VPSs and to the others from their next start or restart from the panel; turn it off from Nodes › Overbooking › CPU chips.
1.5.0

RAM and CPU overbooking

For administrators

  • CPU overbooking per node: vCPUs sold for each server thread, from 1× to 16× (4× by default, also on existing nodes). A VPS cannot have more vCPUs than the server has threads. The node card shows vCPUs sold, for sale and CPU really in use.
  • RAM overbooking up to 2×. VPSs give the node back the RAM they free (free page reporting): in our tests a VPS that had used and freed 3 GB went from 3.9 to 0.7 GB on the node. It applies to new VPSs and to the others from their next start or restart from the panel.
  • RAM really in use fixed: Incus counted VM memory as cache and reported far less than the truth (20% instead of 89% on a test node). The panel now reads it from the node every minute; the real-usage brake, the alerts and the live map use the right number. The brake counts the CPU too.
  • Compressed RAM before the disk (zswap): with swap on, pages first stay compressed in RAM, 2–3 times smaller, and reach the disk only afterwards. On existing nodes just press Overbooking › Apply swap.
1.4.0

Faster disks

For administrators

  • Plans › Fast writes: writes that programs confirm (databases) don't wait for the disk, 8–9 times faster in our tests. If the node loses power suddenly the VPS loses the last few seconds of data: off by default, suited to development or budget plans. Only on ZFS nodes.
  • New Linux VPSs created from the catalog use the virtio-blk disk (vda in the system): up to 18% more on database writes and 10% on random reads. Existing VPSs, Windows and your own templates stay as they are.
  • ZFS cache capped on every node: 10% of RAM, between 2 and 16 GB. Before, it could take almost all the server's RAM and take it away from VPSs under load.
1.3.0

New nodes in a few clicks

For administrators

  • Add node › Server in your account: a dedicated server in the connected OVHcloud, Hetzner Robot or Scaleway Dedibox account is reinstalled by the panel with Debian 13, the panel key and the right partitions, then prepared and connected by itself. To confirm you type the server name.
  • When a node connects, the panel creates the NAT network block by itself (addresses .10 to .250) and, if the server has a public IPv6, the IPv6 block for its /64: you can create VPSs right away.
  • OVHcloud servers and cloud images: if root answers «Please login as the user debian», the panel logs in with that user and works with sudo, with nothing to fix by hand.
1.2.1

Sturdier node setup

For administrators

  • New nodes: setup no longer stops at the «disks and ZFS pool» step when the panel's swap is a file (it happened on servers with the /var/lib/koavm-data partition, such as OVHcloud servers installed with the recommended partitions).
  • If setup stops after emptying the data partition, «Retry» finds it again and creates the ZFS pool there.
  • Automatic node swap: at most half of the free space, always leaving at least 10 GB free on the system disk.
1.2.0

30-day free trial

For administrators

  • The free trial lasts 30 days from installation, still with 1 node, 5 VPSs and every feature. Once it has ended, the panel creates no new nodes or VPSs until you add a license; existing VPSs keep running and are managed as before. Panels installed earlier count from their installation.
  • The License page and the Overview show how many days are left; one week before the end you get an alert and a strip at the top of the pages, then an alert when the trial has ended.
  • First steps: the license is no longer an optional step.
1.1.0

First steps and support report

For administrators

  • First steps on the Overview: brand, first node, IPs, first VPS, emails, backup destination, panel copy and alerts. Each step ticks itself when done and leads to the right page; the card disappears once you are finished or with «Hide».
  • Support report: Settings › Support downloads a text file with version, system, license, nodes, failed jobs, open alerts, settings and the last lines of the log, without passwords, keys or tokens. If the panel doesn't open: «sudo koavm support-report» on the server.
  • English: «license» is always spelled the same way.
1.0.0

First stable version

For administrators

  • KoaVM 1.0: first stable version. Without a key it runs as a trial with 1 node and 5 VPSs and every feature; with the license you pay per node. From here on, the v1 API, the WHMCS and KoaBilling modules and the koavm commands stay compatible across all 1.x versions.
  • Final round of tests: a new VPS through creation, power on and off, password, snapshots, backup and restore, firewall, extra disks, private networks, live move between nodes, reinstall, managed DNS, API keys, traffic and deletion; every admin, customer and demo page in Italian and English, on desktop and phone; clean install from koavm.com on Debian and Ubuntu.
  • Phone: the Nodes, Settings and DNS zone pages no longer scroll sideways.
  • Code checks (staticcheck, race detector, govulncheck, npm audit) and removal of functions no longer used.

For customers

  • KoaVM 1.0: first stable version of the panel.
0.18.0

Traffic measured on the node, panel copy

For administrators

  • VPS traffic is measured on the node, card by card (tap and macvtap), no longer by the agent inside the VM: whoever uses the VPS can't fake it, and Docker, VPNs and internal bridges are no longer counted twice; a new card (VPS restarted, card re-added, move) counts from zero.
  • Traffic is no longer lost when the panel restarts or updates (the last counters are saved and picked up again), and the first half minute after a VPS starts now counts too.
  • Panel copy (Backups › Panel copy): every night the database, node certificate, SSH key and HTTPS certificates go to a backup destination, encrypted with age for a recovery key the panel doesn't keep; alert if it fails; restore on a new server with "koavm panel-restore".
  • Migration: Cancel button for queued migrations (the prepared VPS goes away and the IP is free again) and while copying (everything goes back to how it was on the source node), up to the switchover; email to the customer if they had been notified.

For customers

  • Traffic measured on the server, on the VPS network cards: traffic between programs on the same VPS (for example between Docker containers) no longer counts.
0.17.1

Security review

For administrators

  • Security review before 1.0 (code review by area, dependencies, exposed surface, demo account): every finding fixed.
  • The panel only answers the --domain names; the panel address (invite links, DNS nodes) is only written by a real administrator and doesn't change when the panel is opened by another of its names.
  • Commands run in VPSs through the agent are read from websockets with an output cap: a VM can no longer fill the node's disk with endless output.
  • Backup and snapshot restore: raw and security keys and devices the panel doesn't use are removed from the configuration (a backup changed on the destination no longer gives access to the node).
  • Updates: no installation of older versions from the panel's request, database copy made as the panel user and a restricted koavm-update service (run install.sh again to get it).
  • Sign-in: attempt limits also per email and per IPv6 /64, a limited number of password checks at once, no sign-in or sign-out started from another site; console, VNC and SPICE check the origin before opening the session; limits on VNC messages, open graphical consoles and screenshots.
  • Customers get errors and job messages without node addresses, URLs and paths; new bytes of incremental backups are shown to administrators only.
  • Demo account: no screenshots, application scripts, URLs with keys (webhooks, orders) or writes caused by a read.
  • Migration: the VM disk is mounted without suid, devices and executables and written only inside the disk; the disk format is the one from the source hypervisor.
  • Private networks, firewall and disks: WireGuard keys checked, firewall ports always in decimal, duplicate addresses removed; qcow2 images with external data files rejected; webhooks and images from URL can't reach the server's local addresses; Go 1.26.9 and golang.org/x/net updated.

For customers

  • Security: errors without server details, console opened only from the panel, abuse limits.
0.17.0

Licenses and one-command installation

For administrators

  • Per-node license: KVM-… keys on the new License page, checked with the koavm.com license server, which answers with an ed25519 signature, at startup and every 12 hours. Several keys add up (nodes and provider VPSs); a key works on one panel at a time and is removed to use it on another one.
  • Free trial without a license: 1 node and 5 VPSs with every feature, migration included. Beyond the limits the panel doesn't add nodes (also those set up or ordered by the panel) or VPSs (also migrated or self-service ones): existing VPSs keep running.
  • Grace period: if the license server doesn't answer the panel keeps working for 14 days and alerts after 3. With a suspended, cancelled, expired or too small license the trial limits apply to new things; customer VPSs are never shut down because of the license.
  • License box in the Overview, a strip at the top of the pages when the license has a problem, and the alerts «license server unreachable», «license not active», «more nodes than the license covers».
  • One-command installation: curl -fsSL https://koavm.com/install.sh | sudo bash -s -- --domain … --email … downloads the latest version checking its signature and SHA-256, creates the services and the first administrator and prints the address and the password (Debian 12/13, Ubuntu 22.04/24.04).
  • For KoaVM resellers: a license API for billing (issue, suspend, cancel, monthly statement with the tier discount) and the «KoaVM licenses» module for KoaBilling.
0.16.0

Managed DNS

For administrators

  • Managed DNS: customers put their domains on the panel's nameservers and manage their A, AAAA, CNAME, MX, TXT, SRV, CAA and NS records (with * and names like _dmarc too), with import and export of zone files in BIND format.
  • The zones are served by the nodes chosen in DNS › DNS servers: the panel installs its authoritative DNS server there (koavm-dns service, unprivileged) and keeps it up to date; changes arrive in a few seconds and the nodes keep answering even if the panel is off. Every address is checked every minute, with a response limit against amplification.
  • Reverse DNS of your IP blocks served by the panel (Network and IPs › Reverse DNS): PTRs are chosen on the VPS page, by the customer too.
  • Delegation check of every domain with a public resolver; settings for the nameservers, the SOA email and domains per customer; /dns/zones API for the panel and billing.
  • Demo account: the private address of routers and load balancers is no longer hidden.

For customers

  • DNS (if enabled): your domains on our nameservers, with records you change yourself in a few seconds, and zone import from your old provider.
0.15.1

Read-only demo account

For administrators

  • Demo account to show the panel to partners and providers: it signs in like an administrator and sees every page, but every change is refused, VPS consoles are closed and keys and passwords are hidden from responses. A «Demo account» note appears at the top of the pages. It is created on the server: an administrator with demo = 1 in the users table.
  • The panel can answer on more than one name with the automatic certificate: --domain with the names separated by commas (e.g. «demo.koavm.com,vm.example.com»).
0.15.0

Routers and VPSs without public IPv4

For administrators

  • VPSs without a public IPv4: only the customer's private network (and IPv6, if the plan includes it), with no addresses from the blocks. "Without public IPv4" option in Create VPS, in self-service and in the API (no_ipv4).
  • Routers: a small VPS of the customer running nftables that the panel creates and configures by itself. It becomes the gateway of the private network: VPSs without public IPv4 reach the internet through its IP (NAT) and receive the forwarded TCP and UDP ports, with the real IP of whoever connects.
  • VPSs without public IPv4 go, if there's room, on the same node as the router; when the router is created or deleted the panel brings the gateway into the running VPSs.
  • Settings › Routers: machine plan (by default the load balancers' one), routers created by customers (off by default) and how many per customer. Routers page for you and for customers; in the hourly usage the machine counts as "router"; /routers API.

For customers

  • Routers (if your service includes them) and VPSs without public IPv4: VPSs only on your private network that reach the internet through the router, with the ports you choose forwarded from the router's IP.
0.14.0

Managed load balancers

For administrators

  • Load balancers: a public IP that splits traffic between a customer's VPSs, with health checks (TCP or HTTP page), HTTP, HTTPS and TCP, same VPS per visitor, PROXY protocol and a choice of algorithm. It is a small VPS of the customer running HAProxy that the panel creates, configures and monitors by itself.
  • The load balancer sits on the customer's private network and reaches the VPSs on their private IP, also in other datacenters; the others on their public IP.
  • Let's Encrypt HTTPS certificates requested and renewed by themselves once the domains point to the load balancer (with a temporary certificate meanwhile), or the customer's own certificate.
  • Settings › Load balancers: machine plan, load balancers created by customers (off by default) and how many per customer. Load balancers page for you and for customers; in the hourly usage the machine counts as "lb"; /load-balancers API for billing and for customer keys.

For customers

  • Load balancers (if your service includes them): one address that splits traffic between your VPSs and leaves out those that don't answer, with the Let's Encrypt HTTPS certificate for your domains.
0.13.0

Teams and API access for customers

For administrators

  • Customer teams: every customer invites other people into their account, each with their own email, password and a role (administrator, technician, read-only). They work on the customer's VPSs with the role's permissions; the server checks every action.
  • API keys for customers, with a role, on the panel API (/api/…) with the same permissions as the interface. They don't work on /api/v1, and the keys of Settings › API don't work on the panel API.
  • Account activity log: sign-ins and operations with who did them (the customer, a team member or a key). In Clients & plans the badge button shows a customer's team, keys and log and lets you remove people and keys.
  • Each email joins one account only: new customers can't use the email of a team member.
  • Billing: if the additional disk sold with the service (disk1) was detached, a plan change with extradiskgb no longer creates a new one.

For customers

  • Team & API (new page): invite the people who work with you on your servers, each with their own password and a role: administrator, technician or read-only.
  • API keys for your scripts: they do what a person with the same role does, on the panel API.
  • Activity log: who did what in your account.
0.12.0

Self-service: customers create their own VPSs

For administrators

  • Self-service (off by default: if you only sell predefined VPSs nothing changes). Turn it on in Settings › Self-service; on plans choose which are “offered in self-service”; in Clients & plans give a customer a package (VPSs, vCPUs, RAM, disk, allowed plans and nodes). The customer creates, resizes and deletes the package VPSs themselves; VPSs sold separately don't count and the customer cannot change them.
  • Suspended package: its VPSs shut down (reason “billing”) and no new ones can be created. Removing the package keeps the VPSs as normal VPSs, or deletes them.
  • Hourly usage: every hour the panel counts hours, vCPU, RAM, disk and IPv4 for every VPS and detached volume, per month (24 months). API GET /usage for billing; the package shows the month's usage.
  • SSH keys saved in the account (My account › SSH keys), to pick when creating or reinstalling a VPS; first-boot script (Linux, 64 KB) when creating, also from the API (sshkeyids, user_script).
  • API: GET/PUT/DELETE /clients/{id}/quota and GET /usage. WHMCS module 1.5.0: “pacchetto” product type (creates customer and package, suspends, changes limits, deletes) and package usage metrics for WHMCS Usage Billing.
  • Fixed: the resellers' RAM limit is now counted in MB (it was rounded to GB); suspension no longer fails when the VPS already shut down on its own.

For customers

  • If your service includes a self-service package, in Services you create your own VPSs (plan, city, system, application, SSH keys, first-boot script) and on the VPS page you change its plan or delete it.
  • My account › SSH keys: save your keys and pick them with one click when you create or reinstall a VPS.
0.11.0

VPS firewall, volumes and floating IPs

For administrators

  • Per-VPS firewall: inbound rules (TCP, UDP, ping, ports and ranges, IPv4 or IPv6 source), with replies and outbound traffic always allowed. The node applies it with nftables, by address and by MAC, including between VPSs on the same node and across nodes. When first turned on it suggests SSH or remote desktop, ping and the application ports. Clients can use it too.
  • Volumes: any extra disk can be detached from one VPS and attached to another VPS of the same client on the same node, data intact and mounted automatically. New Volumes page, per-volume snapshots (up to 5) even while detached, deletion by the administrator only.
  • Floating IPs: an extra IP moves from one VPS to another of the same client in a few seconds, without reboots; if the target VPS does not accept it, it goes back. The firewall follows the IP.
  • API: /vps/{id}/firewall, /vps/{id}/disks/{disk}/detach, /volumes (list, attach, snapshots) and /vps/{id}/ips/{ip}/move.
  • Fixed: removing a network card or a disk from a VPS now waits for the node to finish, so an operation right after it (another IP, deleting the disk) no longer finds the old card.
  • The firewall uses nftables on the node and panel SSH access to the node: new node setup installs nftables, Debian and Ubuntu usually have it already (otherwise “apt install nftables”).

For customers

  • VPS firewall: choose which ports to open and to whom, from the VPS page. The console always works.
  • Volumes: detach an extra disk and attach it to another VPS of yours in the same datacenter, data intact; snapshots for each volume.
  • Extra IPs move to another VPS of yours in a few seconds.
0.10.3

KoaVM instead of Incus in the panel texts

For administrators

  • Systems: the “Incus catalogue” tab is now “KoaVM catalogue” (the official cloud images of the distributions, taken from the Incus catalogue).
  • Sign-in, Overview and Nodes talk about your KoaVM nodes: “VPS panel · your nodes and cloud providers”, “KoaVM nodes”. Incus is only mentioned as the node technology (setup, token, version).
0.10.2

Guide updated

For administrators

  • Guide updated for 0.10: introduction (systems, apps, overbooking), creating a VPS and the VPS page (systems per plan, app, ISO, graphical console, Windows), plans, API (GET /apps, app and app_options, app status), moving between nodes, capacity and resellers with node overbooking.
0.10.1

Per-node RAM and disk overbooking, node swap

For administrators

  • Per-node overbooking: RAM from 1× to 1.5× and disk from 1× to 3×, chosen when you add the node (existing server, order, token) and editable from Nodes › Overbooking. They apply to new VPSs, moves, migrations, plan changes and automatic node purchasing. Defaults in Settings › Nodes and overbooking.
  • Real-usage brake (85% by default): when the RAM or disk actually in use on a node reaches the threshold, the node gets nothing more, even if overbooking would allow it.
  • Node swap (“RAM can use the disk when needed”): automatic (half of the RAM, 2–32 GB), a chosen size or off. Chosen when the node is set up and changeable later over SSH, without a reboot.
  • Nodes: RAM and disk assigned against the capacity with overbooking, next to real usage and the server swap.
0.10.0

Systems and templates: full catalogue, Windows Server, your own templates, ISOs and preinstalled apps

For administrators

  • New Systems page: the offered systems with icon, requirements (minimum RAM and disk) and the plans that can use them; when creating or reinstalling, systems that do not fit the plan stay disabled with the reason.
  • KoaVM catalogue: every official cloud image for VMs with cloud-init (from images.linuxcontainers.org) (Debian, Ubuntu, AlmaLinux, Rocky, CentOS Stream, Fedora, openSUSE, Arch, Alpine, openEuler), added with one click. Really tested Fedora 44, Alpine 3.24, Arch, openSUSE Leap 16, CentOS Stream 10 and Debian 13: network cards are called eth0 on every system, DNS arrives even without resolvconf and sshd_config.d works everywhere.
  • Your own templates: from a VPS (snapshot, the VPS stays on) or from a qcow2/raw file, also compressed (xz, gzip, bzip2, zstd; raw becomes qcow2 without qemu-img). Templates live on the nodes and the panel copies them where needed: first directly between nodes with a one-time secret, otherwise through the panel.
  • Windows Server from ISO: the panel installs Windows by itself (autounattend, virtio drivers, cloudbase-init, remote desktop, sysprep) and turns it into a template in 20–40 minutes, with the VM screen visible from the panel. Windows VPSs get the Administrator password, static network (IPv6 too), name and grown disk on first boot; the clear-text password leaves the configuration after one hour.
  • ISO library: ISOs downloaded by the panel straight into the nodes' Incus volumes, mountable on VPSs with boot from CD; public ones can be mounted by clients too.
  • Graphical console (SPICE in the browser, through the panel) for Windows and ISO installs, next to the serial one.
  • Apps on first boot: Docker, WordPress (nginx, PHP-FPM, MariaDB), free HestiaCP and CyberPanel; cPanel, Plesk and DirectAdmin ready but off by default. Status, access details and install log on the VPS page; your own apps with a bash script.
  • API v1: GET /apps, app and app_options when creating, app status; WHMCS module 1.4.0 has the “Application” option and saves Administrator as the user for Windows.
  • Migration: VMs move to KoaVM. The page, the pre-flight checks, the job messages and the guide no longer show Incus as the destination (Incus is only mentioned as the technology the nodes run); they talk about source nodes, because sources also include Proxmox VE, Virtualizor and libvirt.
  • Network: when the node bridge has an MTU below 1500 (for example because it is extended with VXLAN to another node), new and reinstalled VPSs get it on eth0, Windows included. Before, some sites that ignore path MTU discovery (mariadb.org, for example) did not answer from the VPSs.
  • ISO library: an ISO's address can be changed later too (used by the nodes that do not have it yet).

For customers

  • System choice with icons, Windows included (remote desktop as Administrator).
  • Optional preinstalled app (WordPress, Docker, hosting panels): status and access details on the VPS page.
  • Graphical console and mountable ISOs (rescue discs, manual installs).
0.9.0

Automatic new nodes: setup, provider orders, automatic purchasing

For administrators

  • A server you already have: give the IP and password (or the panel key) and the panel sets up the node on its own. It installs ZFS and Incus 7.0 LTS, creates the ZFS pool on an empty disk, on free space or on the data partition, creates the br-vps network and connects the node with the certificate and the private network tunnels. Before starting it checks system, CPU, RAM, disks and Secure Boot.
  • Order a server: catalog of OVHcloud (Kimsufi, So you Start, Rise, Advance), Hetzner (price list and auctions) and Scaleway Dedibox, with price, setup fee, datacenters and delivery times. The panel asks the provider for the exact price, which you confirm. Then the panel waits for delivery, installs Debian (provider API or rescue system with installimage), sets up the node and links it to the account.
  • Nodes being set up: progress, a log of every step, "Retry" from the step that stopped, and cancellation. The server password is deleted as soon as the panel key is in.
  • Capacity and automatic purchasing: free RAM and disk per city and rules that propose a new node (and wait for your OK) or order it on their own, within a monthly cap and a maximum number of nodes per month. New alerts: running out of space, server ordered, node ready, setup stopped.
  • Retire node: an empty node leaves the panel (certificate removed, tunnels updated) and, if linked to a provider, the server is cancelled at the end of the period.
0.8.0

Private networks across datacenters, moves between nodes, alerts, resellers

For administrators

  • Private networks: one or more networks per customer, isolated, on every node even in different datacenters. Between nodes the panel sets up encrypted WireGuard tunnels on its own (UDP 51888); VPSs get a private interface (MTU 1370) configured inside the VPS too. Private networks page with the tunnel status.
  • Moving VPSs between nodes: live (the VPS stays on) when possible, otherwise cold with a preliminary copy while the VPS runs and a few seconds of downtime. Checks before starting, additional disks and snapshots included, addresses that stay or, if needed, new ones with the network updated inside the VPS.
  • Drain node: all the node's VPSs to other nodes (first those in the same city), one move at a time. Rebalancing: suggestions to even out RAM and disk between nodes, to apply one by one or all together.
  • Alerts: unreachable node, node disk or RAM almost full, failed backups, VPSs in error, failed moves, tunnels not ready and updates. By email, webhook, Slack, Discord and Telegram, with language and groups per channel and adjustable thresholds.
  • Resellers: customers with limits (VPSs, vCPUs, RAM, disk, additional IPs, allowed plans and nodes), with their own customers and their own API key for their WHMCS. External references apply per WHMCS.
  • Sign-in with Prime Software ID: “Sign in as admin” from the Casa page, only for the chosen administrator and with two-step verification.
  • WHMCS module 1.3.0: “Private network” option (Yes/No) and private addresses and additional IPs in the client area.
  • On the What's new page a preview build reads “preview build” and gets the published version as an update from the panel; settings also save with numeric fields.

For customers

  • Private networks: a network of your own between your VPSs, even in different datacenters, encrypted between servers.
  • If you are a reseller: Reseller page with your customers, new VPSs, limits and API keys for your WHMCS.
0.7.3

Routed IP blocks (Kimsufi) and extra IPs per VPS

For administrators

  • IPv4 blocks routed to the node's server, without virtual MACs (for example OVH blocks on Kimsufi servers): Network & IPs › New block › Routed to the server. VPSs use the routed interface with gateway 169.254.0.1 and every address of the block can be used.
  • OVH IPs imported from the account on a server that doesn't accept virtual MACs are used routed, without trying to create a virtual MAC.
  • Extra IPs per VPS from routed blocks: added and removed live from the VPS page, and the panel configures them inside the VPS (NetworkManager or systemd-networkd). They survive snapshots, backups and reinstalls.
  • API: “extra_ips” at creation, PUT /vps/{id}/ips for the wanted number, POST and DELETE to add and remove. WHMCS module 1.2.0 with the “Additional IPs” configurable option.
  • IPs added by hand on Incus: “Add IPs › Added by hand” brings them into the panel without touching the VPS; restores and plan changes no longer remove the interfaces the panel knows.
  • Updates: the result shows only version numbers.

For customers

  • If you have extra IPs you see them in the VPS Network box, already configured.
0.7.2

Incremental backups, extra disks and updates from the panel

For administrators

  • Incremental backups: the first one copies everything, later ones only what changed, compressed and encrypted (AES-256). They work on S3, FTP and on another node; the archive key is shown in Settings › Backups.
  • ZFS replication between nodes: when both the VPS and the backup node use ZFS, a backup sends only the changed blocks (a few seconds for a daily backup).
  • New FTP/FTPS destination (for example the backup space that comes with dedicated servers), with self-signed certificates accepted by fingerprint.
  • A «Backups» page in the menu: coverage of every VPS, next backups, errors, all backups and actions.
  • Extra schedules for one VPS or for all VPSs on a node: every few hours, daily or weekly, with their own number of copies and destination.
  • Backups never go to the VPS's own server; new plans start with 3 nightly backups.
  • Custom resources for a single VPS: vCPU, RAM, disk, speed and traffic without changing its plan (also from the API and WHMCS).
  • Extra disks: added even while the VPS is running, formatted and mounted by the panel (e.g. /mnt/disco1), grown and removed; included in snapshots and backups.
  • Snapshots and backups ask the VPS to flush its data to disk before they start.
  • A «What's new» page with every version and one-click updates from the panel: the database is copied first and the previous version comes back on its own if the new one doesn't start. From the command line: «koavm update» and «koavm update --rollback».
  • Guide for administrators and customers, in Italian and English, inside the panel and on koavm.com/docs.

For customers

  • Faster backups: after the first one only the changed parts are saved.
  • If your VPS has extra disks you see them on its page; they are included in snapshots and backups.
  • The customer area has the Guide (how to use the VPS, snapshots, backups, network) and What's new.
0.7.1

Scaleway: Dedibox servers and Instances VPSs

For administrators

  • New provider Scaleway: all it needs is the API key and the project ID.
  • Dedibox servers become nodes: failover IPs come in on their own, the panel moves them to the right server, creates the virtual MAC, sets reverse DNS and buys new ones within the spending cap.
  • Resell VPSs with Scaleway Instances (Paris, Amsterdam, Warsaw): IPv4 and IPv6 that never change, disk as large as the plan's, reinstall, plan change, reverse DNS.
0.7.0

Selling

For administrators

  • Public API with keys (Settings › API) and a WHMCS module you can download from the panel; also works with KoaBilling.
  • Snapshots and backups: to another node or to S3 storage, manual or automatic every night, with safe restore.
  • Plan change, network speed per plan and monthly traffic with the rule chosen in the plan (slow down, suspend or notify).
  • Suspension with a reason (administrator, billing, traffic, abuse).
  • IPv6: one address per VPS from the node's blocks, also for existing VPSs.
  • Reverse DNS from the panel for the IPs of connected providers.

For customers

  • Snapshots and backups from the VPS page.
  • IPv6 address and reverse DNS (when the IP's provider allows it).
  • One-click sign-in to the panel from the WHMCS client area.
0.6.0

Provider VPSs and new look

For administrators

  • Resell Hetzner Cloud and Contabo VPSs under your brand: zones, a product for each plan, costs, sync.
  • Contabo additional IPs managed through the API.
  • New look: dark theme, collapsible side menu, animated sign-in page, animations.

For customers

  • New look, also on phones.
  • Graphical console for VPSs on Hetzner Cloud.
0.5.0

OVHcloud and Hetzner IPs via API

For administrators

  • OVHcloud (dedicated and Public Cloud) and Hetzner (Robot and Cloud) accounts: servers and IPs read from the account, nodes linked automatically.
  • When a VPS is created the panel moves the IP to the node's server and creates the virtual MAC when needed.
  • Buy IPs by hand with a quote or automatically, never above the monthly spending cap.
0.4.0

Migration from every panel

For administrators

  • Migration from SolusVM 1 and 2, Virtualizor, Proxmox VE and KVM/libvirt, with all the VM's disks.
  • Incus pools on ZFS, LVM, dir and btrfs.
  • Batch migrations scheduled at a set time, at most N at once.
  • Emails to customers before and after the move (Prime Mail, SMTP or log only).
  • Easier sign-in from phones.

For customers

  • Notice emails before and after the VPS moves.
0.3.0

English and migration from SolusVM

For administrators

  • Interface in Italian and English.
  • Migration from SolusVM and KVM/libvirt, cold or near-live (about 10 seconds of downtime), keeping the same IP and MAC.
  • Checks before moving and automatic fallback to the source VM if something goes wrong.

For customers

  • Customer area also in English.
0.2.0

New name: KoaVM

For administrators

  • The product is now called KoaVM.
  • Live map: nodes and VPSs on the globe, refreshed every 10 seconds.
0.1.0

The panel core

For administrators

  • Incus nodes connected through the API, no agents to install.
  • IP blocks, plans, operating systems and customers.
  • VPSs: creation with static network, root password and SSH key; start, shut down, restart, reinstall, delete.
  • Job queue, CPU, RAM, disk and traffic charts, console in the browser.

For customers

  • Customer area with their own VPSs: start, shut down, restart, console, new password, reinstall, charts.