How Dify Enterprise license activation works and when you need it
If you have bought the self-hosted Enterprise edition, the enterprise features such as SSO, multiple workspaces, advanced security and professional support are switched on by activating your license inside your own cluster. Until that activation is in place, the deployment runs with the limits of the Community edition, so the platform team should treat activation as a gate in the rollout plan rather than a final administrative step. The Dify pricing page describes the self-hosted Community edition as free and limited to a single workspace, while the self-hosted Enterprise edition is custom priced and adds SSO, multiple workspaces, advanced security, a commercial license and professional support. Confirm the exact license terms, term length and entitlements in your written agreement, since those govern what the activated license permits.
Community and Enterprise also differ in where they run. The Dify deployment overview says the community edition runs anywhere Docker runs, while Dify Enterprise is deployed on Kubernetes for high availability with SSO and multi-workspace management. That means the activation step belongs to the Kubernetes release you operate, not to a single Docker Compose host. Before you start, confirm with your Dify contact which Enterprise version and chart your agreement covers, and make sure the platform team has the cluster access needed to restart the enterprise service once the license is in place.
The decision to make early is which activation path your environment allows. Clusters with outbound internet access can usually use the online method, while restricted or air-gapped networks need the offline method, which is driven by a code generated from the cluster's identifier. Settle this with your security team before the cluster is built, because the choice affects change windows, approval paths and who holds the license record. Ask your Dify contact to confirm the activation options available for your agreement and the information they need from your cluster.
Online activation versus offline activation compared
This table compares online and offline activation of a Dify Enterprise license across network needs, inputs, who performs each step and fit for restricted networks. Read each row as a question to settle with Dify or DeployOpen before the change window. Confirm the activation endpoints, renewal handling and namespace rules against your specific license terms and connectivity rules.
| Point | Online activation | Offline activation |
|---|---|---|
| Network requirement | The cluster must reach the activation service. Confirm the exact destinations and ports with Dify or DeployOpen. | The cluster needs no outbound route to the vendor. A separate workstation completes the exchange. |
| Input you provide | The License ID issued for your Dify Enterprise license. | The Cluster ID read from your cluster, then the returned offline code entered into the cluster. |
| Who performs the exchange | Your platform team enters the License ID and the cluster activates directly. Confirm whether DeployOpen performs this for you. | Your team exports the Cluster ID, a Dify or DeployOpen contact issues the code, and your team applies it. |
| Fit for regulated networks | Suits networks where outbound access to the vendor is approved, logged and limited to named destinations. | Suits networks where no outbound path is allowed and each transfer is approved under change control. |
| Fit for air-gapped networks | Usually unavailable, since the cluster cannot reach the activation service. Confirm this for your topology. | The usual choice, provided the Cluster ID can leave the network through an approved transfer step. |
| Namespace binding | The license is bound to the namespace where Enterprise runs. Confirm what a namespace change requires. | The code is tied to the Cluster ID and namespace. Confirm the effect of rebuilding or renaming either. |
| Restart after activation | Restart the enterprise service after activation and confirm which workloads Dify requires you to restart. | Restart the enterprise service after applying the code, using the same procedure as the online method. |
| Renewal and re-activation | Confirm how renewals, license changes and cluster upgrades are re-activated over the network. | Each renewal or Cluster ID change may need a new code. Confirm the request lead time and the process. |
| Records to keep | Keep the activation request, the change ticket and the namespace and version that were activated. | Keep the Cluster ID, the returned code, the transfer approval and the restart record together. |
Why the license is bound to a namespace
The license is tied to the Kubernetes namespace where Dify Enterprise runs, so the namespace is part of the activation, not just a deployment detail. Moving the installation to a different namespace, deleting and recreating the namespace, or standing up a second Dify Enterprise installation can leave the activation invalid for the new location. Before you activate, decide the namespace name, the cluster it lives in and the environment it serves, and treat those three values as fixed unless you have agreed a change with the vendor.
Record the namespace name, the Cluster ID used to generate an offline code, the License ID and the date of activation in your change records. Keep the same record for every environment you run, including staging, because an activation that works in one namespace does not carry over to another. If your team uses GitOps or Helm releases, make sure the namespace is declared explicitly in the deployment values so a rebuild does not silently pick a new name.
Confirm the following with the vendor before go-live: whether a license can be rebound to a new or renamed namespace, who performs the rebinding, whether a reissued license or a new offline code is required, how long that process takes, and whether it carries any cost. Also ask whether a disaster recovery cluster may hold a standby activation and under what terms. Get the answers in writing and attach them to the change record, since they determine how much freedom your team has when it rebuilds the platform.
Activating the license step by step
This sequence confirms the platform prerequisites, binds the license to the right namespace, activates it online or offline, and restarts the enterprise service. The result is an Enterprise instance where licensed features such as SSO and multiple workspaces are visible and working.
Confirm Kubernetes, Helm and dependency versions
The platform engineer checks the target cluster against the Dify Enterprise resources checklist, which requires Kubernetes 1.24 or later and Helm 3.14 or later, along with PostgreSQL 14 or later, Redis 6 or later, a Qdrant vector database and S3-compatible or cloud object storage. Record the output of the cluster and Helm version commands in the change record. This step is done when every component meets or exceeds the listed minimum and the versions are documented for the activation ticket.
Record the Cluster ID and target namespace
The platform engineer locates the Cluster ID the enterprise deployment reports and writes it down with the namespace where Dify Enterprise will run. Because the license is bound to a namespace, changing the namespace later can require a new activation, so confirm the namespace name with the business owner before continuing. Confirm with the Enterprise documentation where the Cluster ID is displayed for your release. This step is done when the Cluster ID and namespace are recorded together and approved.
Choose online or offline activation
The team decides whether the cluster can reach the activation service. Clusters with outbound access can use the License ID flow. Air-gapped or restricted networks use an offline code generated from the Cluster ID, so the Cluster ID from the previous step must be sent to the license issuer before the code is returned. Confirm the exact offline request process with your license contact, since the steps depend on your agreement. This step is done when the activation method is written down and the team knows who issues the code.
Apply the License ID or offline code
The platform engineer enters the License ID or offline code through the configuration method documented for your Enterprise release, either as Helm values in the deployment or through the console activation flow. Store the value in your secrets management process rather than in a plain values file committed to source control. The step is done when the configuration change is applied and the deployment reports no license validation errors in its logs.
Restart the enterprise service
The platform engineer restarts the enterprise service so it reads the new license state, then waits for the pods to return to ready status. Check the pod status and the service logs for the activation result, and note any warning that mentions the license, the namespace or the Cluster ID. The step is done when all enterprise pods are running and ready and the logs show a successful license check.
Verify enterprise features appear
An administrator signs in to the console and checks that enterprise features are present. Enterprise editions include SSO and multiple workspaces, so confirm that the SSO settings and the workspace management options are visible to an administrator account. If either is missing, compare the namespace and Cluster ID against the record from earlier steps before retrying the activation. The step is done when the features appear and a test administrator can use them.
Record the activation evidence
The platform engineer saves the activation record with the Cluster ID, namespace, versions, activation method, restart time and the screenshots or log excerpts that show the features working. Store the record with your change documentation so auditors and future administrators can trace how the license was bound. The step is done when the evidence is stored in your change system and linked to the deployment ticket.
Protecting the license and the activation path
The License ID, the offline code and the Cluster ID together determine which Dify Enterprise installation a license works for, so they deserve the same care as other deployment credentials. The cards below cover who handles that material, who can change the namespace or Helm release, how secrets stay out of activation records, and how restarts are controlled.
Treat the License ID as sensitive
The License ID identifies your commercial entitlement to Dify Enterprise, so it should not be pasted into tickets, chat channels, shared runbooks or screenshots. Keep it in your organization's approved secrets store and record which team owns it. Before activation, confirm with DeployOpen or Dify which contact can reissue it if it is exposed, and how long that takes.
Limit who can request offline codes
An offline code is generated from the Cluster ID, so the person requesting it should be a named platform owner who can prove the cluster identity. Record the Cluster ID, the requester, the date and the target namespace in your change record. Check that the code matches the cluster it was issued for before it is entered, because a code tied to the wrong cluster will fail or activate the wrong installation.
Restrict namespace and Helm release changes
The license is bound to a namespace, so changing the namespace or renaming the Helm release can invalidate activation or force a new one. Use Kubernetes RBAC to limit who can modify the release, its values and the namespace object to a small platform group. Require a reviewed pull request or change ticket for any change to those values.
Keep SECRET_KEY out of activation records
Activation notes often capture the full values file or environment output, which can include SECRET_KEY, database passwords and object storage credentials. Redact those values before any record is saved. Remember that changing SECRET_KEY after deployment logs out all users, so it must be generated once, stored in your secrets manager and never regenerated during a license action.
Put the enterprise restart under change control
Restarting the enterprise service after activation interrupts running apps and sessions. Schedule the restart in a maintenance window, confirm a recent backup, and write down the rollback step. After the restart, verify the license status in the admin view and check that workflows still respond, then close the change with the evidence attached.
What a restart of the enterprise service changes
Treat the restart as a planned change window, not a background task. Restarting the enterprise service after activation recycles the pods that serve the console and the API, so active user sessions drop, workflow runs in progress can fail, and calls from external applications may return errors until the service is back. Choose a window outside peak use, tell workspace owners and the teams that call Dify APIs in advance, and name one person who can approve a rollback. Confirm with your Dify Enterprise contact how long a restart takes in your cluster, because this guide does not supply a duration and your node count and storage will affect it.
After the restart, confirm the pods return healthy before anyone signs off. Check that every enterprise pod reaches the ready state, that restart counts stop increasing, and that the console loads and a test application can be opened. Then check the license status in the admin view. It should show the expected license, the namespace it is bound to, and the enterprise features it covers, such as SSO and multiple workspaces. If the status still shows the old state, compare the namespace in the license with the namespace where the enterprise release runs, and read the logs of the service that validates the license before you retry the activation.
Take a backup before the restart, following the pattern the Dify Docker Compose documentation recommends before every upgrade. Dify's Docker Compose guide advises a backup before each change and a check of the environment template afterward. Apply the same discipline here: back up the metadata database, the object storage that holds uploaded files, and the Helm values and secrets that configure the enterprise release, including the SECRET_KEY value. Keep SECRET_KEY unchanged, because changing it after deployment logs out all users. Store the backup somewhere the restart cannot affect, and confirm with your Dify Enterprise contact whether your release needs any further steps before the restart.
Limits to confirm before activation
Activation depends on conditions in your own environment as much as on the license itself. The cards below cover the platform minimums, network paths, commercial terms and identifiers that should be settled before you request or enter a license.
Kubernetes and Helm minimums
Dify Enterprise is deployed on Kubernetes, and the resources checklist sets a minimum of Kubernetes 1.24 or later and Helm 3.14 or later. Confirm that the cluster you will activate is at or above these versions, and that the Helm client used for installs and upgrades meets the same floor. A cluster that falls below the minimum should be upgraded before activation, not after, so the enterprise service restarts only once.
Network path for online activation
Online activation requires the cluster to reach the activation service from the namespace where Dify Enterprise runs. Confirm the egress rules, proxy settings and any firewall or DNS policy that applies to that namespace. If your cluster sits in a restricted network, plan for the offline path instead and confirm with your Dify account contact which method is supported for your deployment.
License terms with your account contact
The Enterprise license is a commercial agreement that covers the edition, scope and term of your deployment. Confirm with your Dify account contact which entitlements the License ID or offline code carries, how renewals are issued, and what happens when the license expires. Ask for the terms in writing before scheduling a production activation window.
Whether the namespace can change
The license is bound to a namespace, so the namespace you choose at install time becomes part of the license identity. Ask your Dify contact whether a license can be reissued for a different namespace after issue, what the process and lead time are, and whether a cluster rebuild or a rename would require a new license. Record the namespace name in your change log before requesting the license.
Cluster identifier for offline codes
For offline activation, the offline code is generated from the Cluster ID of the target cluster. Confirm which identifier your deployment exposes, who on your team can retrieve it, and that the value is captured from the same cluster that will run the enterprise service. A Cluster ID taken from a rebuilt or cloned cluster will not match the one the license was prepared for.
Restart window and rollback
Activating a license requires restarting the enterprise service, so schedule a maintenance window that covers user sessions and running workflows. Confirm the restart procedure in a staging environment first, keep a backup of the current deployment values, and agree with your Dify contact what to do if the license does not validate after restart.
Questions teams ask about Dify Enterprise license activation
How much does it cost to activate a Dify Enterprise license?
Dify lists the self-hosted Enterprise edition as custom priced, so the license fee comes from a written quote, and the Dify pricing page gives no figure for it. Most of the effort sits in preparation around the activation steps: a platform engineer to plan the namespace and network rules, someone with cluster rights to run activation and the restart, and a change window. Preparation is one-time, while the license term and renewal recur. Ask the quote to split the license fee from any implementation hours for activation, and to state what a re-activation after a cluster rebuild would cost. Costs rise when the cluster is not ready when the license arrives.
How long does it take to switch on a Dify Enterprise license?
No activation duration is published in the sources available to us, so treat any number as unconfirmed until Dify or a partner gives it in writing. The steps are short once the cluster is ready. Elapsed time depends on how long it takes to get cluster access, agree the namespace, open the network paths your activation method needs, and schedule the restart of the enterprise service. Plan for a service interruption while it restarts. Online activation with a License ID mostly waits on approvals. Offline activation adds the exchange of the Cluster ID and the returned code between teams. Ask for the step list and the restart impact in writing before you book a change window.
Can our own engineers activate a Dify Enterprise license without an outside partner?
Yes, if your engineers have Kubernetes access to the Dify Enterprise namespace and can run Helm and read service logs. The Enterprise resources checklist sets the baseline you need first: Kubernetes 1.24 or later, Helm 3.14 or later, PostgreSQL 14 or later, Redis 6 or later, a Qdrant vector database and S3-compatible or cloud object storage. If those components already run and have owners, activation is a contained task for one platform engineer with a second reviewer. Outside help makes sense when the cluster is new, the namespace plan touches several teams, or no one on staff has operated a Helm-based enterprise service before. DeployOpen plans, implements and documents this work under a written, fixed scope.
What must our team provide before Dify Enterprise license activation starts?
The license needs five inputs from your side:
- Cluster access, including rights to view the namespace, read the enterprise service status and restart it.
- A namespace plan that names the namespace the license will bind to and the team that owns it.
- Network rules that allow the activation path you choose, whether online with a License ID or offline from the Cluster ID.
- A named approver for the restart window and a rollback contact who can decide during the change.
- The Cluster ID for offline activation, plus sign-off to share it outside your network through an approved channel.
Confirm each item with Dify's enterprise documentation for your version before the change window is booked, since activation requirements can change between releases.
Why is a Dify Enterprise license tied to a namespace?
The license is bound to the namespace it was activated in, so choose the namespace before you activate. Moving Dify to another namespace later, renaming it, or rebuilding the cluster can break that binding and force a new activation. Staging and production layouts make this more important, because each environment needs its own planned namespace. Confirm with Dify whether a binding can move, what a re-activation requires, and whether a single license covers more than one namespace. Record the answer in your platform decision log so that future changes to naming or cluster layout go through a licensing check.
Can Dify Enterprise license activation work in an air-gapped network?
Offline activation uses a code generated from the Cluster ID, so it suits clusters that cannot reach the activation service. Take the Cluster ID out through an approved channel, receive the code, enter it in the enterprise configuration, and restart the service. Confirm with Dify the exact steps, the code format, whether codes expire, and whether a code is tied to one cluster. Air-gapped sites should also plan how images and the Helm chart reach the cluster, because the license step does not deliver them. Test the full path in a non-production namespace first, if your Dify contract includes one.
What usually goes wrong during Dify Enterprise license activation?
The most common failures are a wrong namespace at activation, a mistyped License ID, a Cluster ID copied from the wrong cluster, and a restart that never happens after the license is entered. Check the namespace first, since the license binds to it. Then compare the License ID or Cluster ID character by character and confirm the code was issued for this cluster. After the restart, check the enterprise service logs for license status. If the status still shows the license as inactive, do not repeat activation blindly. Collect the namespace, Cluster ID and exact error text, then send them to Dify support or your implementation partner.
How DeployOpen scopes Dify Enterprise activation
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, including Dify. For Dify Enterprise license activation, we treat the license as one step in a wider change: confirming the target cluster, choosing the online or offline path, and restarting the enterprise service in a controlled way.
How we scope
- Engagements are fixed-scope, with the activation path, target namespace and deliverables agreed in writing before work starts.
- We confirm whether your clusters can reach the activation service or whether the offline Cluster ID process applies.
- We record who receives the License ID, who holds the license file and who approves the restart window.
How we build
- We prepare the Kubernetes deployment so the enterprise service runs in the namespace the license is bound to.
- We activate the license through the online path or the offline code flow, then verify the entitlement in the console.
- We test a controlled restart of the enterprise service and confirm that workspaces and SSO still work afterwards.
How we hand over
- You receive a written runbook covering activation steps, the namespace binding and the restart procedure.
- You receive a record of the License ID handling, the Cluster ID used for offline activation and the storage location of the license.
- Your team walks through the runbook with us so the next renewal or cluster rebuild can be run in-house.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers for renewals, cluster changes and version updates.
- We review license-related changes before any upgrade, including checks of your Dify Enterprise release notes.
- We can re-run activation checks after cluster migrations, node replacements or namespace changes in your environment.
