Licensing

ProxCenter ships in two editions, and licensing is managed from Settings > License by a provider administrator.

Editions

Edition	Description
Community	Free, with a limited feature set. No license key required.
Enterprise	Licensed. Unlocks advanced automation, security, reporting, and MSP / IaaS capabilities.

The License tab shows your current edition, who the license is issued to, the node quota, and the expiry date.

Activating a license

Enterprise licenses reach an install in one of two ways, chosen per customer account on proxcenter.io.

Connected mode (default from ProxCenter 1.4.11)

1. Go to Settings > License and click Connect to proxcenter.io.
2. ProxCenter shows a short code such as ABCD-2345 and a link. Open the link, sign in to your proxcenter.io account, name the instance and tick the licenses it should hold.
3. A license ticked at that step reaches the instance in a few seconds. A license issued or assigned later reaches its instance at its next daily sync, or at once with Sync in Settings > License. A brand new license waits, unassigned, in the Instances card of your proxcenter.io account until it is assigned to an instance, either by you or by proxcenter.io when it is issued; a renewal instead goes automatically to the instance already holding the license it renews. Nothing to paste either way.

If you bought ProxCenter through a reseller partner, your partner connects the instance for you, because you have no proxcenter.io account of your own. Give them the code shown in Settings > License (or let them read it on site); they enter it in their proxcenter.io partner space and approve it for your company. Your partner can also revoke any connected instance of your company. Once connected, the title of the License tab reads ProxCenter Enterprise via your partner's logo and name (the name alone when the partner has not uploaded a logo). If your partner later changes its logo, the new one appears at the next sync.

A connected instance checks in with proxcenter.io once a day. Each key carries a 30-day lease that every successful check-in renews, so an unreachable portal never interrupts production: the keys stay valid until their lease ends. The License tab shows the days left on that lease (a fresh lease shows 30; once under a day is left, it shows "less than a day") and reflects a failed check-in as soon as it happens; the notification bell only warns once 3 check-ins in a row have failed (retries keep trying, spaced further apart each time). The check-in sends the install identifier and public key, the install fingerprint, the ProxCenter version, the name of each connection with its cluster name and node count, the identifiers of the licenses held, the digest of the partner logo it already holds (so the logo is sent again only when it changes), a counter and a timestamp (used for diagnostics), and a rolling token that lets proxcenter.io tell this copy of the installation apart from any other, and nothing else. In an HA deployment only the leader checks in; the other orchestrators pick the keys up from the shared database, and if a failover briefly leaves two nodes both believing they lead, only one of them actually checks in at a time, so this never triggers the clone protection described below.

Behind an HTTP proxy, set HTTPS_PROXY on the orchestrator container (the Docker daemon proxy alone is not enough, as for the CVE feed). To remove the connection option entirely, whatever the account's mode (no Connection card in Settings at all), set PROXCENTER_OFFLINE=true or license.portal.enabled: false on the orchestrator; this is the default for an air-gapped bundle install.

Restoring a backup, or a copy running alongside the original

Restoring a database backup, or copying the whole stack (database volume and APP_SECRET) so the copy keeps the same install identity, is common for disaster-recovery drills and database failovers. proxcenter.io tells a one-off restore apart from two copies both actually running:

• A single restore, such as after a DR test or a database failover to a replica that was slightly behind, is accepted: the restored copy checks in normally and keeps its keys. Nothing shows in ProxCenter; proxcenter.io only logs it for its own support team.
• Two copies actually running and checking in at the same time are not accepted: the copy that checks in first keeps working, and the other copy, the one still holding the older check-in, is refused at its next check-in. Its Settings > License tab shows: "Another copy of this installation is active on proxcenter.io. This copy was refused." On proxcenter.io, the account's Instances card shows that instance as "Refused: another copy is active". This can catch the production copy just as easily as a newly started DR or test copy, so keep a DR or test copy disconnected (Disconnect, or Reset install identity) until you actually mean to start it alongside production.
• The refused copy is not cut off at once: it keeps the keys it already holds until their lease ends, gets no renewal after being refused, and then falls back to the Community edition. It cannot unblock itself: only proxcenter.io support can lift the block. Once support has lifted it, click Reconnect on the refused copy and approve the code again to resume it as the same installation. If it should instead carry on as its own installation, click Reset install identity on it, then connect it again as a new instance, which then needs its own license.

Air-gapped mode (request file)

For sites without internet access, ask your partner or support to set your account to the air-gapped mode. Licenses are then delivered through a signed request file:

