Dify Enterprise branding and white labeling

Dify Enterprise branding and white labeling: when a team needs it and what the license allows

Dify Enterprise has branding settings for the console and web apps, and the Community license forbids removing or modifying the logo or copyright information in the Dify console and front-end without authorization. Dify is an LLM application development platform for building AI workflows, RAG pipelines and agents through a visual interface, with a prompt IDE, support for many model providers, LLMOps monitoring and backend-as-a-service APIs. Branding matters most when staff are asked to trust an internal portal that looks like a vendor tool, when a customer-facing web app must carry the organization's name, or when procurement and security reviewers expect a sanctioned internal service with clear ownership.

The license question should be settled before the rollout plan is written, not after users have been onboarded. The Dify Open Source License is a modified Apache License 2.0 that also forbids using the source code to operate a multi-tenant environment without written authorization, where one tenant is one workspace. The Community edition is limited to a single workspace, so an organization that wants several business units, its own logo and a branded customer-facing app is describing the Enterprise edition, which the pricing page lists as custom priced. Ask the vendor to confirm in writing which branding changes are authorized under your license terms, including the logo, product name, favicon and copyright notices, and whether the authorization covers the web apps your customers see.

Plan the branding work as a release item with an owner. Confirm which console and web app surfaces the Enterprise branding settings cover in the version you will run, because the release notes in the Dify releases on GitHub page change between minor versions roughly monthly. Keep a record of the authorization, the settings applied and the version they were applied on, and retest them after each upgrade, since an upgrade can reset or alter front-end assets. Treat the record as part of your license evidence, not as a cosmetic task.

Which branding approach fits Community, Enterprise and custom front-ends

Community self-hosting is the simplest case. The Dify Open Source License forbids removing or modifying the logo or copyright information in the Dify console and front end without authorization, so a team that wants Dify to look like its own product must accept that the Dify identity stays visible or request permission from Dify. The Dify LICENSE sets these terms, and the Community edition is limited to a single workspace, which keeps the decision narrow.

What changes: Nothing in the console. Your team can still set its own app names, descriptions and prompts, which are content, separate from the Dify interface.
Who approves: Your legal or license owner reads the license terms. Any change to the logo or copyright requires written authorization from Dify.
Trade-off: No Enterprise contract is needed to start, but internal users see Dify branding throughout the console.
Scope limit: A single workspace means you cannot split brands across business units on this edition.

Confirm the current license text and the pricing page before you assume the Community terms cover your rollout.

Branding configuration options and when each fits

This table compares the branding surfaces a team may change in Dify Enterprise, from the console to web apps, sign-in pages and documentation. Read each row for when the change fits, who should approve it, and what to confirm in the Enterprise branding documentation before committing. The main takeaway is that the Community license restricts changes to the Dify console logo and copyright information, so Enterprise terms should be checked before any console change.

Branding surface	When it fits	Who must approve	What to confirm before committing
Console logo and name	Staff use the Dify console daily and the organization wants its own identity on internal tooling.	Legal or licensing owner, with the platform owner who holds the Enterprise agreement.	Whether your Enterprise terms permit the change, which fields the branding settings expose, and how logo files must be supplied.
Web app presentation	Business users reach published apps and want them to look like part of an internal or customer-facing product.	Application owner and brand or communications owner for any external audience.	Which web app elements can be altered, whether changes apply to all apps or per workspace, and how changes behave after upgrades.
Sign-in and access pages	Users reach Dify through SSO and the organization wants a recognizable entry point for staff or partners.	Identity owner, with security review because sign-in pages carry trust signals.	Whether the sign-in page is covered by branding settings, how it interacts with SSO scopes for workspace and web app access, and test steps in a staging environment.
Email notifications	Invitations, alerts or account messages should match the organization's sender identity.	Messaging or email administrator and the security team for sender domains.	Whether outbound email templates are configurable in the Enterprise branding documentation and how mail settings are supplied in your deployment.
Documentation and embedded content	Internal guides, help links or embedded app pages should point to your own knowledge base.	Documentation owner and, for public content, the brand or legal reviewer.	Whether help and support links can be replaced, and whether embedded app content or third-party links remain visible to users.
Copyright and license notices	Only changed when counsel has confirmed the notice text and the license permits it.	Legal counsel, since the Dify Open Source License restricts changes to logo and copyright information.	The exact license terms in your Enterprise agreement, and whether any notice must remain visible in the console or front end.

