Dify web app settings and branding on Community: what you can change
If you have published a Dify web app and need it to look like your product or department, you can change the user-facing text on the app page yourself, through app configuration. The app's title, description and input placeholders are settings, and they belong to your team to set. Replacing the Dify logo or altering copyright information in the Dify console is a different matter: the Dify Open Source License forbids removing or modifying the logo or copyright information in the console, so branding work has to stay inside what the license allows. Read the LICENSE file before you plan any change to the console itself.
Most teams need this only in two situations. The first is a cosmetic task: a department wants its own app name, a short description that explains who the tool is for, and placeholder text that tells users what to type into each input field. Those changes are low risk, reversible and can be made by an app editor, so they do not need a partner. The second situation is a brand decision that touches the console or the logo. Before anyone proposes that, confirm with your legal or licensing contact whether the change is permitted for your edition and deployment, and get the answer in writing. Do not assume that a supported logo option exists on the edition you run, because the set of options differs between Community and Enterprise and can change between releases.
Before publishing changes, check three things. Confirm that the title and description match what the published link shows to external users, since web app users and console users see different surfaces. Test every input placeholder with a real request so that users can tell what each field expects. Record the setting values in your change log or DSL export, because the release process for moving them between instances is covered elsewhere on this page's sibling topics. Finally, confirm the current release notes for your Dify version, since UI behavior for these settings can change between minor releases, which arrive roughly monthly.
Which web app settings fit which goals
This table compares each configurable element of a published Dify web app against the goal it serves, the risk it carries and the team that should own it. Read each row as a decision: keep the wording you control, and confirm logo options against the current docs and the license for your edition before you plan a rebrand. The main takeaway is that text settings are low-risk and owned by the product team, while console branding is constrained by the license and should be decided once, early.
| Setting | Goal it serves | Risk it carries | Who should own it |
|---|---|---|---|
| App title | Tells users which assistant they are talking to and matches your internal naming | Title may reveal Dify or a vendor name, or clash with another app's name in the same workspace | Product owner, with brand review |
| App description | Sets expectations on scope, data handling and what the app will not answer | Overpromising capability or stating data rules the workflow does not enforce | Product owner with the compliance lead for data statements |
| Opening text | Starts the conversation with the right context and guides first questions | Wording that invites users to share sensitive data the app is not approved to handle | Product owner and the security lead for approved data types |
| Input field labels | Collect the variables the workflow needs in a consistent way | Labels that are ambiguous change the prompts and retrieval results downstream | App builder, reviewed against the workflow variables |
| Input field placeholders | Show users an example of the expected format or value | Example values that look like real data or a real identifier can be copied into the app | App builder, using clearly fictional examples |
| Logo or icon replacement | Presents your brand on the published web app | Supported options depend on edition and license; the console logo must not be removed or modified on Community without confirming the terms | Brand owner, with legal review of the current LICENSE and docs |
| Console branding | Makes the internal builder environment recognizable to staff | The license forbids removing or modifying logo and copyright information in the console, so changes may breach terms | Legal or licensing owner, decided once for the whole instance |
| Settings changes after publishing | Lets teams correct wording without rebuilding the app | Edits can go live without review and can differ from the version that was tested | Release owner, with changes logged in version notes |
How to set web app titles, descriptions and placeholders on Community
This sequence takes a published Dify app from draft text changes to a verified live web app for end users. It also confirms that the console branding was left untouched, which the Dify Open Source License requires. Each step ends with a check you can record.
Open the app in the console
An operator with edit rights signs in to the Dify console, opens the target workspace, and selects the app. Confirm the workspace name and app name match the instance you intend to change, since Community is limited to a single workspace and staging and production are usually separate instances. Note the currently published version and its date so you have a rollback reference. The step is done when you can see the app's current draft and its published state.
Edit the web app title and description
In the app's web app settings, update the title and description that end users see on the published page. Menu names and field locations can differ between Dify versions, so confirm them against the App management documentation for your release before you edit. Keep the text short and free of internal project names, since it appears to anyone who opens the link. The step is done when the draft shows the new text and the save completes without an error.
Update input placeholders and labels
Edit the placeholder text and labels for each user input field so end users know what to enter. Review each input type, such as text, paragraph or select, because placeholder support can vary by field type. Check that the placeholder wording does not prompt users to enter credentials, personal data or secrets. The step is done when every input in the draft has the intended placeholder and label, and no field was added or removed by accident.
Confirm console branding is unchanged
Before publishing, check that the console logo, copyright information and other console branding still match the original Dify release. The Dify Open Source License forbids removing or modifying the logo or copyright information in the console, and logo replacement in the web app depends on the edition you run. Ask your Dify vendor or review the pricing page if you are unsure whether your edition supports a logo change. The step is done when you have confirmed the console is unmodified and recorded that check.
Publish the draft to the live app
Publish the draft so the new title, description and placeholders become part of the live version. Confirm the publish action completed and that the published version now shows the new text in the app's details. Record the version name or timestamp in your change log, along with the operator who published it. The step is done when the published state changes and the version reference is written down.
Test the live URL in a private session
Open the published web app URL in a private browser window that is not signed in to the Dify console, so you see what an end user sees. Check that the title, description, input labels and placeholders render as intended, with no leftover draft text or broken layout. Also confirm that the console logo or copyright was not altered on the page. The step is done when the live page matches the approved text in a clean session.
Verify the published version matches the approved change
Compare the approved change list with the live page, field by field, and confirm nothing was published that was not reviewed. If your deployment exposes version history for the app, confirm that the published version corresponds to the one you recorded in the previous step. If a mismatch appears, restore the previous published version and repeat the edit. The step is done when the change list, the live page and the version record agree.
What the Dify Open Source License allows for the console
The Dify Open Source License is a modified Apache License 2.0, and it contains two restrictions that matter most when a team plans to brand Dify. The first forbids removing or modifying the logo or copyright information in the Dify console. The second forbids using the source code to operate a multi-tenant environment, where one tenant is one workspace, without written authorization. Logo replacement inside the console is therefore not a settings question. It is a licensing question, and it should be answered before any build or design work starts. Note that the console restriction covers the console itself, while the published web app is the surface your end users see, so the two should be assessed separately.
The Community edition is free and limited to a single workspace, according to Dify's pricing page. That limit and the multi-tenant restriction work together. A team that wants one brand per customer, business unit or partner, with each one running in its own workspace on a shared instance, is operating a multi-tenant environment and needs written authorization from Dify before going further. Running separate Community instances per brand avoids the multi-tenant question on a single instance, but it multiplies upgrades, backups and credentials, so the cost of that choice should be modeled in the plan. Pricing and feature details for the Enterprise edition, including multiple workspaces and a commercial license, come from Dify directly, not from this page.
Before any change beyond the published web app, have your legal or licensing contact read the Dify LICENSE file directly, and do not rely on a summary, including this one. Ask Dify for written terms covering the specific change, such as removing console branding, hosting several brands on one instance, or offering Dify-based services to third parties. Record the answer, the date and the version of the license it applies to in your change record. Re-check the license when you upgrade, because the terms are part of the source you are deploying, and treat any answer you do not have in writing as not granted.
Security and operational risks in web app customization
Changing a published web app's text, placeholders and branding touches what end users see, how they fill in inputs and what your organization is seen to publish. The cards below cover the failure modes that show up most often, and the approval and tracking habits that keep copy changes from drifting away from the app definition.
Exposed internal wording
Titles, descriptions and descriptions of inputs are shown to every visitor of the web app. Internal project names, system prompt fragments, vendor names or notes about data sources can end up in that copy if a builder pastes working text into a public field. Before publishing, read every title, description and placeholder as an outsider would, and confirm that no internal labels or hints about your backend appear.
Sensitive placeholder defaults
Input placeholders and default values are visible to users before they type anything. A default that contains a sample account number, an internal hostname or a realistic-looking customer record can leak data or teach users to submit sensitive content. Use generic examples, and check that default values in input fields do not carry data copied from test runs.
Changed input expectations
Renaming an input field, changing its placeholder format or altering which fields are required changes how end users supply data. Callers that send values by variable name, and users who have learned the old wording, can submit incomplete or misrouted input without any error. Treat input label and format edits as interface changes that need a note to any integrations and a test run with sample values.
Copyright and logo edits
The Dify Open Source License forbids removing or modifying the logo or copyright information in the Dify console. Web app branding is a separate surface, so a team that edits the console header, footer or about text while customizing an app can cross that line by accident. Keep a baseline of console branding, and check it after each upgrade or template change.
Unreviewed copy changes
Web app text is often edited directly in the console by whoever is working on the app, with no second reader. Define who may change titles, descriptions and placeholders, who approves them, and whether legal, brand or security review is needed for public-facing or regulated apps. Record the approver in the change note so the decision can be traced later.
Drift from the DSL export
Console edits to web app settings do not automatically appear in the YAML DSL file you keep in version control, so the repository can describe a different app than the one running. When you promote or restore an app, the stored copy may silently overwrite live copy. Export the DSL after each approved change, commit it with a version name, and compare the exported file against production before release.
How web app settings relate to the app's DSL and versions
Web app settings such as the title, description, input placeholders and logo belong to the app's published configuration, not to the instance it runs on. That means they travel with the app's state and its version history, and they are only as portable as the export that carries them. The Dify docs say a DSL export includes app configuration, workflow nodes, model parameters, prompts and knowledge base connections, so a well-scoped DSL is the record you should treat as the source of truth for what the end user sees. Before you rely on it, confirm with the current version of the app management documentation exactly which web app presentation fields are written into the DSL on your version, because some display details may be handled separately from the workflow itself.
The same export boundary sets limits you need to plan around. A DSL file does not carry third-party API keys, knowledge base content or usage logs, so a copy of an app imported into a second Community instance will prompt for its own model credentials and will not bring the source instance's documents with it. For copy changes, this means a title or placeholder edit can be tested on a staging instance by importing the DSL, then reviewing the rendered web app there before the same text is applied to production. Check that the imported app still points at the knowledge bases and model providers you expect, because a title that looks right can sit on top of a broken retrieval step.
Restoring a prior state is the harder case. Rolling back the DSL restores configuration and prompts, but it does not restore knowledge base content, logs or credentials that changed since the export. Keep a dated DSL export alongside a version name and release note for every published change, and take a database backup before any restore, because the Docker Compose upgrade guidance also recommends a backup before every change. Test the restore on a non-production instance first, then confirm the published web app shows the expected branding and that the API and web app users still resolve correctly.
Questions teams ask before changing Dify web app branding
Can our team change Dify web app branding without outside help?
Yes, many teams can make basic changes themselves, since titles, descriptions and input placeholders are set inside the app configuration in the Dify console. The harder part is deciding what to change, checking it against the license and keeping each instance consistent. Teams with a platform engineer, a product owner and a reviewer for public-facing text usually handle the work in-house. Outside help becomes useful when you need a repeatable process across many apps, languages and instances, or a written review of the license position before you publish.
What drives the effort of a Dify branding change?
Effort depends on a few drivers that you can count before any work starts:
- The number of published apps and how many have customized text
- The number of languages each app must support
- How many people must approve copy, logos and colors before release
- How deep the branding goes, from text edits to a full visual redesign
Each driver adds review cycles and testing across every app and instance. Ask any partner to size the work from a written list of apps and approvals rather than from a general estimate.
Is replacing the Dify logo allowed on the Community edition?
The license does not allow removing or modifying the logo or copyright information in the Dify console. The Dify Open Source License is a modified Apache License 2.0 and it sets that restriction, so you should read the LICENSE file in the langgenius/dify repository before you plan any logo work. Logo replacement on supported editions is a different matter and depends on the edition you run. Confirm the exact position for your edition and your use with Dify or with your legal team before changing anything visible in the console.
What should we prepare before asking for a branding quote?
A quote is only as accurate as the written scope behind it. Prepare these items before you ask:
- A list of every published app and each instance it runs on
- Your brand guidelines, including approved names, tone, colors and any logo files you are permitted to use
- The languages required for each app
- A named approver for copy and visual changes
- A copy of the license review, or a note from your legal team on the position you have confirmed
With these in hand, a partner can define deliverables and timelines in writing.
Does moving to Dify Enterprise change how we can brand web apps?
Enterprise changes the commercial and administrative picture more than the basic text settings. The Dify pricing page says the self-hosted Enterprise edition is custom priced and adds SSO, multiple workspaces, advanced security, a commercial license and professional support. Those additions matter for branding because the license terms and the supported editions differ. Before you decide, ask Dify directly which branding and logo options your Enterprise agreement includes, and get the answer in writing.
How long does a Dify web app branding project take?
Duration depends on scope, and no supplied figure applies to a general branding project. The main variables are the number of apps, the number of languages, how many approval rounds your organization requires and whether a license question has to be resolved first. A small set of text changes on one instance can move quickly, while a multi-app, multi-language rollout with legal review takes longer. Ask for a timeline that lists each phase, its owner and the approvals it depends on.
What operational steps keep branding consistent across instances?
Treat branding text as configuration you can review and reproduce. Keep a written record of each app's title, description and input placeholders, and store the approved versions in version control. When you export an app as a YAML DSL file, the export includes app configuration and prompts, so the text travels with the app. Re-check the console after every Dify upgrade, because upgrade notes and the .env.example file can change how settings behave. Assign one owner to confirm each release on every instance.
What a DeployOpen engagement covers for web app delivery
DeployOpen scopes web app settings and branding work in writing before any change is made. The first step is an inventory of every published app on the instance, recording which apps are exposed as web apps, who uses them, what the title, description and input placeholders currently say, and whether any app has been copied or exported from another instance. That inventory becomes the baseline the change record is built on. The written scope then names the apps in and out of the change, the copy and placeholder text to be approved, the browsers and devices to be tested, and the logo treatment, if any, that the client's edition and license permit.
The copy and placeholder review is usually the largest source of effort in this kind of work, because end users read these strings as instructions and they often differ from what the app's prompts expect. Testing covers the published web app across the browsers and screen sizes your users actually use, checking that titles render in tab bars and bookmarks, that placeholders are readable, and that changes made in the console do not alter the behavior of any linked API call. Before the logo or any console branding is touched, the license review is handed to the client's counsel, since the Dify Open Source License prohibits removing or modifying the logo or copyright information in the console. DeployOpen prepares the technical facts for that review but does not give legal advice.
Most engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts, and a quote follows from that written scope. Ask for the quote to separate the inventory, copy review, testing, license review support and handover, and to state which items recur if you later add apps. The handover is a change record listing each app, the before and after text, the test results, the license decision and the instance and version it was applied to. Keep that record with your DSL exports, because the next upgrade or promotion will need it to confirm nothing was overwritten.
How DeployOpen scopes and supports Dify web app delivery
DeployOpen treats web app settings and branding on Community as a scoped piece of delivery work, not a styling exercise. We agree in writing which app titles, descriptions, input placeholders and branding items change, then build, test, document and hand them over inside your own infrastructure.
How we scope
- Inventory every published web app and record its current title, description and input placeholder text.
- Confirm which branding items you want changed and check each one against the Dify Open Source License logo rule.
- Agree the scope in writing before work starts, since engagements are fixed-scope with deliverables and timelines set out.
How we build
- Apply app-level text changes in the console and record each change in the exported DSL for the affected apps.
- Test the published web app for each changed string, including how input placeholders render for each input type.
- Confirm that any logo or copyright change stays within what the license and your Dify edition permit before release.
How we hand over
- Deliver a settings register listing each app, the changed fields, the approved wording and the date of change.
- Document the license position for the console, including which branding items were left untouched and why.
- Walk your team through repeating the changes on a new instance so the settings survive a rebuild or a version upgrade.
How we support
- Recheck web app settings after each Dify minor release, since releases arrive roughly monthly and may change console behavior.
- Offer ongoing support and continuous testing as a retainer if your team wants a regular review of published apps.
- Ask us to confirm any edition-specific branding question with the Dify pricing and license documents before you commit.
