Embedding Dify web apps in websites and portals

The main drivers are how many apps and portals are involved, how much user context must pass from the host site into Dify, and how many identity and security decisions the embed forces. A single chat bubble on one public site is a small job. Embedding several apps in an authenticated portal, with inputs prefilled from the signed-in user and a tightened Content Security Policy, adds design, testing and review work on both sides. Costs split into the implementation effort (planning, configuration, host page changes, testing) and the recurring work of keeping the embed working through Dify upgrades and portal releases. Ask any partner for a quote that lists these items separately, and for which items are one-time and which recur. Community and Enterprise licensing are separate decisions: the Dify pricing page lists the self-hosted Community edition as free and limited to a single workspace, and the self-hosted Enterprise edition as custom priced, adding SSO and multiple workspaces.

No duration figure is supplied for this work, so treat any number you hear as a claim to verify. The time is set by a few factors: whether the Dify app is already published and stable, whether the portal team has a staging environment that matches production, whether the identity team has settled how signed-in users will reach the app, and how many browsers, portal templates and content security rules must be tested. A pilot with one app, anonymous visitors and a standard iframe moves quickly. A pilot that needs signed-in users, prefilled inputs and approval from security review takes longer because each dependency waits on another team. Ask for a written plan with named milestones and the dependencies that could stall them.

The portal team must supply the pages that will host the embed, the template or CMS details that control headers and scripts, a staging copy of the site, and an owner who can approve changes to the Content Security Policy. The identity team must confirm how users sign in to the portal, which identity provider issues their tokens, and whether those users should reach Dify as anonymous visitors, as members of a workspace, or as external users. Dify Enterprise documents separate SSO scopes for workspace access and web app access, so a decision on which scope applies is needed before build starts. Dify's own secrets and key settings, such as SECRET_KEY, are operated by the platform team, so that owner should be included early.

Yes, if the team has someone who knows the Dify deployment, the portal platform and browser security well enough to change headers and host scripts safely. The Dify docs cover publishing and embedding, so a capable internal team can build a basic embed alone. The gaps usually appear in three places: testing across browsers and portal templates, reviewing how the Content Security Policy and cookie behavior affect the embed, and confirming that identity and user context are passed without exposing data. A partner is most useful when those areas are unclear or when the embed must be ready for an audit. Whichever route you take, ask for the scope in writing and check it covers testing and handover, not only configuration.

Browsers block frames, scripts and connections that the page's Content Security Policy does not allow, so an embed that worked in staging can fail silently in production. The usual fixes involve allowing the Dify web app origin in frame and connection directives, and checking that the portal does not forbid framing by its own response headers. Each change widens what the page may load, so each one needs a security review. Cookie settings also matter: when the Dify app and the portal sit on different sites, browsers may refuse third-party cookies that the session depends on. Test in every browser your users run, and keep a record of every directive you changed.

Each Dify upgrade can change the embed, so it should be part of the upgrade plan rather than an afterthought. Dify ships minor releases roughly monthly, based on the release dates in the GitHub releases page, and the Docker Compose docs advise a backup before every upgrade and a check of .env.example for new variables. Re-test the embed after each upgrade, because web app behavior, script locations, sandboxing and authentication between services can change. Keep the portal's Content Security Policy and embed snippet under version control so a regression can be traced and reverted. Confirm the upgrade path and any breaking changes against the release notes for the target version before scheduling it.

Choose by how much control the portal needs over layout, user context and the look of the app. A chat bubble is the fastest to add and gives the least control over placement and data passed in. An iframe keeps the app isolated from the host page and is easier to reason about for security, but it limits styling and makes cross-frame communication harder. A custom embed built on the published app's endpoints gives the most control over inputs and identity, and adds the most code to maintain and test. Write down the user context you need to pass, then pick the lowest-effort option that carries it safely. Confirm the options your Dify version supports in the Dify docs for web apps before you decide.

Embedding a published app on your own site does not by itself change the license terms, but the Dify Open Source License restricts operating the source code as a multi-tenant environment without written authorization and restricts removing logo or copyright information from the console. Those terms should be read in full with your legal team before you expose apps to outside users. Licensing decisions also affect what identity features you can use: the Dify pricing page lists SSO and multiple workspaces under the self-hosted Enterprise edition, not the Community edition. Confirm these points with Dify and your counsel before the embed goes live.