How to set up Enterprise branding without breaking the license

This sequence applies your organization's logo and name to Dify Enterprise while keeping the Dify logo and copyright notices that the license protects. It produces a tested, recorded configuration that you can verify, reapply and roll back after each upgrade.

Confirm license tier and written authorization
Start with the contract. Confirm that your organization holds a Dify Enterprise license covering the deployment, since the self-hosted Enterprise edition is the tier that adds a commercial license and professional support. Ask the vendor in writing which branding changes are permitted and whether any Dify logo or copyright notice must remain visible. The platform lead works with legal or procurement on this step. It is done when the written authorization and contract reference are filed in the change record.
Collect approved brand assets and wording
Gather the logo files, product name and any sign-in or footer wording from the brand owner, and obtain their written sign-off. Ask legal to list which Dify elements must stay visible, including the logo and copyright information that the license protects in the console and front end. Store the assets in a versioned folder so that every later check compares against the same files. It is done when the brand owner and legal have approved the asset list and the protected elements are written down.
Apply branding on a staging instance
Using the Dify Enterprise branding settings, apply the approved assets and wording to a staging instance first, leaving production unchanged. Confirm each field in the branding documentation for your release before entering values, because the available options depend on the version you run. Record every setting you change, the asset file names and the Dify version. It is done when the staging console shows the approved assets and the change record matches the values entered.
Verify console and web app appearance
Test the staging instance in each browser your users run, at desktop and narrow widths. Check the workspace console, a published web app and each sign-in flow. The Dify Enterprise SSO documentation separates scopes for workspace access and web app access, so test both paths. Confirm that the approved name and logo load without broken images and that no page mixes old and new branding. It is done when a test log lists each browser, page and result as a pass or fail.
Confirm copyright and license notices remain
Walk every surface that carries Dify identifiers, including the console, web app footers, help or about pages and sign-in screens. Compare each one against the protected elements list from the second step. If any Dify logo or copyright information was removed or altered, restore it or obtain written authorization from the vendor before rollout. It is done when legal signs the comparison and no protected element is missing or modified without authorization.
Roll out and record the change
Take a backup of the production instance before applying anything. The Dify Docker Compose guidance recommends a backup before every upgrade, and the same caution suits a branding change. Apply the settings you verified on staging, then repeat the appearance and notice checks on production. Save screenshots, asset file hashes, the Dify version, the approver and the date in the change log. Rollback note: if production branding fails, restore the backup or reapply the recorded settings from the staging record, and keep the failed configuration for review.
Recheck branding after each upgrade
Treat every upgrade as a branding risk. Dify publishes minor releases roughly monthly, and an upgrade can reset or overwrite custom files. Before upgrading, take a backup, then read the upgrade guide for the target version on the GitHub releases page. After upgrading, compare your settings against the .env.example file for new variables, and rerun the appearance and notice checks against the change log. Rollback note: if the upgrade guide or the checks show a regression, roll back to the previous version as the guide describes, then reapply the recorded settings.

Security and operational risks of changing the Dify interface

Changing the Dify console or web apps touches licensing, trust and upgrade work at the same time. The cards below cover the risks a reviewer should check before a logo or product name goes live, and who should own each check.

Unapproved third-party brand assets

A logo, favicon or font file uploaded for branding is content your organization now distributes to every user of the console and web apps. Check that each asset has a clear source and usage right, that your legal or brand team has approved it, and that no image copies another company's mark. Keep a record of the file, its origin and its approver so an asset can be traced and replaced if a rights question appears later.

