Skip to main content
A FalkorDB Enterprise license is a signed token that authorizes the admin server and encodes the resource limits your account has purchased. It is issued by FalkorDB, verified inside your cluster, and never leaves it.

​
Get a license

Getting a license happens in two phases. FalkorDB onboards your organization once; after that your team issues its own licenses without waiting on anyone.

​
Onboarding, once per organization

Request access to the FalkorDB Enterprise Portal from your FalkorDB account manager. Onboarding creates your organization and sets the quota it can draw against — the ceiling on Kubernetes clusters, CPU cores, memory and deployments your account is entitled to, and how far out licenses may be dated.

Enterprise Portal

How to get access, register a cluster, and issue its license.
To avoid a round trip, include:

​
Self-service, after onboarding

Once your organization exists, licensing moves to the FalkorDB Enterprise Portal, a FalkorDB-hosted site your team signs in to. From there you can, without contacting anyone:
  • Register a Kubernetes cluster and receive its license immediately. A license is minted at the moment of registration — the two are never created apart.
  • Regenerate a license for a cluster, for example after it expires or if the string was mishandled.
  • Resize a cluster, within the quota your organization already holds.
  • Request more quota when you need to grow beyond it. Quota changes are the one step that still goes through FalkorDB.
Registration asks for the cluster ID described in Binding to a cluster, along with the CPU, memory and deployment capacity that cluster should be allowed. Those numbers are checked against your remaining quota and then become the license limits.
You do not need a license to start. An unlicensed admin server begins a 14-day trial with no limits the first time it starts, so you can install and evaluate before onboarding completes. When the trial ends the installation goes read-only until a license is activated.

​
How licenses are generated

Licensing is entirely offline. Nothing in the flow contacts a FalkorDB server, at issue time or at validation time, so an air-gapped installation is licensed exactly like a connected one.
1

FalkorDB signs the payload

The portal holds a private signing key. A small JSON payload describing your account, cluster, limits and expiry is signed with it. The key stays in FalkorDB-hosted infrastructure and is not part of any release artifact.
2

You receive a single string

The result is one line of text in the form falkor.license.v1.<payload>.<signature>. The payload segment is the base64url encoding of the JSON, and the signature covers that exact segment. Both are readable, and neither is secret in the sense a password is — but a modified payload will not verify.
3

The admin server verifies it locally

The matching public key is compiled into the admin server image. It is not a chart value and not fetched at runtime, so verification works with no network access at all. The image also carries a checksum of the public key and re-checks it on every validation, so a tampered image fails closed rather than accepting forged licenses.
The portal and your cluster never talk to each other. There is no callback, no heartbeat and no activation server: the signed string is the only thing that crosses the boundary, and you carry it across. A cluster that is air-gapped, or offline for a month, is licensed exactly like a connected one. The signature scheme is Ed25519. The payload carries a version field, which is 1 today; the admin server rejects any version it does not recognize rather than guessing at the meaning of unknown fields.

​
What is inside a license

Nothing in the payload is encrypted, so you can always decode it to see exactly what you have been granted.

​
Binding to a cluster

Every license the portal issues is locked to exactly one Kubernetes cluster. That is why registering a cluster and issuing its license are a single step: there is nothing to bind a license to until the cluster is registered. Cluster identity is the uid of the kube-system namespace, which Kubernetes assigns when the cluster is created and which no two clusters share. Read it out of the cluster you are registering:
The portal records that value as k8sClusterId. At validation time the admin server compares it against the K8S_CLUSTER_ID environment variable when one is set, and otherwise against the live kube-system namespace uid.
A license only works on the cluster it was issued for. Activating it anywhere else fails with License is not valid for this Kubernetes cluster, and the installation stays read-only. Rebuilding a cluster from scratch produces a new kube-system uid, so treat it as a new cluster to register rather than one to move a license onto. See Disaster recovery into a replacement cluster.

​
When the cluster ID cannot be read

Reading the kube-system namespace can fail for reasons that say nothing about which cluster the admin server is in: an API server outage, a timeout, or a missing RBAC permission. Such a failure does not invalidate the license. The admin server keeps using its last successful check of the same cluster ID for a grace period, 24 hours by default, and reports the binding as unverifiable. The Admin UI shows a warning with the time the grace period ends. Only a definitive answer invalidates a bound license straight away: the namespace was read and its uid differs, or the API server reports that kube-system does not exist. If the grace period runs out before a check succeeds, the license becomes invalid until the next successful check. Set the grace period with adminServer.license.verificationGracePeriodHours in the Helm values. 0 turns it off, so any failed check invalidates the license. The license format itself allows k8sClusterId to be omitted, in which case the admin server accepts the license on any cluster. Such licenses are not something you can issue for yourself; ask support if an unbound license is genuinely required.

