A key runs on the clusters you paid for, and not on one more.

Last updated 25 August 2026

Every edition is licensed, including the free one

Community Edition takes a key and activates it like any other edition. The difference is the key, not the ceremony: a Community key does not expire, and a paid key does.

The reason is not bookkeeping. Everything an installation is allowed to do sits in the certificate it was issued: its capabilities, its monthly image-name allowance, its framework and cluster counts. An installation with no certificate is not a free installation; it is an installation with no answer to the question, and the only way to serve one is to assume an answer. An assumption cannot be counted, cannot be bound to a cluster and cannot be withdrawn. So there is no unlicensed mode, and the free edition is free because of what its key says, not because it lacks one.

Getting one is the same three steps either way. Create an account at customer.portiger.com, take the free key or buy the plan you want, then enter that key in your own console. Nothing else happens first: there is no sales call in front of the free tier and no form to fill in before you can install.

What a key is bound to

Activation is a one-time exchange per cluster. The installation sends its activation key and a fingerprint of the cluster it is running in; we bind the key to that fingerprint and return a signed certificate that carries the fingerprint inside it.

A key binds to as many clusters as the plan pays for. Community and Team buy one, Business buys three, Enterprise is unbounded. Activating the fourth cluster on a three-cluster key is refused, and the refusal says which of the two things happened: you are out of clusters and can buy another, or one of the three is a cluster you no longer have and can release.

From then on the operator checks three things every time it starts, none of which leave the cluster: that the signature is ours, that the certificate has not expired, and that the fingerprint inside it matches the cluster it is actually running in. A certificate copied to a cluster it was not issued for fails the third check, locally and offline, with no call to us. The binding is not a lookup we perform on request. It is part of what we signed.

The fingerprint is a hash of your cluster's kube-system namespace identifier. It is created with the cluster and does not change for its lifetime. Deleting and reinstalling the operator does not change it, so a reinstall needs nothing from us. Building a new cluster does change it, which is what the section on moving a licence is about.

Your cluster allowance, and what is left of it

A key carries an allowance rather than a single binding, and every activation spends one slot of it. Buy three clusters and the first install leaves two, the second leaves one, the third leaves none. Same key each time, no second key to keep track of.

What is left is not something you have to remember. Your account lists the key, the clusters currently holding its slots with the date each was activated, and the number still free; the operator says the same thing on its own licence screen the moment it activates. Running out is not an error state. It has two ordinary answers: release a slot you are not using, or add one.

Clusters can be added to a key you already own, from your account, without touching the installations already running. The allowance goes up, and the next daily check is the one that notices: a change to what you bought is one of the things that causes a fresh certificate to be issued, so every cluster is carrying the new number within a day, by itself.

Why the cluster count is the one limit that needs us

Your monthly image-name allowance and your framework count are counted by the operator inside your own cluster, because everything they count happens there. Nothing about those two needs us and nothing about them is sent.

The cluster count is different in kind. An operator running in one cluster has no way of knowing that the same key is also running in two others. There is no vantage point inside a cluster from which to see the rest of them. The only place that can hold that number is the side that issued the key and holds the bindings.

So the daily check is not a formality wrapped around an offline licence. It is the only mechanism behind a line we actually sell, and the alternative to having it is printing a cluster count on the price list that nothing enforces.

The daily licence check

Once a day the installation checks its licence with us and takes a fresh certificate. This is not something an installation can be configured out of. There is no setting for it, in the chart or anywhere else. A licence that can be told to stop checking is enforced by whoever installed it, which is not enforcement.

The check sends three values and no others:

• the licence identifier,
• the cluster fingerprint described above,
• the operator version.

It sends no image names, no scan findings, no CVE identifiers, no workload or namespace names, no cluster topology, no user accounts and nothing from your database. It cannot: the image and framework limits are counted inside your cluster, so those counts have no reason to leave it and no code path that would carry them. What travels is enough to answer one question: is this licence still entitled to run on this cluster. Nothing in it would answer a second.