Branding that hides license notices

The Dify Open Source License forbids removing or modifying the logo or copyright information in the Dify console and front end without authorization. Before you change any element, read the license text yourself and confirm with Dify whether your Enterprise agreement covers the change. Review the console footer, about pages and login screens after each change, because a copyright notice removed from one screen may still appear on another.

Spoofing by lookalike pages

A custom logo and name can make a Dify console or app look like an official Dify, vendor or internal IT page. Attackers can use that resemblance in phishing that asks users for credentials or model keys. Check that the custom name is clearly internal, that login pages are served from your own domain with TLS, and that users know where to report a page that looks wrong. Include the branded domain in your phishing awareness material.

Upgrades that overwrite branding

Dify ships minor releases roughly monthly, and each upgrade can replace front-end files or configuration that carried your branding. Before every upgrade, confirm where your branding settings are stored, whether they survive the target version, and how they are restored if they do not. Add a visual check of the console, login page and web apps to the upgrade test plan so a regression is found in staging, not by end users.

Who can edit branding

Branding changes alter what every user sees, so edit rights should be narrower than workspace administration. Confirm which admin roles can open the branding settings, whether changes are logged, and who approves an edit before it reaches production. Keep the list of editors short, review it when staff change roles, and tie edits to a named change ticket so a stray or malicious change can be traced to a person.

Questions buyers ask about Dify branding and white labeling

Can Community edition users remove Dify branding from the console?

No, not without authorization. The Dify Open Source License forbids removing or modifying the logo or copyright information in the Dify console and front-end without authorization from the licensor. It is a modified Apache License 2.0, so the general permissions of Apache 2.0 do not override this specific restriction. The same license also forbids using the source code to operate a multi-tenant environment, where one tenant is one workspace, without written authorization. Read the Dify LICENSE file yourself and have your legal team confirm how it applies to your deployment before you change any visual elements. Changing branding on a Community install without that authorization is a licensing question, not a configuration task.

What does Dify Enterprise change about branding?

Enterprise is the edition where branding is handled as a licensed, supported feature. The Dify pricing page describes the self-hosted Enterprise edition as custom priced and adds SSO, multiple workspaces, advanced security, a commercial license and professional support. Enterprise also provides branding settings in its admin documentation, which is the source to check for exactly which logo, name and console elements can be changed. Confirm with Dify which of those settings are included in your contract, because the commercial license is the instrument that decides what you are allowed to alter, not the console settings alone.

How much effort does Dify branding take?

The work is usually small in code but has to be tested on every surface your users see. The effort depends on how many surfaces need your identity: the admin console, the end-user web apps, email or notification text, and any embedded pages in your products. It also depends on how many languages, themes and environments you run, and whether your brand assets are finished and approved. Ask any partner to list each surface, the assets required for each, and the test steps per surface, then price those items in the written scope. Expect a quote to name these components rather than a single number.

Can our own team apply Dify branding without a partner?

Yes, if your team has the licensing approval and staff who can operate the deployment. Your engineers need access to the Enterprise settings, a change process for the Kubernetes or Docker Compose environment, and a way to verify the result after each upgrade. The harder part is ownership over time: each Dify minor release arrives roughly monthly, and branding settings can need checking after an upgrade. A partner can take on the scoped build, test and documentation work, while your team keeps the operating knowledge. Decide which of those roles you want to keep in-house before you request a quote.

How long does a Dify branding project take?

No duration is supplied for this work, so treat any timeline as unconfirmed until it is written into a scope. The main drivers are the number of surfaces, how complete your brand assets and approval chain are, whether your Enterprise licensing is already in place, and how many environments must be verified, including staging and production. Dify's releases arrive roughly monthly, so a plan should also allow time for re-checking branding after a version change. Ask for a schedule that lists each milestone, the client decisions it depends on, and the verification step that closes it.

What do we need to provide before a partner can start?

