Introduction
VorticPanel is a self-hosted control panel for selling and running KVM virtual servers. It has three parts:
- The controller: one Node.js process. It serves the panel and its API, keeps everything in one SQLite file, sends email, pushes DNS to PowerDNS, and talks to the nodes.
- The panel: the web interface for customers, resellers and staff. The controller serves it.
- The node agent: one Node.js file on each KVM host. It connects out to the controller, drives libvirt, QEMU and nftables, and reports telemetry.
browsers ──https──▶ reverse proxy ──▶ controller (127.0.0.1:8080) ◀──wss── node agents
(TLS, WebSockets) SQLite in /var/lib/panel (libvirt, KVM)Nodes only ever connect out to the controller on 443, so hypervisors need no open ports from the internet. Moving servers between nodes uses SSH between the nodes, on a management network you choose.
Who uses it
| Who | What they get |
|---|---|
| Customers | Their servers: power, console, reinstall, snapshots, backups, firewall, reverse DNS, DNS hosting, private networks, floating IPs, team access and API tokens. |
| Resellers | Everything a customer has, plus their own customers, quotas, branding, webhooks and a billing API. |
| Staff | The fleet: nodes, storage, IP pools, packages, templates, backups, customers, resellers, imports, announcements and the audit log, limited by their role. |
Words used in these docs
| Term | Meaning |
|---|---|
| Controller | The central server running the panel and API. |
| Node | A KVM hypervisor running the agent. VirtFusion calls these hypervisors. |
| Region | A location, such as Amsterdam. Servers keep their IP addresses when they move between nodes in the same region. |
| Node group | A set of nodes in a region with a placement rule that decides where each new server goes. Packages are sold in node groups. |
| Package | The size and limits of a server: vCPUs, memory, disk, traffic, speed limits, snapshots and the default backup plan. |
| IP pool | A range of addresses handed to servers on its nodes. |
| Storage pool | Where a node keeps server disks: LVM thin, LVM, ZFS or qcow2 files. |
| Backup storage | An S3 bucket or SFTP server that backups are sent to, off the nodes. |
| Backup plan | How often backups run and how many are kept. |
| Job | A long-running action, such as creating, reinstalling or moving a server, shown with its progress. |
The same rules everywhere
Every rule (who can see what, quotas, placement, disks only growing, idempotency) lives in one engine. It runs inside the controller, and also in the browser for the demo, so the demo behaves the way a real install does.
Where to go next
- Check the requirements.
- Install the controller.
- Prepare a hypervisor and add it as a node.