Documentation

Requirements

Everything CorePanel expects before and during installation. Read this once and the install itself takes about five minutes.

1. The panel server

CorePanel runs on its own machine, next to your hypervisors. A small VM is plenty to start.

The installer asks two questions, your panel domain and the admin e-mail address, and handles the rest: packages (nginx, MariaDB, Redis, PHP, Node.js from stock Debian), database, TLS with automatic renewal, services, and the admin account. The admin password is shown once at the end and stored nowhere.

The installer is currently provided to early-access partners. Request access.

2. Proxmox VE

Some setups already have it loaded, so check first, on each node:

$ lsmod | grep br_netfilter

If that prints a line containing br_netfilter, the module is already loaded and you can skip this step. If it prints nothing at all, run these two commands: the first loads the module right now, the second makes it load automatically on every reboot:

$ modprobe br_netfilter
$ echo br_netfilter >> /etc/modules

3. The API token

CorePanel talks to your cluster through one API token, created at Datacenter → Permissions → API Tokens. Tokens, users and permissions in Proxmox are cluster-wide, so this is a datacenter-level credential, not a per-node one.

That has a convenient consequence: you onboard a connection, not a node. In CorePanel a connection is one cluster (or one standalone host); give the panel a single reachable host address and it classifies the topology, then discovers and onboards every member node automatically, pinning each node's certificate individually. This is why the admin Nodes page has no "add" button, nodes only ever come from a connection.

Added a node to Proxmox later? Open the connection in CorePanel (Admin → Connections) and press Sync nodes. CorePanel re-probes the connection, pins the new node's fingerprint and starts polling it. Nothing is discovered silently in the background, this one action is the sync.

Creating the token:

1. Create a dedicated user, e.g. corepanel@pve (or use root@pam).
2. Datacenter → Permissions → API Tokens → Add: user as above, token id e.g. panel. If you enable Privilege Separation, grant the token itself the role below; if you disable it, the token inherits the user's permissions.
3. Grant the Administrator role on path / with propagation. CorePanel provisions VMs, manages firewalls and storage content, and creates its own restricted console service account, which requires user-management rights.
4. Copy the secret immediately; Proxmox shows it once.

If the token cannot create users, onboarding still completes and records a console login gap: everything works except browser consoles, until you widen the token and re-probe.

4. Proxmox Backup Server

PBS is optional (local backup storage works out of the box) but recommended. Two ways to connect it:

1. Detect from Proxmox (recommended): if your nodes already have the PBS datastore configured as a storage, CorePanel discovers and adopts it. Credentials stay on the Proxmox side; the panel stores only a reference.
2. Register in the panel: enter the PBS host, datastore, token and fingerprint, and CorePanel configures the storage on your nodes for you.

Creating a PBS token, on the PBS side:

1. Create a backup user, e.g. backup@pbs, then Configuration → Access Control → API Token → Add, e.g. backup@pbs!corepanel.
2. Grant DatastoreBackup on /datastore/<your-store> to the token (Permissions tab, with propagation).
3. Copy the fingerprint from the PBS dashboard; the registration form asks for it.

Sharing a datastore with another system? Use a PBS namespace. Backup groups are keyed by VM ID, so two systems writing the same datastore will collide on reused IDs ("backup owner check failed"). Create a namespace for CorePanel on the datastore and point the storage at it: full isolation, while deduplication still spans the whole datastore.

5. Templates & guests

6. Networking

7. WHMCS

8. Ports at a glance

Questions the page doesn't answer? We're quick to reply.