1. Go to Settings > License and click Generate a license request. On a Community install, Server without Internet access? explains these steps first, then downloads the request file.
2. Upload the file in your proxcenter.io account (or send it to your partner).
3. Paste the returned key under License key and confirm.

A key issued this way is bound to the install fingerprint shown on the tab and requires ProxCenter 1.4.11 or later. Keys issued before the cutover keep working on any version until they expire.

If the instance is currently connected to proxcenter.io, pasting a key here does not stick: it is replaced by the edition proxcenter.io assigns to this instance at the next check-in. Click Disconnect first, or have the account moved to the air-gapped mode, before pasting a key.

Moving a license to another instance

Connected mode: on proxcenter.io, connect the new instance and tick the license, or assign it from the Instances card of your account. The new instance receives the key at its next check-in; the previous instance keeps it for 7 more days, then falls back to the Community edition. Each move counts against the self-service quota of your account (3 per year by default); your partner or support can move a license beyond it.

Air-gapped mode: generate a license request on the new install and upload it as a rebind. The previous key stays usable on the previous install until it expires.

In the Instances card of your proxcenter.io account, a connected instance that has not synced for 14 days is flagged Inactive for N days, as a hint to revoke it if the machine is gone. A revoked instance stays listed while its licenses run out their lease, then moves to a folded Revoked instances section.

The license defines a node quota, that is, how many Proxmox nodes the install may manage (some licenses are unlimited). You can deactivate a license from the same screen.

Node quota and enforcement

Enforcement is based on the total number of nodes across your managed clusters against your licensed capacity. If you exceed the capacity, the install switches to read-only until you are within the limit again. Read operations and visibility are never blocked.

Stacking multiple licenses

A single ProxCenter install can carry more than one license at once. This is useful in two situations:

• Central NOC aggregation -- A central install supervises several remote sites that are already licensed locally. Stacking lets each site keep its own license without being counted twice against a single quota.
• Capacity expansion -- Instead of regenerating a larger license when you add nodes, you import a supplemental license. The fleet quota grows by the additional nodes, the original license is untouched, and the supplement lapses on its own expiry.

Importing an additional license

1. In Settings > License, click Import a license.
2. Paste the additional license key under License key.
3. Optionally map it to a cluster under Map to a cluster (optional), or leave it as Floating (no cluster).
4. Click Import.

A floating license contributes to your capacity whenever it is active. A cluster-mapped license contributes while it is mapped to a cluster.

Fleet capacity

With stacking, the License tab shows a Fleet capacity summary: the sum of all active licenses, compared against the total number of nodes. The install stays within capacity as long as that total does not exceed the sum, and switches to read-only beyond it.

Editing a mapping

Use Edit mapping on a license to select the clusters it covers. A cluster already covered by another license is disabled in the picker, so a cluster is never double-counted.

When the main license is invalid

If the main license is missing, expired, past its lease or bound to another install, a valid imported license keeps the install licensed: the best one by edition, then node quota, then expiry date. The License tab shows Primary invalid, says why, names the imported license that provides the edition and until when, and marks it Provides the edition in the table. Nothing is rewritten: the main license takes back as soon as it is valid again, for example after a sync renews its lease.

Removing an imported license

Use Remove on an imported license. The nodes it covered fall back under the primary license quota.

Per-tenant attribution

In an MSP deployment, the License tab shows a Per tenant breakdown: license coverage attributed to each customer tenant, with the Licensed to name (the customer's company, or their name).

Attribution is derived, not configured directly. A license is mapped to a connection (a cluster), and that connection is owned by a tenant, so coverage flows from the license to the connection to the owning tenant. There is no direct license-to-tenant link to maintain. The per-tenant view is for visibility and reseller billing; enforcement remains based on the fleet total.

Enterprise feature

Licensing, license stacking, and the per-tenant rollup are Enterprise capabilities, managed by provider administrators.

Limitations

• A copy of the whole stack (database volume and APP_SECRET) is a copy of the install identity; see "Restoring a backup, or a copy running alongside the original" above for how connected mode tells a one-off restore apart from two copies running at once.
• The install clock judges the lease. A clock set back is reported, not blocked.
• Moving a license in connected mode leaves it usable on the previous instance for 7 days (30 if that instance stopped checking in). In air-gapped mode the previous key stays valid until it expires.
• Resetting the install identity, or restoring only the database backup on another server without the same APP_SECRET (so the install identity's signing key cannot be decrypted), creates a new instance: reconnect it, then move the licenses to it.

Permissions

Permission	Description
super_admin	Full access to license management
admin.settings	Required to manage the license and imports

License management is provider-only: it is performed from the provider tenant.