Open Innovation Grant

The Open Innovation Grant (OIG) provides free commercial use of Directus for entities with less than $5M in annual revenue and fewer than 50 employees. Eligibility is assessed based on the legal entities whose representatives log into the Directus Studio. Full terms are set out in the grant usage agreement.

Apply for the Open Innovation Grant to receive a license key. Once you have it, follow Managing Your License to apply it to your instance.

This page covers the questions that come up most often once you have an OIG license: what it includes, how its activations work across environments, and how it behaves in CI pipelines and database restores.

Haven't Received Your Key?

License keys are delivered by email. If your key has not arrived, check your spam or junk folder, as grant emails are often filtered there.

What's Included

An OIG license is not a trial or a reduced edition. It unlocks the entitlement-gated features most projects need, including custom access policies and SSO, with no caps specific to the grant. A small number of capabilities are reserved for higher commercial tiers.

The main thing to plan around is the number of activations, covered below.

Activations

Each OIG license key includes 5 activations. An activation binds the key to one instance at its PUBLIC_URL on first use, and that binding authenticates all later revalidation requests for the instance. See Activations and project bindings for the full mechanics and the deactivation flow.

Five activations are intended to cover the distinct environments of a single project, such as local, dev, staging, and production, with one spare. Because a license binds to your PUBLIC_URL and project database rather than to a container or IP address, you do not consume a separate activation for each replica.

Multiple Projects and Agencies

A single key and its 5 activations are meant for one project across its environments. If you build and host Directus for multiple clients or run several distinct projects, apply for a separate OIG key per project. Each key receives its own 5 activations, so a project's environments never compete with another project's for slots.

Replicas and Horizontal Scaling

A license binds to your project and PUBLIC_URL, not to a container, IP address, or instance identity. In a horizontally scaled deployment, every replica shares the same project database and the same PUBLIC_URL, so a single key and a single activation cover the entire cluster rather than each container.

Set the license through the LICENSE_KEY environment variable at the service or task level so that every replica inherits the same value automatically. New containers added by autoscaling pick up the license on start with no manual setup or per-container retrieval. See Replicas and Horizontal Scaling for more detail.

Continuous Integration and Ephemeral Environments

CI pipelines are the most common way to exhaust an OIG license's activations. The problem comes from fully ephemeral setups: if a pipeline run tears down both Directus and its database and recreates them from scratch, each run generates a new project and a new binding, consuming an activation every time. Because old activations are not released when the throwaway instance disappears, five runs exhaust the limit and later runs fail with an activation limit error.

To validate licensed features (such as SSO and OIDC) in CI without burning through activations, use one of the following approaches:

• Reuse the same database and PUBLIC_URL across runs. If runs share a persistent project database and a constant PUBLIC_URL, they reuse a single binding and consume only one activation in total. Persist the database between runs rather than recreating it each time.
• Validate against a stable instance. Point feature tests at a long-lived dev or staging instance that holds its own activation, instead of spinning up a fresh licensed instance per run.
• Run ephemeral pipelines on the core tier. Leave the license out of throwaway runs entirely and reserve licensed-feature validation for a persistent environment. The core tier runs without a license and without consuming activations.
• Use a commercial license sized to your workload if none of the above fit your pipeline.

Restoring Database Dumps

Dumping a database and restoring it elsewhere (for example, copying production into a local or dev environment) is a common workflow, and how it interacts with your license depends entirely on the PUBLIC_URL of the instance you restore into.

A dump carries the project's license binding with it. What happens on the next boot is:

• Restoring into the same environment (same project and same PUBLIC_URL, such as recovering a backup of production back onto production) revalidates the existing binding. It does not create a new activation, so restoring a backup into its own environment is free.
• Restoring into a different environment (a different PUBLIC_URL, such as production into local) does not match the original binding. The instance still starts as licensed and keeps running while its current validation holds, but because it cannot revalidate under the new URL, it eventually falls back to the core tier once that validation expires.

If you want a long-lived local or secondary copy running at the full tier, dedicate one of your 5 activations to it and activate the license under that environment's own PUBLIC_URL. Always restore into the same PUBLIC_URL for that environment. Changing the URL on each restore registers a new binding every time and consumes additional activations.

When activating a license on a local machine, make sure Directus runs in production mode. A license will not activate while NODE_ENV is set to development. See Activation in Development Mode for details.

Next Steps

• Licensing overview for license keys, statuses, and the deactivation flow.
• Telemetry for what usage data Directus collects.
• PUBLIC_URL configuration for setting the value that licensing binds to.