​
What a license limits

A license constrains four dimensions. Every one of them is a live count taken from the installation itself, not a figure you self-report. Each dimension is either a number or unlimited. CPU and memory are read from the resource requests you set on a deployment, falling back to limits when no request is set, and are multiplied by the number of nodes in each component. A Sentinel or sharded deployment therefore counts every node it runs, not one per deployment. Notably, the license does not gate features. Authentication providers, backups, sharding, monitoring and the API are all available regardless of which license you hold. Only capacity is licensed.

​
When a limit would be exceeded

Limits are checked before a change is applied, not after. Creating a deployment, scaling one up or down, changing its resources, or adding a user all recompute what usage would become and refuse the change if it crosses a limit. The existing installation keeps running untouched — an over-limit request is rejected, never partially applied.

​
License states

The admin server reports exactly one state at a time. Limits are enforced on the change an action would make. Using a limit exactly is fine: once every licensed deployment slot or core is in use, the installation stays active and only actions that would go past a limit are refused. Those include creating another deployment, creating one that alone needs more than the remaining quota, scaling out or up, and adding users. The same checks apply to deployments created or edited as raw YAML. They fail with a License limit exceeded error that names the resource. In locked, the same rule applies to whichever limit is exceeded: actions that would grow it further are refused. Everything else keeps working, including deleting, scaling down, restarting, stopping and reconfiguring deployments. That’s how you bring usage back within the license. In expired and invalid the installation enters read-only mode. Authenticated write requests are refused with HTTP 423 Locked, while reads continue to work normally. Deleting a deployment is still accepted, so you can free capacity. Your databases are unaffected and keep serving traffic. Read-only mode applies to the management plane, not to the data plane. Recovery operations on an existing deployment also stay available, because they change no licensed usage:
  • Restart, start and stop
  • Switchover to another replica
  • On-demand backup
Everything else is refused, including creating, scaling, reconfiguring or editing deployments, restoring a backup (which always creates a new deployment), and changing backup schedules and policies. The licensing and authentication endpoints stay reachable in read-only mode by design, so you can always sign in and activate a replacement license to recover.

​
Activate a license

The license reaches the admin server in one of three ways.

​
Admin UI

Sign in and open Licensing in the sidebar. Paste the license string and activate it. This works even when the installation is locked, and is the fastest way to recover from an expired license.

​
Command line

​
Helm

Supply the license at install time for unattended deployments. See Production installation for the Secret and values keys.
Keep admin server persistence enabled. Validated license state is written to /data/license-state.json, and a license activated through the UI, CLI or API is lost on pod restart if that path is not backed by a volume.

​
Check the current status

The same information is on the Licensing page of the Admin UI, which shows the active limits next to current usage, the expiry date, and any violations that are holding back new deployments and scale-ups. Check it before scaling up, so a capacity change does not fail at apply time.

​
Renew or change a license

Renewals and resizes are self-service in the portal. Regenerate the cluster’s license, or change its capacity, and activate the new string the same way as the first one. There is no migration step and no downtime: activating a new license replaces the previous one immediately, and an installation sitting in locked because it outgrew its limits returns to active as soon as a license covering current usage is activated. Two things still go through FalkorDB support: increasing your organization’s quota, and extending the term licenses may be dated to. Both are ceilings set at the organization level, so no amount of self-service can raise them.

​
Disaster recovery into a replacement cluster

A license bound to a lost Kubernetes cluster is invalid on any other cluster, so it cannot license the replacement. On an invalid license you cannot restore a backup, because a restore creates a new deployment, which is not a recovery operation. License the replacement cluster first.
1

Read the replacement cluster's ID

2

Get a license bound to it

Register the replacement cluster in the Enterprise Portal with that ID and the capacity it needs. Registration issues its license. If your quota is already used by the lost cluster, request a quota change, or contact FalkorDB support.
3

Install the admin server with the new license

Put the new license string in adminServer.license.value, or in the Secret named by adminServer.license.existingSecret.name. Do not reuse the lost cluster’s values unchanged. A license supplied through Helm is applied on every start and replaces one activated in the Admin UI, so an old license left there makes the installation invalid again.
4

Confirm the license is active

The Licensing page of the Admin UI shows the same state. It should be active. If you install without a license, the 14-day trial starts instead, and you can activate the new license from the Admin UI later.
5

Restore the data

A backup is restored by cloning the deployment it was taken from (see Restore to a new deployment), so the Admin UI and API can’t yet restore a lost cluster’s backups into a replacement cluster where that deployment doesn’t exist. Contact FalkorDB support to restore them.