Dify Community edition login options without SSO: when they are enough
Community sign-in can protect a self-hosted Dify instance, but only as far as the console access and account creation controls allow. A team that has not bought Enterprise SSO can rely on built-in email and password accounts, optional one-time email codes, GitHub and Google OAuth buttons, invite-only sign-up, and a reverse proxy authentication layer in front of the console. Community is free and limited to a single workspace, so every login decision is really about who can reach the console, how accounts are created, and who can see the apps inside. Exact availability of each path depends on the running version, so confirm which options your release exposes in the Dify docs before you write the access policy.
Start by listing the people who need the console and the people who only need to use published apps, because the two groups call for different controls. Built-in accounts suit a small, known group of builders. OAuth buttons add a dependency on GitHub or Google account lifecycle, so decide whether your staff already use those identities and who removes an account when someone leaves. Disable public registration if the setting is available in your version, and confirm the sign-up and invitation behavior in the Dify docs: Deploy with Docker Compose and Dify docs: FAQs before relying on it.
Record the chosen model as an access decision with an owner, and test it. Create a test account outside your allow list, attempt sign-up, attempt login from an unapproved network, and confirm that a removed user loses console access. If you place a reverse proxy authentication layer in front of Dify, verify that the proxy protects every route, including API paths that accept service keys, and that the SECRET_KEY value in your environment is set and stored securely, since changing it logs out all users. Community does not offer SCIM provisioning or per-app access levels, so plan for manual offboarding and periodic account reviews, and move to Enterprise SSO when those controls become a requirement.
Which Community sign-in option fits which situation
This table compares the sign-in options a Community instance can use without Enterprise SSO, with what each protects, what it depends on and where it falls short of directory-driven control. Treat each row as a question to confirm against the Dify docs for the exact version you deploy, because login options and their settings change between releases. The main takeaway is that every Community option keeps accounts inside the instance, so the choice governs who can sign in, not how access is managed across the organization.
| Option | What it protects and who manages accounts | What it depends on | What it lacks compared with Enterprise SSO |
|---|---|---|---|
| Email and password | Local accounts that admins create, reset and remove in the console | The metadata database and SECRET_KEY, which signs session cookies and JWTs | No central directory, SCIM or group mapping; offboarding is manual |
| One-time email codes | Sign-in proves control of a mailbox; accounts still live in the instance | Working outbound mail delivery configured for the instance | A mail outage blocks sign-in; no group mapping or directory-driven deprovisioning |
| GitHub OAuth button | Sign-in through a GitHub identity; access follows that account | A GitHub OAuth app you register, with its client credentials stored in the instance | Confirm whether organization membership can restrict sign-in for your version |
| Google OAuth button | Sign-in through a Google account, suited to teams already on Google accounts | A Google OAuth client you register with redirect URLs for your domain | Confirm whether sign-in can be limited to your own domain for your version |
| Invite-only account creation | Stops open self-registration so only invited people receive accounts | The instance sign-up setting, the invitation flow and mail delivery for invites | Limits who joins, but does not assign roles or groups from an identity source |
| Reverse proxy authentication layer | A gate in front of Dify that decides who reaches the console and apps | A proxy or gateway with its own identity integration, plus TLS and header handling | Dify keeps its own accounts; confirm whether API and web app paths are covered |
| Enterprise SSO (reference) | Workspace and web app sign-in through OpenID Connect, SAML or OAuth2 | An Enterprise license and an identity provider such as Entra ID, Okta or Keycloak | Reference point: the pricing page lists SSO and multiple workspaces as Enterprise features |
Choosing sign-in by audience: staff, builders and reviewers
Staff who use Dify day to day from a shared instance make up the largest group on a Community deployment, and every one of them shares the same workspace. Email and password accounts are the simplest path for a small group. Where the organization already runs its own sign-in, a reverse proxy authentication layer in front of Dify lets staff sign in once, so Dify only receives requests from people who passed that gate.
- Usual login path: Email and password for a small team, or a reverse proxy authentication layer when the organization wants its existing sign-in to control access.
- Provision by hand: Create or invite each account, assign the role each person needs, and record who approved the access and why.
- Session and secret rules: Set SECRET_KEY before first use, because changing it after deployment logs out all users. Confirm password strength and session length in the current docs.
- Shared accounts: Do not let several staff share one login, because the audit trail then names nobody.
- Offboarding: Remove the account in Dify and in the proxy or identity layer on the same day the person leaves, and confirm whether existing sessions end at once.
Confirm invitation, deactivation and account deletion behavior in the current environment variable reference before you write the offboarding procedure.
Builders create workflows, knowledge bases and agents, and they publish them, so their accounts carry the most change power in the instance. Because the Community edition is limited to a single workspace, every builder shares one tenant with every other account. The login method matters less than who can edit and who can publish. GitHub or Google buttons can reduce password handling for developers, but they add an external account that the organization does not manage unless it checks how those accounts are created.
- Usual login path: Email and password, or a one-time email code, for builders with mailboxes the organization controls. Use GitHub or Google buttons only where the team accepts those accounts as identities.
- Provision by hand: Assign builder roles deliberately, keep the publisher list short, and record which apps and knowledge bases each builder owns.
- Credential handling: Keep provider API keys out of shared notes and chat. Check how model credentials are stored before granting edit access.
- Export discipline: DSL exports omit third-party API keys and knowledge base content, so keep a separate record of where those secrets and documents live.
- Offboarding: Transfer ownership of apps and knowledge bases before removing a builder, then remove the login and any OAuth link the person used.
Check in the current docs how app ownership transfers and whether an OAuth-linked account can be unlinked before a builder leaves.
Reviewers and testers need access for a limited period, often to check a prompt change or run acceptance tests before a release. The Community edition does not provide a time-limited access setting in the facts available to this page, so the team must plan the end date outside the account itself. Invite-only settings matter most for this group because they keep the sign-up path closed to anyone without an invitation.
- Usual login path: One-time email codes for named reviewers, combined with invite-only settings so no one creates an account on their own.
- Provision by hand: Record a removal date when the request is approved, along with the apps and data the reviewer needs to reach.
- Test data: Use a non-production instance or sanitized sample data, so reviewers do not see live knowledge base content.
- Shared logins: Avoid passing one tester login through chat or tickets, since removing it then affects everyone who used it.
- Offboarding: Remove the account on the planned end date, then confirm that no pending invitation or email code still accepts the address.
Confirm whether invite-only mode blocks self-registration completely and whether an invitation expires in the current Dify docs before you rely on either behavior.
How to set up Community sign-in on a Docker Compose instance
This sequence takes a self-hosted Dify Community instance from a bare Docker host to a tested sign-in path. The operator confirms prerequisites, protects the secret that signs sessions, sets the account policy, adds any OAuth buttons, places TLS and a reverse proxy in front, and proves that sign-in, invitation and removal behave as intended.
Confirm the host meets Docker Compose prerequisites
The platform team checks the host before any login setting is touched. The Docker Compose deployment needs at least 2 CPU cores, 4 GB of RAM and Docker Compose 2.24.0 or later. The stack starts the api, worker, web and plugin daemon services along with PostgreSQL, Redis, Weaviate, Nginx, a code sandbox and an SSRF proxy, so the host must have room for all of them. Run the Compose version command on the host and compare the output with the required version. The step is complete when the version is 2.24.0 or later, the host has at least the minimum cores and memory, and the stack starts without errors on a first run.
Set and protect the SECRET_KEY before first login
The operator sets a unique, long, random SECRET_KEY in the environment file before the first user signs in. Dify uses this value to sign session cookies and JWTs and to encrypt OAuth credentials, and changing it after deployment logs out all users. Store the file with restricted read permissions and keep it out of version control and shared chat channels. Confirm the key name and handling in the Dify environment variable reference for your version. The step is complete when the default placeholder is gone, the key is recorded in your secrets store, and the environment file is readable only by the account that runs the stack.
Decide the account creation and invitation policy
The security lead and the Dify owner agree in writing who may create an account, whether anyone can self-register, and who may send invitations. The Community edition is limited to a single workspace, so every account lands in the same tenant and the policy applies to everyone. Look up the sign-up and invitation settings in the environment reference for your exact version and record the setting names and chosen values in the change record. The step is complete when the written policy is approved and a test on the instance matches it, meaning an uninvited address cannot create an account if the policy forbids it.
Register OAuth apps only where the policy needs them
If the policy allows GitHub or Google sign-in buttons, the operator registers an OAuth application with each provider. The callback URL must match the public HTTPS hostname that users will reach, so decide that hostname now and reuse it in the next step. Place the client ID and client secret in the environment file, then restart the stack. Confirm the exact callback path and any required scopes in the docs for your version. The step is complete when the provider consent screen appears during a test login, the redirect returns to the instance, and the client secret does not appear in container logs or the web console.
Put TLS and a reverse proxy in front
The operator places a reverse proxy in front of the Dify Nginx service and terminates TLS there with a valid certificate for the public hostname. If the organization wants an extra authentication gate, the proxy layer enforces it before traffic reaches Dify, and the team confirms which headers and session behavior the proxy must pass through so Dify's own login still works. Block direct access to Dify's published ports from outside the network, so the proxy is the only entry point. The step is complete when HTTP redirects to HTTPS, the certificate chain validates from a clean client, and a direct request to the internal port from outside the network fails.
Test sign-in on every enabled method
The tester signs in with each method the policy enables, using a test account for each one. For email and password, confirm the login succeeds and that a wrong password is refused. For each OAuth button, confirm the provider round trip completes and the account maps to the expected Dify user. Repeat the sign-in from a private browser session to confirm the login is not depending on a cached session. The step is complete when every enabled method signs in, every disabled method is absent from the login page, and the results are recorded with the date, version and tester name.
Test invitation and account removal
The Dify owner invites a test user from the workspace member settings, and the tester accepts the invitation from a separate browser profile. Confirm the new user reaches only the workspace and apps they were granted. Then the owner removes that member, and the tester attempts to sign in again and reloads any open browser session. Confirm in the docs for your version how existing sessions end after removal. Community edition has no SSO or SCIM provisioning, so removal is a manual step, and Enterprise SSO is the separate route for centralized provisioning according to the pricing page. The step is complete when the removed account cannot sign in and no longer appears in the member list.
Security considerations for a Community login setup
A Community sign-in setup puts the session and credential controls in your hands, not in an identity provider's. The cards below cover the settings that protect sessions, OAuth credentials, the proxy layer and the admin surface, plus the upgrade review. Verify each control against your own environment before you rely on it.
Protect SECRET_KEY
The SECRET_KEY variable signs session cookies and JWTs and encrypts OAuth credentials. Generate a strong value once, store it in your secrets manager and keep it out of shared compose files. Changing it after deployment logs out every user, so treat rotation as a planned maintenance event and confirm the procedure in your own environment before you need it.
Keep OAuth secrets out of Git
GitHub and Google OAuth client secrets belong in the .env file or a secrets store on the host, not in committed compose overrides, screenshots or ticket attachments. Restrict read access to the host, check that backups of the configuration are encrypted, and confirm that your repository scanning covers the Dify deployment directory.
Set TLS and proxy header trust
Terminate TLS at a proxy you control and confirm that the reverse proxy overwrites forwarded headers from the client rather than passing them through. If Dify trusts spoofed forwarding headers, access logs and any IP-based controls become unreliable. Test the chain with a request that sends a fake forwarding header and check what reaches the application.
Close public sign-up
For an internal instance, disable open registration and use invitations so that only people you named can create accounts. Review who holds workspace admin rights after each onboarding batch. Confirm the current invite-only setting in the Dify docs for your release, because the option name and location have changed across versions.
Restrict admin console reach
Limit network access to the Dify console and admin paths to a management network or VPN, and keep the public web app paths separate. Put the reverse proxy authentication layer in front of administrative routes, log every admin sign-in, and review the list of administrators on a fixed schedule. Test that a direct request to the backend ports is refused.
Review 1.16.1 security changes
Dify 1.16.1 release notes describe agent sandbox network isolation through a Squid proxy, token-based API authentication between services and sandboxed Jinja2 template rendering. Before you upgrade, confirm these behaviors in a staging copy, check whether your agents depend on outbound paths the isolation now restricts, and back up before the change. Minor releases arrive roughly monthly, so schedule this review into each upgrade cycle.
Where Community login stops and Enterprise SSO starts
The boundary is set by edition, not by configuration. The self-hosted Community edition is 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, according to the Dify pricing page. For a regulated team, that means the login options in this section can make sign-in safer, but they do not give you a centrally managed identity provider, workspace separation or user provisioning. Those capabilities sit in Enterprise, and no Community setting replaces them.
The practical gaps are most visible in access reviews. With one workspace, every builder, publisher and administrator shares the same boundary, so you cannot separate production apps from experimental ones by workspace. Accounts are created and removed inside Dify itself, which means leavers must be deprovisioned by hand and there is no directory-driven group mapping to audit. Confirm with your own security and compliance owners which of these gaps your control objectives can tolerate before you commit to a Community design, and record the decision in your system documentation.
The Enterprise price is not published. It comes from a written quote based on the deployment you describe, so ask Dify for the scope, the SSO protocols and identity providers included, the support terms and whether the license covers your deployment model. Because the pricing page can change, check it for current Community and Enterprise terms before you plan budgets or a migration path, and treat any figure you find there as the starting point for your own quote rather than a commitment.
Limits to confirm before you rely on Community sign-in
Community sign-in is simpler than Enterprise SSO, and its limits are set by the version you run and the configuration you choose. The six checks below cover what the running version exposes, how access is restricted, and what changes on upgrade. DeployOpen does not assume any of these capabilities until you confirm them in the docs or on a test instance.
Login methods the running version exposes
Email and password, one-time email codes, and GitHub or Google OAuth buttons are not guaranteed on every build or every configuration. Check the login page of a test instance running the exact version you plan to deploy, and confirm which OAuth providers need client credentials in your environment. Record the result with the version number so the evidence matches what you run.
Invite-only and sign-up settings
Confirm whether public sign-up is blocked by a configuration key, by a console setting, or by both, and which one takes precedence. Test it from a private browser session with an unknown email address. An open sign-up path on an internet-facing instance is the most common way an unplanned user gets in.
Password policy and session lifetime
Find out which controls for password complexity, lockout, reset and session expiry are configurable, and which are fixed. Session lifetime also depends on the SECRET_KEY value, because changing it after deployment logs out all users. Document the defaults you accepted so an auditor can see the controls in place.
Identity passed by the reverse proxy
If an authentication layer sits in front of Dify, confirm whether it can pass a verified identity to the application in a header or cookie that Dify actually reads. Many proxies can block access but cannot tell Dify who the user is, so the console still asks for its own login. Test that a user removed in the proxy also loses access to Dify.
Authentication changes during upgrades
Each release can add, rename or remove authentication variables. Read the upgrade guide for the target version, compare your .env file with .env.example, and back up before you upgrade. Minor releases arrive roughly monthly, so plan a retest of login behavior after every upgrade rather than assuming settings carried over.
Community license fit for the intended use
The Community edition is free and limited to a single workspace, and the Dify Open Source License restricts operating the source code as a multi-tenant environment without written authorization. Have counsel confirm that your planned use, including external users or several business units, stays inside those terms. If it does not, the Enterprise edition is the route to evaluate.
Questions teams ask before choosing Community sign-in
Can Community sign-in meet our internal access policy without buying Enterprise?
It can meet some policies, but not all of them. The Community edition gives you email and password sign-in, one-time email codes, GitHub and Google OAuth buttons, and an invite-only setting, so a policy that requires named accounts, a single sign-on source of truth or automatic removal of leavers will need work outside Dify. The Dify pricing page lists SSO, multiple workspaces and advanced security as part of the self-hosted Enterprise edition, and the Enterprise SSO documentation describes the protocols and scopes that Community does not provide. Map each clause of your policy to a control before deciding. Where a clause needs a central identity provider, a reverse proxy authentication layer may cover it, but you should confirm with your security team that it satisfies the policy wording.
What does a Community login setup cost in effort, and who does the work?
The Community edition is free to download and run, so the cost is labor and infrastructure. Your team, or a partner, will configure environment variables, create OAuth applications with GitHub or Google, set up mail delivery for one-time codes, and decide whether a reverse proxy layer is needed. Some costs recur: patching the proxy, rotating OAuth secrets, reviewing the user list and keeping up with monthly minor releases described on the Dify releases page. Ask any quote to separate one-time configuration from ongoing operation, and to name who holds the admin account and who signs off on access changes.
How long does a basic Community login setup and test take?
The duration depends on how many of these pieces you already have: a working Docker Compose host, a DNS name, a valid TLS certificate, a mail sender and an identity owner who can approve access rules. If those exist, the sign-in settings themselves are a small part of the work. If you must build a reverse proxy layer, register OAuth applications, and test password reset and invitation flows across real user accounts, expect more time, mostly spent waiting on approvals and certificates rather than on configuration. Ask any partner to show the test cases it will run, and confirm your own change-control window before the schedule is agreed.
What must we provide before a Community sign-in setup can start?
Prepare these items before work begins:
- A stable domain name for the Dify console and any published web apps, with DNS control.
- TLS certificates for that name, issued by a CA your users trust.
- OAuth applications in GitHub or Google if you plan to offer those buttons, with the callback URLs set to your domain.
- A mail sender and credentials for one-time email codes and invitations.
- A named identity contact who approves the user list and access rules.
- Hosting that meets the Docker Compose requirements in the self-hosting docs, which list at least 2 CPU cores, 4 GB of RAM and Docker Compose 2.24.0 or later.
Confirm each item with the owner who controls it, since many delays come from access requests rather than from the software.
Can our team set up Community sign-in alone?
A team comfortable with Docker, reverse proxies and environment files can usually complete the basic configuration alone, provided it has someone who understands the identity rules. The harder parts are judgment calls: which login methods to enable, whether invite-only is enough for your user population, and whether a proxy layer is an acceptable control for your auditors. Also decide who holds the SECRET_KEY, since the environment reference notes that changing it after deployment logs out all users. Teams without a second reviewer often find the testing and documentation are the parts they skip, so plan for both.
What does a fixed-scope partner engagement for Community sign-in include?
A fixed-scope engagement usually covers the agreed items in writing: a review of your access policy against the available login methods, configuration of the chosen methods, a reverse proxy authentication layer if you require one, mail and TLS setup, a test plan with recorded results, and handover documentation for your operators. It may also cover a short review of the settings against your security baseline. It does not include an audit report or certification, which come from independent assessors. Ask the partner to list what is excluded, such as future user onboarding, and what happens if your policy changes after delivery.
Does a reverse proxy login layer replace Enterprise SSO?
It can cover the sign-in step in front of Dify, but it does not replace the Enterprise capabilities. A proxy that enforces your identity provider can gate who reaches the console, yet Dify still manages its own accounts, roles and web app access levels, and those do not come from your directory automatically. Leavers may still hold Dify accounts unless removed separately, and SCIM-based provisioning is an Enterprise feature. Test both paths: a user blocked at the proxy, and a user who was removed from the directory but still has a Dify account. Record the results so the gap is visible to your risk owner.
How DeployOpen works on this
DeployOpen scopes Dify Community sign-in as a written, fixed-scope piece of work inside your own infrastructure. We choose the login method, configure the instance and place any reverse proxy authentication layer in front, then document and hand over the result so your team can run it.
How we scope
- Your written scope states which sign-in methods are enabled, including email and password, one-time codes or GitHub and Google buttons.
- We confirm whether invite-only registration is required and who approves new accounts before any configuration starts.
- Ask for the scope to name the reverse proxy product, the hostnames involved and who owns the proxy configuration.
How we build
- We set the sign-in options in the Community instance and test each one against the exact Dify version you run.
- Where a proxy authentication layer is in front, we test that direct access to the Dify services is blocked and that headers cannot be spoofed.
- We check the SECRET_KEY handling and session behavior, since changing that key after deployment logs out all users.
How we hand over
- You receive a configuration record listing each enabled login method, its settings and the owner of each external OAuth application.
- We document the steps to add or remove an account, reset a password and rotate OAuth credentials in your environment.
- Handover includes a test checklist your team can rerun after each upgrade, using the upgrade guide for the target version.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, so sign-in checks can follow each Dify release.
- Retainer scope for sign-in should be agreed in writing, including who reviews proxy and OAuth changes before they go live.
- Ask us to confirm which Community sign-in behavior changes between releases before you schedule an upgrade.
