Enterprise Edition License Management

The Enterprise Edition of ArangoDB requires a license so that you can use ArangoDB for commercial purposes and have a dataset size over 100 GiB. See ArangoDB Editions for details.

Which method applies to you?

Which approach you use depends on how you run ArangoDB and whether the deployment has internet access:

The rest of this page describes each method in detail. The Platform CLI tool sections and the container walkthrough apply to every row except Kubernetes with internet access — for that case, the operator handles everything, so you can skip to the Kubernetes-managed deployment subsection under Activate a deployment.

License methods summary

• Activate a deployment (from the v3.12.6 release date onward):
  Customers receive license credentials composed of a client ID and a client secret. You can use the Platform CLI tool to activate deployments with these credentials, either one-off or continuously.

  An activation is generally valid for two weeks and it is recommended to renew the activation weekly.

• Apply a license key:
  Before the time of the v3.12.6 release, customers received a license key directly and it was typically valid for one year. Since this release, customers receive license credentials instead. You can use the Platform CLI tool to generate a license key using these credentials, and the license key generally expires every two weeks.

  You can also activate a deployment instead of generating a license key, but this requires an internet connection. For air-gapped environments for example, the license key method is required and the license key has a longer validity.

Activate a deployment

Standalone deployment

You can activate a standalone deployment with the Platform CLI tool or, if your contract enables it, with the License Activation portal in Managed or Generic mode. The Platform CLI tool is the recommended option for ongoing operation because it can re-activate the deployment automatically on a fixed interval. The activation portal is a quick, browser-based alternative for one-off activation. An activation has a short validity by default; the portal’s Custom TTL lets you override it within the limits permitted by your contract.

Platform CLI tool

1. Download the Platform CLI tool arangodb_operator_platform from https://github.com/arangodb/kube-arangodb/releases . It is available for Linux, macOS, and Windows for the x86-64 as well as 64-bit ARM architecture (e.g. arangodb_operator_platform_linux_amd64).

   It is recommended to rename the downloaded executable to arangodb_operator_platform (with an .exe extension on Windows) and add it to the PATH environment variable to make it available as a command in the system.

