Skip to main content

Licensing

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

Editions​

EditionDescription
CommunityFree, with a limited feature set. No license key required.
EnterpriseLicensed. 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.

Checking Activation and Feature Access​

After connecting or importing a license, return to Settings > License and check the edition, Nodes, Valid until and Received from status. For a connected instance, use Sync after assigning or renewing a license on proxcenter.io, then review the updated status.

License summary card of a connected Enterprise license received via a partner, with Sync failing status, the icon toolbar numbered 1 Sync, 2 Generate a license request, 3 Activate a license key, 4 Copy the fingerprint and 5 Disconnect, the nodes used against the allowed total, next expiry and Received from
The license actions are icons: Sync (1), Generate a license request (2), Activate a license key (3), Copy the fingerprint (4) and Disconnect (5). Hover an icon to see its name.
License summary with the nodes used across all licenses against the allowed total, the next expiry date, and the Received from line with the last sync and an unreachable warning
Review the managed-node quota, expiry and sync status after activation or renewal.

An Enterprise edition does not include every add-on. Settings > API requires the separate ProxCenter API Access add-on; without it, token creation and token-authenticated calls are refused even while Enterprise is active. See API Tokens. The Proxmox VE subscription shown on a hypervisor is also separate from the ProxCenter license.

Activating a license​

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

Connected mode (default)​

  1. Go to Settings > License and click Connect to proxcenter.io.
  2. ProxCenter shows a short code such as ABCD-2345 and a link. The code is valid for 10 minutes; once it has expired, start the connection again to get a new one. 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.
Sequence diagram: the administrator starts the connection in ProxCenter, which gets a pairing code from proxcenter.io; the administrator signs in to proxcenter.io, checks the install, names the instance and ticks its licenses; ProxCenter polls until approved, receives the license keys, then checks in once a day to renew its 30-day leaseSequence diagram: the administrator starts the connection in ProxCenter, which gets a pairing code from proxcenter.io; the administrator signs in to proxcenter.io, checks the install, names the instance and ticks its licenses; ProxCenter polls until approved, receives the license keys, then checks in once a day to renew its 30-day lease
You start the pairing in ProxCenter and approve it yourself in your proxcenter.io account. Bought through a partner? You can do the same, or let your partner approve it: see the partner flow.
License tab of ProxCenter waiting for approval, with the pairing code, its remaining validity, and the Open proxcenter.io button
The pairing code shown in Settings > License while ProxCenter waits for the approval on proxcenter.io.

Bought through a reseller partner? Your partner registered your company on proxcenter.io, and you have your own sign-in there with the email address your partner registered. Use the invitation email you received, or Forgot password on proxcenter.io/account/login if you have no password yet. Then connect the instance yourself, as above: click Connect to proxcenter.io, open the link, sign in, name the instance and tick its licenses.

Your proxcenter.io space shows your licenses and instances only. You can download your license keys and connect, rename or revoke your instances. Prices, invoices and orders stay with your partner, and you cannot change your sign-in email yourself: ask your partner.

If you prefer, your partner can still approve the code for you: give them the code, or let them read it on site, and they approve it from their partner space, see Connecting a customer's instance (partners).

Once connected, the License tab reads ProxCenter Enterprise via your partner's logo and name (the name alone if the partner has no logo; a new logo shows at the next sync). Your partner can also revoke any connected instance of your company.

Connecting a customer's instance (partners)​

When you register a company in your partner space, its contact receives an email inviting them to create a password on proxcenter.io. In their own space they can connect their instances and download their license keys themselves; they never see your prices, orders or invoices. The company page shows whether they have done so (Portal access).

You can also connect each of their instances yourself from your partner space at proxcenter.io/partner, and you assign their licenses.

Before you start:

  • Your reseller agreement must be signed.
  • Only the Owner and Technical roles of your team can connect, assign or revoke an instance. A Billing member sees the instances read-only.
Sequence diagram: the customer administrator starts the connection in ProxCenter, which gets a pairing code from proxcenter.io; the customer sends the code to the partner by email or on site; the partner staff looks it up in the partner space, checks the install, names the instance and ticks its licenses; ProxCenter polls until approved, receives the license keys, then checks in once a day to renew its 30-day leaseSequence diagram: the customer administrator starts the connection in ProxCenter, which gets a pairing code from proxcenter.io; the customer sends the code to the partner by email or on site; the partner staff looks it up in the partner space, checks the install, names the instance and ticks its licenses; ProxCenter polls until approved, receives the license keys, then checks in once a day to renew its 30-day lease
When the partner approves: the customer starts the pairing in ProxCenter and sends the code; the partner approves it from its partner space. The customer can also approve it from their own proxcenter.io space instead.
  1. On the customer's ProxCenter, a provider administrator opens Settings > License and clicks Connect to proxcenter.io. ProxCenter shows a pairing code valid for 10 minutes, that the customer sends you (or you read it on site).
  2. On proxcenter.io, open the connection screen:
    • from Companies, open the customer, then click Connect an instance on the Instances tab, or Connect next to a waiting license on the Licenses tab; the customer is already selected;
    • or, on site, click Open proxcenter.io next to the code while signed in to your partner space; the code is already filled in, choose the customer.
  3. Enter the code if needed and click Look up. Check the fingerprint, ProxCenter version and clusters shown: they identify the install.
  4. Name the instance, tick its licenses and click Connect this instance (or Refuse to reject the code).