A partner needs written licensing status, a clear list of the surfaces to brand, and finished assets. Provide the Enterprise license arrangement or the Community license position your legal team has agreed, the target Dify version and deployment model, and access to a staging environment. Supply logos in the formats your brand team approves, the product name and wording, color and typography rules, and the names of the people who approve each change. Also name the copyright and attribution text that must remain in place, so the scope can keep required notices intact while applying your identity.

What drives the cost and effort of branding work

Branding looks like a small change, but its cost sits in the surrounding work: confirming what the license allows, preparing assets, testing every sign-in and browser path, and re-checking after each upgrade. Most of these items are one-time setup, while the re-checks and approvals recur for as long as the deployment runs.

License and authorization review

Before any change, someone must read the Dify Open Source License and confirm what it permits for your deployment. The license forbids removing or modifying the logo or copyright information in the Dify console and front end without authorization. Ask Dify Enterprise whether the branding settings you plan fall within your commercial license terms, and get that answer in writing. This is a one-time review for legal and procurement, though it should be repeated if your license terms change.

Asset and copy preparation

Logos, favicons, product names and any help text need to be produced in the formats the console and web apps accept, with light and dark variants checked against each background. Copy changes should be written once and reviewed for accuracy, since wording in sign-in screens and app headers is seen by external users. Budget for designers or brand owners to supply approved files, and for an engineer to verify placement. This work is one-time for the initial set and recurs when the brand changes.

Cross-browser and sign-in testing

Branded pages must be tested in each supported browser, at common screen sizes, and through every route users take to reach them. That includes Dify Enterprise SSO sign-in, workspace access and web app access, because each path renders the console and app pages separately. Document a short test script with expected results, so a tester can repeat it without guessing. Testing is needed at launch and again after any asset or configuration change.

Upgrade re-checks

Each Dify release can change console markup, front-end file names or configuration, so a branding setup that worked on one version may break on the next. Minor releases arrive roughly monthly, so plan a re-check into every upgrade window and compare the rendered console against your approved baseline. Keep a copy of the branding assets and settings under version control so a rollback can restore them. This check recurs with every upgrade you apply.

Change approval and governance

Decide who may request, approve and publish branding changes. Brand, legal and security owners usually need to sign off, because a logo or product name change can affect license compliance and external trust. Record each approved change with the version it was tested against, the approver and the date. A simple change log and named approvers prevent an unreviewed edit from reaching external web apps. This governance cost recurs for every change, so ask vendors how they will support the process.

How DeployOpen scopes and delivers Dify branding work

DeployOpen scopes branding work as a fixed-scope engagement inside your own infrastructure. DeployOpen is a Chainscore Labs company that implements self-hosted open-source platforms in the client's cloud accounts, data centers or air-gapped networks. For a Dify Enterprise branding engagement, the written scope should name the exact surfaces to change (the console, the web apps, login and email text where applicable), the Dify Enterprise version and deployment method, the people who approve assets, and the environments that receive the change, such as a staging copy before production. Deliverables and timelines are agreed in writing before work starts, so the scope document is the reference point if a change request arrives later.

DeployOpen does not issue license rulings or legal opinions. Whether a particular logo change, copyright notice or redistribution is permitted depends on your Dify license terms and your counsel's reading of them, and that decision stays with you. DeployOpen can implement the approved configuration, record exactly what was changed and check that the result matches the approved design. Before work starts, ask your legal team to confirm which branding changes your Dify Enterprise agreement permits, and make that confirmation a named input to the scope.

Every branding engagement should end with three handover items. The first is the documented branding configuration: the settings applied, the asset files and their versions, and where each one lives in the deployment. The second is verification notes, which record how each surface was checked in the console and web apps, including the browsers and user roles used. The third is an upgrade checklist, because Dify ships new releases roughly monthly and a later upgrade can change templates or reset overrides. Ongoing upgrade re-checks that confirm branding still renders after each release are available as a retainer, and that retainer should be priced in the same written scope as the initial work.

Dify Enterprise branding and white labeling