2. Activate a deployment once using the Platform CLI tool. Point it to a running ArangoDB deployment (running on http://localhost:8529 in this example) and supply the license credentials:

   arangodb_operator_platform license activate \
     --arango.endpoint http://localhost:8529 \
     --license.client.id "your-company" \
     --license.client.secret "00000000-0000-0000-0000-000000000000"
   

   Unless authentication is disabled for the deployment, you need to additionally supply either ArangoDB user credentials or a JWT session token and specify the authentication method (case-sensitive):

   # User credentials
   arangodb_operator_platform license activate \
     --arango.authentication Basic \
     --arango.basic.username "root" \
     --arango.basic.password "" \
     ...
   
   # JWT session token
   arangodb_operator_platform license activate \
     --arango.authentication Token \
     --arango.token "eyJh..." \
     ...
   

3. By default, the Platform CLI tool activates the deployment once and exits. This one-shot mode is suited to scheduled invocations — for example, from a cron job or a systemd timer that runs the command once a week. Each run is independent, so a failed activation surfaces through the scheduler’s normal failure reporting.

   Alternatively, you can specify an activation interval to keep the tool running and have it re-activate the deployment automatically, e.g. once a week:

   arangodb_operator_platform license activate \
     --license.interval 168h \
     ...
   

   In this continuous mode, run the Platform CLI tool under a process supervisor (for example a systemd unit with Restart=always, a container with a restart policy, or Kubernetes) so renewals resume automatically if the process exits unexpectedly.

License Activation portal

The portal supports three activation modes:

• Inventory identifies the deployment by an inventory.json file produced by the Platform CLI tool. The default mode, and the only option available for most customers.
• Managed identifies the deployment by its deployment ID alone. No inventory file is needed. The mode covered in the procedure below, because it applies to a running online standalone deployment.
• Generic uses the license credentials only, with no deployment binding. The procedure below applies; just skip the deployment ID step.

The portal generates a license key for a deployment without running the Platform CLI tool. It is suited to one-off activation; for unattended renewal, use the Platform CLI tool’s --license.interval instead.

1. Get the deployment ID from a running ArangoDB instance:

   # User credentials (-u username:password)
   curl -u root: http://localhost:8529/_admin/deployment/id
   
   # Example result:
   # {"id":"6172616e-676f-4000-0000-05c958168340"}
   

2. Open https://activate.license.arango.ai/ .

3. Enter your License Client ID and License Client Secret.

4. Select the activation mode:

   • Inventory (default): upload the inventory.json file produced by arangodb_operator_platform license inventory. See Generate a license key for the end-to-end flow that uses this mode.
   • Managed — Deployment ID only: paste the deployment ID from step 1.
   • Generic (if available): no further input is needed.

5. Optionally enable Custom TTL to override the default license duration.

6. Click Activate and copy the generated license key.

7. Apply the license key to ArangoDB using one of the interfaces in Apply a license key — for example arangosh or the HTTP API.

Repeat this procedure when the license is close to expiry. If you want unattended renewal, use the Platform CLI tool with --license.interval instead.

Kubernetes-managed deployment

With a Kubernetes-managed deployment, the ArangoDB Kubernetes Operator activates and re-activates the deployment for you. You only need to make your license credentials available as a Kubernetes secret and reference it in the ArangoDeployment spec. The Kubernetes cluster must be able to reach *.license.arango.ai.

1. Create a Kubernetes secret from your license credentials. Substitute <license-client-id> and <license-client-secret> with the actual values:

   kubectl create secret generic arango-license-key \
     --namespace arango \
     --from-literal=license-client-id="<license-client-id>" \
     --from-literal=license-client-secret="<license-client-secret>"
   

2. Reference the secret in the spec.license.secretName field of the ArangoDeployment:

   apiVersion: "database.arangodb.com/v1"
   kind: "ArangoDeployment"
   metadata:
     name: "deployment-example"
   spec:
     # ...
     license:
       secretName: arango-license-key
   

See Contextual Data Platform — License Management for the operator’s renewal cycle, the required network access, and the configuration options that let you tune TTL and grace periods.

Generate a license key

1. Download the Platform CLI tool arangodb_operator_platform from https://github.com/arangodb/kube-arangodb/releases . It is available for Linux, macOS, and Windows for the x86-64 as well as 64-bit ARM architecture (e.g. arangodb_operator_platform_linux_amd64).

   It is recommended to rename the downloaded executable to arangodb_operator_platform (with an .exe extension on Windows) and add it to the PATH environment variable to make it available as a command in the system.

2. Create an inventory file using the Platform CLI tool. Point it to the running ArangoDB deployment that the license should apply to. Replace <arango-endpoint> with the URL of that deployment — use http://localhost:8529 only if the Platform CLI tool runs on the same host as the ArangoDB instance you want to license; otherwise use the deployment’s actual address (for example, http://10.0.0.5:8529 or https://arangodb.example.com:8529).

   The inventory file captures the deployment ID of whichever ArangoDB instance you point the Platform CLI tool at. The license key generated from it only works for that instance. Make sure the endpoint is the deployment you intend to license — not a local test or throwaway instance.

   arangodb_operator_platform license inventory \
     --arango.endpoint="<arango-endpoint>" \
     inventory.json
   

   Unless authentication is disabled for the deployment, you need to additionally supply either ArangoDB user credentials or a JWT session token and specify the authentication method (case-sensitive):

   # User credentials
   arangodb_operator_platform license inventory \
     --arango.authentication Basic \
     --arango.basic.username "root" \
     --arango.basic.password "" \
     ...
   
   # JWT session token
   arangodb_operator_platform license inventory \
     --arango.authentication Token \
     --arango.token "eyJh..." \
     ...
   

3. Determine the ID of the ArangoDB deployment by calling the GET /_admin/deployment/id endpoint. Querying the deployment directly confirms that you are generating a license key for the intended instance, rather than trusting whatever is recorded in the inventory file:

   # User credentials (-u username:password)
   curl -u root: http://localhost:8529/_admin/deployment/id
   
   # JWT session token
   curl -H "Authorization: Bearer eyJh..." http://localhost:8529/_admin/deployment/id
   
   # Example result:
   # {"id":"6172616e-676f-4000-0000-05c958168340"}
   

4. Generate the license key using the deployment ID, the inventory file, and the license credentials. You can do this with the License Activation portal or with the Platform CLI tool — both produce an equivalent license key.

   Activation portal Platform CLI

   1. Open https://activate.license.arango.ai/ .
   2. Enter your License Client ID and License Client Secret.
   3. Choose how to identify the deployment:
      • Inventory (default): upload the inventory.json file into the upload area, or click to select it. Captures the full deployment shape and is recommended for offline / air-gapped environments.
      • Managed — Deployment ID only: enter the deployment ID directly. No inventory file is needed. Available only if Managed activation is enabled for your license — check your contract or with your Arango contact. If it is not enabled, the portal rejects the request and you should use Inventory mode instead.
   4. Optionally enable Custom TTL to override the default license duration. Accepts values like 24h, 168h, 7d, or 3600s.
   5. Click Activate and copy the generated license key.

   The activation portal is a convenient alternative for users who would otherwise run arangodb_operator_platform license generate. Inventory mode still requires the Platform CLI tool to produce the inventory file in the previous step; Managed mode skips that step entirely.

   Run the Platform CLI tool with the deployment ID, the inventory file, and the license credentials, and write the key to a file:

   arangodb_operator_platform license generate \
     --deployment.id "6172616e-676f-4000-0000-05c958168340" \
     --inventory inventory.json \
     --license.client.id "your-company" \
     --license.client.secret "00000000-0000-0000-0000-000000000000" \
     2> license_key.txt
   

Walkthrough: generate a key in a container

This walkthrough runs the Platform CLI tool inside a container alongside a throwaway ArangoDB instance — a convenient self-contained setup for trying out the license generation process. The same license inventory and license generate commands work in any environment that can reach an ArangoDB endpoint over the network, so you can also run them against a local install, a virtual machine, or an existing production host.

The commands below use the docker CLI. podman provides Docker-compatible CLI commands, so the same invocations work by substituting podman for docker; for other container runtimes, use the equivalent commands.

1. Download the Platform CLI tool

On the host machine, download the Platform CLI tool arangodb_operator_platform from https://github.com/arangodb/kube-arangodb/releases .

Pick the build that matches the container image’s OS and CPU architecture. For a standard Linux x86-64 ArangoDB image, download arangodb_operator_platform_linux_amd64 and rename it to arangodb_operator_platform for convenience. Make it executable:

chmod +x ./arangodb_operator_platform

2. Start an ArangoDB container with the CLI tool mounted

Pull and run an ArangoDB Enterprise image, for example v3.12.8. Expose the default port 8529, set a root password, and bind-mount the Platform CLI binary into the container at /usr/local/bin/ so it is immediately available on PATH:

docker run -d --name arangodb \
  -p 8529:8529 \
  -e ARANGO_ROOT_PASSWORD="<root-password>" \
  -v "$(pwd)/arangodb_operator_platform:/usr/local/bin/arangodb_operator_platform:ro" \
  arangodb/enterprise:3.12.8

Verify the instance is up with cURL:

curl -u "root:<root-password>" http://localhost:8529/_api/version

3. Open a shell inside the container

docker exec -it arangodb sh

All of the remaining steps run inside the container.

4. Generate the inventory file

Create an inventory.json file containing information about the ArangoDB deployment, including the deployment ID. Point the Platform CLI tool at the ArangoDB endpoint and supply the authentication options for your instance. The example below uses HTTP Basic Authentication with the root user:

arangodb_operator_platform license inventory \
  --arango.endpoint http://localhost:8529 \
  --arango.authentication Basic \
  --arango.basic.username root \
  --arango.basic.password "<root-password>" \
  inventory.json

If authentication is disabled on the ArangoDB instance, you can omit the --arango.authentication flag (the default is Disabled) as well as the credential flags. To use a JWT session token instead, pass --arango.authentication Token together with --arango.token "<jwt>".

5. Get the deployment ID

Query the ArangoDB deployment directly for its ID. This confirms that you are generating a license key for the deployment you expect, rather than trusting whatever is recorded in the inventory file:

curl -u "root:<root-password>" http://localhost:8529/_admin/deployment/id

The response looks like {"id":"6172616e-676f-4000-0000-05c958168340"}. Copy the id value for the next step.

6. Generate the license key

Generate the license key using the deployment ID, the inventory file, and the license credentials you received from Arango (a client ID and a client secret). You can do this with the License Activation portal (no extra tool needed) or with the Platform CLI tool inside the container. Both options produce an equivalent license key.

arangodb_operator_platform license generate \
  --deployment.id "<deployment-id>" \
  --inventory inventory.json \
  --license.client.id "<license-client-id>" \
  --license.client.secret "<license-client-secret>" \
  2> license_key.txt

docker cp arangodb:/license_key.txt ./license_key.txt

7. Apply the license key to ArangoDB

Copy the license string from license_key.txt and apply it to your ArangoDB deployment using any of the interfaces documented in the next section, Apply a license key — for example arangosh or the HTTP API.

Apply a license key

Standalone deployment

Apply a generated license key to a running ArangoDB deployment via one of the interfaces below.

db._setLicense("<license-string>");

curl -d '"<licenseString>"' -XPUT http://localhost:8529/_db/mydb/_admin/license

await db.setLicense('"<licenseString>"');

ctx := context.Background()
err := client.SetLicense(ctx, "<licenseString>", false)
if err != nil {
  fmt.Println(err)
}

err = db.set_license('"<licenseString>"')

Check the response whether the operation succeeded, for example:

{ "error": false, "code": 201 }

Please be careful to copy the exact license key string.

Kubernetes-managed deployment

In a Kubernetes-managed deployment — including air-gapped environments where the Kubernetes cluster cannot reach the Arango license service — you apply a license key by creating a Kubernetes secret and referencing it in the ArangoDeployment spec. The operator takes care of setting the license on the ArangoDB servers.

1. Generate the license key on an internet-connected system, as described in Generate a license key above. You need the deployment ID and an inventory file collected from the air-gapped ArangoDB instance. The License Activation portal  is the recommended way to generate the key.

2. On the cluster, create a Kubernetes secret with the generated license key. Substitute <license-string> with the key contents:

   kubectl create secret generic arango-license-key \
     --namespace arango \
     --from-literal=token-v2="<license-string>"
   

3. Reference the secret in the spec.license.secretName field of the ArangoDeployment:

   apiVersion: "database.arangodb.com/v1"
   kind: "ArangoDeployment"
   metadata:
     name: "deployment-example"
   spec:
     # ...
     license:
       secretName: arango-license-key
   

Because the generated license key has a limited validity, repeat the generation step and update the secret before the key expires. The operator applies the updated key on its next reconciliation cycle.

If the key expires before the secret is updated, the deployment enters read-only mode — reads keep working, but no data or data-definition changes are possible. See Check the license for the full set of status values.

See Contextual Data Platform — License Management for the full lifecycle, including how to choose between license credentials (online) and a generated license key (offline / air-gapped).

Check the license

At any point, you may check the current state of your license like so:

db._getLicense();

curl http://localhost:8529/_db/mydb/_admin/license

const license = await db.getLicense();

ctx := context.Background()
license, err := client.GetLicense(ctx)
if err != nil {
  fmt.Println(err)
} else {
  _ = license // Use license info here
}

license = db.license()

The server response is different for the Community Edition and the Enterprise Edition.

{
  "upgrading": false,
  "diskUsage": {
    "bytesUsed": 127316844,
    "bytesLimit": 107374182400,
    "limitReached": false,
    "secondsUntilReadOnly": 315569520,
    "secondsUntilShutDown": 315569520,
    "status": "good"
  }
}

{
  "upgrading": false,
  "features": {
    "expires": 1743568356
  },
  "hash": "95af ... 3de1",
  "license": "JD4E ... dnDw==",
  "version": 1,
  "status": "good"
}

Monitoring

In order to monitor the remaining validity of the license, the metric arangodb_license_expires is exposed by Coordinators and DB-Servers, see the Metrics API.

Managing Your License

Backups, restores, exports and imports and the license management do not interfere with each other. In other words, the license is not backed up and restored with any of the above mechanisms.

Make sure that you store your license in a safe place, and potentially the email with which you received it, should you require the license key to re-activate a deployment.