Connect an instance screen of the partner space, with the customer selected, the looked-up instance, its name and the license waiting for an instance ticked
The partner picks the customer, looks up the code, names the instance and ticks the licenses it should hold.

The licenses offered are grouped by origin:

GroupMeaning
Licenses waiting for an instanceLicenses of the customer not held by any instance yet, ticked by default.
Offline licenses bound to this installKeys issued from a request file for this same install, converted to the connected mode for free.
Licenses held by another instanceLicenses already delivered to another instance of the customer. Ticking one moves it here and counts against the customer's quota, see Moving a license to another instance.
Confirmation in the partner space that the instance is connected, with the license assigned to it
Once approved, the screen lists the outcome for each license ticked.
  1. The instance receives its keys within a minute, with nothing to paste. Its License tab then reads ProxCenter Enterprise via your logo and name, with the customer's company name below.
License tab of ProxCenter showing ProxCenter Enterprise via the partner name, the customer company, the node quota and the expiry date
The customer's License tab names the partner that delivered the license.

After the connection, everything stays in your partner space, on the customer's Instances tab:

  • A license issued later for this customer waits on that tab until you pick its instance in the Assign to… list. A renewal goes by itself to the instance holding the license it renews.
  • Revoke, in the menu of an instance, disconnects it. It gets no renewal after that: its keys keep working until their lease ends (30 days at most), then it falls back to the Community edition. If the same install is connected again later, the first return within the quota window gives its licenses back without counting as a move.

Daily check-in and lease​

Timeline over 50 days of a connected instance. A top row marks the daily check-ins: successful until day 20, then failed, with retries after 2 h, 4 h and 8 h, then every 12 h, while the keys keep working, and successful again from day 48. Below, a line shows the days left on the lease: it counts down from 30 days and, on day 16 with fewer than 15 days left, the check-in renews it to 30 days. From day 20 proxcenter.io is unreachable: the License tab shows it at once and the notification bell warns after 3 failed check-ins in a row, and the lease runs down unrenewed. On day 39, with 7 days left, the bell turns critical with The license lease ends in 7 days. On day 46 the lease ends: the License tab shows Sync overdue, Your licenses stopped working, and the Community edition applies. On day 48 the first successful sync brings the licenses back and the lease returns to 30 days. A note adds that in an HA deployment only the leader checks in.Timeline over 50 days of a connected instance. A top row marks the daily check-ins: successful until day 20, then failed, with retries after 2 h, 4 h and 8 h, then every 12 h, while the keys keep working, and successful again from day 48. Below, a line shows the days left on the lease: it counts down from 30 days and, on day 16 with fewer than 15 days left, the check-in renews it to 30 days. From day 20 proxcenter.io is unreachable: the License tab shows it at once and the notification bell warns after 3 failed check-ins in a row, and the lease runs down unrenewed. On day 39, with 7 days left, the bell turns critical with The license lease ends in 7 days. On day 46 the lease ends: the License tab shows Sync overdue, Your licenses stopped working, and the Community edition applies. On day 48 the first successful sync brings the licenses back and the lease returns to 30 days. A note adds that in an HA deployment only the leader checks in.
An unreachable proxcenter.io never stops production at once: the keys run out their lease, with warnings on the way, and the first successful sync brings them back.
  • A connected instance checks in with proxcenter.io once a day.
  • Each key carries a 30-day lease, renewed by every successful check-in. An unreachable portal never interrupts production: the keys stay valid until their lease ends.
  • The License tab shows the days left on the lease (30 when fresh, "less than a day" at the end) and shows a failed check-in at once. The notification bell only warns after 3 failed check-ins in a row; retries keep going, spaced further apart each time.
  • In an HA deployment, only the leader checks in and the other orchestrators read the keys from the shared database. If a failover briefly leaves two nodes both believing they lead, only one of them checks in at a time, so the clone protection described below is never triggered.
License summary card with Sync failing and the tooltip of the unreachable warning: unreachable since a date, the number of failed attempts, the next try, and the date until which licenses keep working without a sync
When the portal cannot be reached, hover the unreachable warning: it tells how long the check-in has been failing and until when the licenses keep working.