The exact fields, how long we keep them and on what legal basis are in the privacy notice.

You buy a year, the certificate lasts a month

Plans are sold annually. The certificate your installation holds is never that long: it is good for thirty days at most, and it is replaced with a fresh one well before it runs out. Nothing about your subscription changes. The date on the invoice is the date you paid for, and the certificate quietly tops itself up beneath it.

The daily check and the certificate are two different things, and only one of them happens daily. The check asks a question and usually gets "still valid" for an answer, which changes nothing and costs nothing. A new certificate is issued in two cases: when something actually changed (you added clusters, released one, renewed, cancelled), or when the one in hand has fewer than ten days left on it. So an installation is never holding less than about ten days of runway and never more than thirty, and neither of us is signing and storing a new certificate every morning for no reason.

The reason the ceiling is thirty days at all is that a certificate is a promise we cannot take back once it is signed. Write a year into it and we have given away a year: a cancellation, a refund, a chargeback, or a licence you moved to a different cluster would all have to wait for that year to run out before anything took effect. Thirty days is the longest we are willing to be unable to change our mind. It is also the longest you can be disconnected. That is not a coincidence: they are the same number seen from two sides.

Near the end of a term the certificate never reaches past the subscription it belongs to. The last one shortens to end when your year does, so a licence never outlives the thing that paid for it. Renew and the next check restores the full thirty.

When it cannot reach us

Nothing happens, for between ten days and a month, depending on how much life the certificate in hand had left when the connection went. A failed check is retried a few hours later rather than waiting for tomorrow, so a maintenance window, a firewall change or an afternoon of bad routing never reaches the installation as a licensing event. Neither does a fortnight of them.

It does not fail silently either. After a week without a route to us the console says so and counts down the days remaining; before the certificate lapses the administrators are e-mailed. Nobody should discover this by noticing that a feature went missing.

Past thirty days the certificate lapses and a paid installation falls back to Community Edition: scanning, signature verification, admission enforcement and evidence carry on under the free limits. It does not stop, lock you out, or start denying deployments. A Community installation is unaffected, because its certificate does not expire.

Being unreachable and being refused are different states and the installation treats them differently. Silence spends the thirty days. An answer that says this licence has been released or revoked is applied immediately, because in that case we did reach each other and the answer was no.

Moving a licence to another cluster

When the clusters a plan pays for are all bound, the next one is refused with a message that says which problem you have rather than a generic failure: this licence is already active on another cluster, and to use it here you have to release that one first. The refusal names the clusters currently holding the slots and when each was activated, so "which one is the old one" is a question you can answer.

From the old cluster. Deactivate there: the slot is released immediately, the local certificate is erased, and the new cluster can take it at once. This is the clean path and the one to use whenever the old cluster still exists.

From your account. If the old cluster is genuinely gone (deleted, rebuilt, lost with the hardware), release its slot from your account and the new cluster can take it.

One thing this does not do. If the old cluster still exists and still runs, releasing it in your account does not reach into it and switch it off. Nothing can: it holds a certificate that verifies offline. What it can no longer do is renew. Its certificate runs out within thirty days, usually sooner, and that installation falls back to Community Edition on its own.

The window is bounded and known rather than open-ended, and every release is recorded. Releasing the same licence over and over is visible to us and is the kind of pattern we will ask about.

When a licence ends

Expiry and cancellation behave like a certificate that lapsed: the installation returns to Community Edition and keeps working under the free limits. There is no cliff to fall off. Admission control does not stop, and nothing you have already scanned or recorded is taken away.

Cancelling mid-term does not switch anything off on the day you cancel. You keep what you paid for until the term ends, because that is what you paid for; the certificate simply stops being renewed past that date.

Every security capability is in the free edition. What a paid key buys is scale and two capabilities, and the comparison says which.