The check-in sends only:

  • the install identifier and public key, and 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 already held, so the logo is sent again only when it changes;
  • a counter and a timestamp, used for diagnostics;
  • a rolling token that lets proxcenter.io tell this copy of the installation apart from any other.

Proxy and offline switch​

  • Behind an HTTP proxy, the installer passes the proxy to the orchestrator through /opt/proxcenter/.env, see Installing behind an HTTP proxy.
  • 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:

Flowchart. A copy with the same install identity, such as a restored backup or a DR or test copy, checks in, and proxcenter.io asks whether two copies are running at once. No: it is a one-off restore, accepted; it checks in normally, keeps its keys, and nothing shows in ProxCenter. Yes: the copy holding the older check-in is refused and its License tab shows Copy detected, Another copy of this instance uses the same licenses. From there it keeps its keys until their lease ends, with no renewal after the refusal, then runs the Community edition; two ways out are done by hand: Reconnect once support lifts the block, which resumes it as the same installation, or Reset install identity, then connect it as a new instance that needs its own license. A note says the refused copy can be production as easily as DR, so keep a DR or test copy disconnected, with Disconnect or Reset install identity, until you mean to run it alongside production.Flowchart. A copy with the same install identity, such as a restored backup or a DR or test copy, checks in, and proxcenter.io asks whether two copies are running at once. No: it is a one-off restore, accepted; it checks in normally, keeps its keys, and nothing shows in ProxCenter. Yes: the copy holding the older check-in is refused and its License tab shows Copy detected, Another copy of this instance uses the same licenses. From there it keeps its keys until their lease ends, with no renewal after the refusal, then runs the Community edition; two ways out are done by hand: Reconnect once support lifts the block, which resumes it as the same installation, or Reset install identity, then connect it as a new instance that needs its own license. A note says the refused copy can be production as easily as DR, so keep a DR or test copy disconnected, with Disconnect or Reset install identity, until you mean to run it alongside production.
A one-off restore is accepted. Two copies running at once are not: the one presenting the older check-in is refused, and only support can lift the block.
  • 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. Bought through a partner? Send it to your partner, who returns the key.
  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.

Import an additional license dialog with an example license key pasted and the Map to a cluster (optional) list open on Floating (no cluster), PVE-DR and PVE-PROD
Paste the additional key, then keep it floating or map it to one cluster before clicking Import.

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.

Licenses card with four licenses: the primary Enterprise license covering PVE-PROD and PVE-DR, an imported Enterprise trial in the shared pool with its Edit mapping (1) and Remove (2) actions, two add-on options, and the Per tenant breakdown
Stacked licenses are listed with the nodes they cover and their clusters. Use Edit mapping (1) or Remove (2) on an imported license.

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.

Edit license mapping dialog with the hint that a cluster already covered by another license is disabled, the PVE-DR and PVE-PROD checkboxes, Cancel and Save
Tick the clusters the license should cover, then save.

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.

Diagram in three columns: licenses, clusters and owning tenants. The primary license, Enterprise with 10 nodes, covers the clusters no imported license covers, here pve-cluster-a with 3 nodes, owned by the Provider tenant. An imported license, Enterprise with 5 nodes, is mapped with Edit mapping to pve-cluster-b with 4 nodes, owned by the MSP tenant msp-customer-a. Below, two License tab panels: Fleet capacity compares the 7 managed nodes with the 10 + 5 = 15 licensed, shows Within licensed capacity while 7 is at most 15, and says the install switches to read-only beyond 15; Per tenant, fed from the owning tenant, follows license to cluster to owning tenant, has no direct license-to-tenant link, does not list the primary license, and shows msp-customer-a · 4 / 5. A note adds that a floating import adds its nodes to the capacity without covering a cluster.Diagram in three columns: licenses, clusters and owning tenants. The primary license, Enterprise with 10 nodes, covers the clusters no imported license covers, here pve-cluster-a with 3 nodes, owned by the Provider tenant. An imported license, Enterprise with 5 nodes, is mapped with Edit mapping to pve-cluster-b with 4 nodes, owned by the MSP tenant msp-customer-a. Below, two License tab panels: Fleet capacity compares the 7 managed nodes with the 10 + 5 = 15 licensed, shows Within licensed capacity while 7 is at most 15, and says the install switches to read-only beyond 15; Per tenant, fed from the owning tenant, follows license to cluster to owning tenant, has no direct license-to-tenant link, does not list the primary license, and shows msp-customer-a · 4 / 5. A note adds that a floating import adds its nodes to the capacity without covering a cluster.
Capacity is the sum of the active licenses, checked against every managed node. The Per tenant view follows each imported license to its clusters and their owner.
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​

PermissionDescription
super_adminFull access to license management
admin.settingsRequired to manage the license and imports

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