Dify sign-up policy: who can create an account on your instance
A self-hosted Dify Community instance lets people create accounts, join workspaces and sign in through several paths, and each path needs its own decision before the console is reachable beyond the team that deployed it. Sign-up, workspace creation, login methods and email changes are separate controls, so locking down one does not lock down the others. Teams need this policy before they expose the console to a wider network, a shared VPN or a corporate subnet, because the first person to reach the login page may otherwise be able to register an account. Confirm the current ALLOW_REGISTER behavior and related variables against the Dify environment variable reference for the exact version you run, since those settings change between releases.
The Community edition is limited to a single workspace, according to the Dify pricing page, so a Community instance has one place where invited people land. That shapes the design: you are deciding who may join one shared workspace, not how several business units are separated. Multi-workspace administration and the wider access model, including SSO for workspace and web app access, come with the Enterprise edition only. If you need named identity providers or separate access scopes, that is an Enterprise procurement question, and the Community settings described here are the controls available without it.
Before go-live, write down the answer to four questions: who may create an account, who may create or join workspaces, which login methods are allowed, and who may change an account's email address. Test each one from an account outside your team, using a fresh browser session. Also confirm that mail delivery works for invitations and email code login, because if outbound mail fails, invited users may be locked out or may fall back to methods you did not intend to allow. Record the result as evidence for your access review, and repeat the test after each upgrade, since release notes can change defaults.
Which account paths to close before inviting users
A Community instance can be reached by more routes than the sign-in page. Each path below lets a person create or reach an account, and each needs an explicit decision before you send the first invitation. Check every path in your own environment, because the supplied documentation describes the settings but your deployed values decide what a stranger can do.
Open self-registration
The ALLOW_REGISTER setting controls whether anyone who reaches the sign-up page can create an account on the instance. Confirm the effective value in your deployment before anything else, and test it from a browser with no session. If registration is open, a stranger can obtain a console login and then look for whatever your workspace settings expose to new members. Record the decision, the owner of the decision, and the test you ran to verify it.
Automatic workspace creation
A new account may be placed into a workspace of its own when it signs up, depending on how your version handles first login and workspace creation. Confirm with the environment reference and the release notes for your version whether this behavior applies to your instance. The policy question is whether a self-created workspace is acceptable at all, since it can hold apps, knowledge bases and model credentials that belong to your organization.
Email code login
Email code login lets a person sign in by receiving a one-time code at an address, so access depends on that mailbox being controlled by the right person. It also depends on working mail delivery, which means a misconfigured mail provider can block legitimate users or leave you without a tested recovery path. Decide whether invited users may use this method, and test code delivery and expiry with an invited test account before rollout.
Social OAuth buttons
Social sign-in buttons let people authenticate through an external identity provider and then reach the instance. Each enabled provider is a second front door, with its own account recovery, MFA and offboarding rules that your team does not control. Check which providers are enabled in your environment, remove those you cannot govern, and confirm that a disabled employee cannot keep access through a linked external account.
Changes to account email addresses
If users can change the email address on their account, a person who gains a session can redirect future sign-in codes or password resets to an address they control. Decide whether email changes are self-service, admin-only, or disabled, and confirm how the console handles them in your version. Verify the behavior with a test account, and check that an address change is recorded in your audit trail before you rely on it.
Configuration options and when each setting fits
This table compares the policy settings that decide who can create, sign in to and keep an account on a Community instance. For an invite-only instance, most rows should be closed or tightly limited, and the mail row is the one most likely to break sign-in if it is not tested. Confirm exact key names and accepted values in the Dify environment variable reference and against your running version before you change anything.
| Setting | Access it controls | Typical choice for invite-only | Dependency or risk |
|---|---|---|---|
| ALLOW_REGISTER | Whether anyone can create an account from the sign-up page | Disabled, so admins create accounts through invitation | Blocks self-service sign-up only. Confirm accepted values for your version. |
| Workspace auto-creation | Whether a new account automatically gets its own workspace | Off, so invited users join the workspace you manage | Community is limited to a single workspace, so stray workspaces create governance and licensing questions. |
| Email code login | Lets users sign in with a one-time code sent by email | Enable only after mail delivery is tested end to end | Depends on working mail delivery. If mail fails, users can be locked out. |
| Social OAuth sign-in buttons | Lets users sign in with an external provider account | Off unless the provider is an approved identity source | Each provider adds a trust relationship. OAuth credentials are encrypted with SECRET_KEY, so rotating that key affects them. |
| Account email changes | Lets users change the email address tied to their account | Restricted to admin-approved changes | The email identifies the person and receives sign-in and invitation mail, so a change can move access to a different mailbox. |
| Invitation email delivery | Sends the link that lets a named person set up an account | Used for every new user, with links sent only to the intended address | Depends on mail. Undelivered invitations stall onboarding, and a forwarded invitation link can be used by someone else. |
Setup sequence for an invite-only Community instance
This sequence brings a self-hosted Dify Community instance online with registration closed, mail working and only the login paths you need, so the first public URL never exposes an open sign-up form.
Confirm the version and environment file
The platform engineer records the Dify version being deployed and locates the environment file used by the Docker Compose deployment, following the Docker Compose quick start. Compare the file against the reference for the target version, since variable names and defaults change between releases. Record the version and the file's location in your change record. The step is done when the deployed version matches the one approved for the environment and every sign-up and login variable is present in the file.
Set the registration and workspace policy
Before the instance has a public address, the platform engineer sets the variables that govern open registration and workspace creation, using the environment variable reference as the authority for names and behavior. Set the registration variable to the closed value, and confirm how new accounts are attached to a workspace so that no account can create a new workspace without an invitation. Keep the file under version control or a reviewed change so the decision is traceable. The step is done when the values are written, reviewed and deployed, and the reviewer has signed off on the chosen behavior.
Configure outbound mail
Mail delivery is a dependency for invitations, email code login and account email changes, so the platform engineer configures the mail settings described in the environment reference and points them at an approved relay. Confirm the sender address, transport security and credentials with the mail team, and keep the credentials out of shared documents. Confirm that the plugin and worker services can reach the relay from inside the network. The step is done when the mail configuration is deployed and a test message reaches an internal mailbox.
Send and accept a test invitation
The administrator invites a test mailbox that the team controls from the workspace member settings. The invitee opens the link in a clean browser profile or private window, creates the account and joins the workspace. Confirm the invitation email arrives, the link expires or is single-use according to the behavior of your version, and the invitee lands in the expected workspace. The step is done when the invitation is delivered and accepted, and the test account appears in the member list with the intended role.
Create the administrator account
The platform engineer creates the owner account through the setup path the instance offers at first start, using a unique password stored in the approved password manager and a mailbox the organization controls. Enable any second factor the version supports, and record the account as the break-glass owner. Do not share the administrator login with the rest of the team. The step is done when the administrator signs in from a clean browser, can open workspace settings and the account is listed as the sole owner.
Test that unauthorized sign-up fails
From a clean browser with no session, the tester opens the sign-up page and any direct registration address, then attempts to create an account with a mailbox outside the approved domain and one inside it. Both attempts must fail or be redirected to a message that requires an invitation. Repeat the test with the email code login path if it is enabled. Record the request, the result and the version tested. The step is done when every unsolicited registration attempt is refused and the refusal is logged in the change record.
Disable login paths you do not need
The platform engineer reviews each login option the version exposes, including email code login, social OAuth buttons and account email change, and turns off any path the team has not approved, using the variables in the environment reference. Remove or hide social sign-in buttons whose identity provider is not in your sign-in standard, and confirm that email change is limited to the owner or administrator if the version allows it. Restart the services as the deployment guide requires. The step is done when each disabled path returns a refusal in a clean browser and each approved path still works.
Verify the final login from a clean browser
After all changes, a tester signs in as an invited user and as the administrator from clean browser profiles, then signs out and confirms the session ends. Repeat the sign-in after restarting the services to confirm the settings persisted. Keep this check in the runbook so that it runs again after every upgrade, because new releases can add variables or change defaults, and the upgrade guidance advises checking the example environment file for new variables. The step is done when both logins succeed, the sign-out is confirmed and the results are filed with the version and date.
Community policy settings versus Enterprise SSO
The Community edition is free and limited to a single workspace, so access control sits with your own team. Administrators decide whether strangers can create accounts, whether a new account receives a workspace automatically, and which sign-in methods appear on the login page. No external directory decides who is a member, so every joiner and leaver is handled inside Dify.
- Registration: Turn off open sign-up so that only invited users can create accounts. Confirm the exact setting name, such as
ALLOW_REGISTER, in the environment variable reference for your version before you change it. - Workspace creation: Check whether new accounts receive a workspace of their own, since that decision determines who can build and publish apps on the instance.
- Login methods: Review email code login and any social OAuth buttons, and disable the methods your team does not need.
- Mail delivery: Invitations, email code login and email changes all depend on working outbound mail, so test delivery before you rely on it.
- Email changes: Decide who may change an account's email address, because that address is the usual recovery path for the account.
After each change, confirm from a clean browser session that a non-invited address cannot register.
Dify Enterprise moves sign-in to an identity provider. According to the Dify pricing page, the self-hosted Enterprise edition is custom priced and adds SSO, multiple workspaces, advanced security, a commercial license and professional support. The Enterprise SSO documentation lists OpenID Connect, SAML and OAuth2, with identity providers such as Microsoft Entra ID, Okta and GitHub.
- Protocol support: Confirm that your identity provider can speak OpenID Connect, SAML or OAuth2 in the form Dify Enterprise expects.
- Named providers: The documented examples are Microsoft Entra ID, Okta and GitHub. Confirm the setup for your own provider with its vendor and with Dify.
- Two SSO scopes: Workspace access and web app access are configured separately, so decide who signs in to the console and who only uses published apps.
- Account lifecycle: Creating, disabling and removing accounts moves to the identity provider, so the local invitation process needs review against that model.
- Local configuration: Redirect URLs, claim mapping and group or role assignment still have to be set in Dify and in the provider.
Ask the Enterprise vendor to confirm how account changes made in your identity provider reach Dify before go-live.
The choice depends on how many workspaces you need and whether your identity team must own sign-in. A Community instance keeps the policy in your hands but leaves account lifecycle manual. Enterprise places identity under a central provider but adds a commercial contract and a Kubernetes-based deployment to plan.
- Workspace count: The Community edition is limited to one workspace, so more than one workspace points toward Enterprise.
- Account ownership: If your identity team already handles joiners and leavers in a directory, Enterprise SSO keeps that process in one place.
- Infrastructure: The Enterprise resources checklist lists requirements such as Kubernetes 1.24 or later and Helm 3.14 or later, while the Community edition runs under Docker Compose.
- Cost components: The Community license is free, but hosting, mail and operations still cost money. Enterprise pricing is custom and should be quoted from a written scope.
- Timing: Changing the sign-in model after people have accounts affects every existing user, so decide before production users are invited.
Write the chosen model, its owner and the date of the decision into the deployment record before the first account is created.
Why mail delivery decides whether invitations and code login work
Invitations, email code login and changes to an account's email address all depend on outbound mail, so a mail failure rarely announces itself. An invited colleague never receives the link, a new user cannot finish signing in with a code, and an administrator who changes an email address may lose the confirmation path to that account. The pricing page lists SSO as a feature of the self-hosted Enterprise edition, while Community is limited to a single workspace, so a Community instance usually has no second identity route to fall back on when mail stops. Mail is therefore part of the access policy itself and needs testing as part of that policy.
Test delivery before you close registration, using the same sender address, relay and network path the instance uses in production. Send invitations to an internal mailbox and to an external mailbox you control, and record how long each message takes to arrive and whether it reaches the spam folder. Repeat the test for email code login and for an email address change, since each produces a different message and one may fail while the others work. Ask your mail provider to confirm the sending domain's SPF, DKIM and DMARC records, the relay rules that accept mail from the Dify host, the permitted sender and recipient domains, and any rate limits that could throttle bulk invitations. Check the mail settings in the Dify environment variable reference and in the .env.example file shipped with your version, because the exact variable names should be confirmed for the release you deploy.
Plan a fallback administrator path before you set ALLOW_REGISTER to close sign-up. Keep at least one named administrator account whose sign-in does not depend on the mail channel you are testing, and record its recovery steps in your runbook with an owner and a secure place to keep the credentials. Confirm for your Dify version whether password login and code login both rely on mail, and whether an administrator can reset another account without email. If the only way back in is a direct database change, rehearse that procedure on a staging copy so it is known before an incident. Keep the fallback plan alongside your backup plan, because a restore may be the only recovery route if access and data are lost together.
Security risks in a sign-up policy that is left open
A Community instance with open sign-up, automatic workspaces and loose login options lets people you never invited reach your data. The cards below pair each risk with the control that closes it and the check that proves the control still works after upgrades and configuration changes.
Open registration admits outsiders
If registration stays enabled, anyone who can reach the console can create an account and start using models, tools and any app shared with the default workspace. Set ALLOW_REGISTER to false in the .env file and invite users by email from an administrator account. The operational check is an anonymous attempt to reach the sign-up flow on the public console URL, which should fail, plus a review of the member list after each invitation batch. The Dify license also forbids operating a multi-tenant environment, one tenant being one workspace, without written authorization, so open sign-up can create a licensing issue as well as a security one.
Auto-created workspaces spread data
Automatic workspace creation gives each new account its own tenant, which fragments data, credentials and model keys across workspaces that nobody reviews. Whether a new sign-up creates a workspace is governed by the sign-up settings, so confirm that behavior in your release before you open any path. Treat every workspace as a separate boundary: confirm who owns each one, which model credentials it holds, and which apps are shared. The check is a periodic inventory of workspaces against your approved list, with unexpected entries removed or assigned an owner.
Social login trusts external identities
Social OAuth buttons let anyone with an account at the provider sign in, so the trust decision moves to a third-party identity you do not manage. Disable social sign-in buttons unless you have decided which providers are acceptable and who controls their tenant or organization. Where you need centralized control, use an identity provider you run and its sign-in rules, and confirm that Community login options match what your policy allows. The check is a test login from a personal account on each enabled provider, which should be blocked when the provider is not approved.
Email change re-anchors stolen sessions
If an attacker holds a live session, changing the account email can shift recovery and notification control to their address, making the takeover durable. Confirm whether your release requires the current password or a verification code before an email change, and restrict who may make that change. Mail delivery is a dependency here: if the outbound mail path is broken, users cannot receive verification codes, which pushes them toward workarounds. The check is a test email change in a non-production instance that should trigger a notice to the old address.
SECRET_KEY changes end all sessions
SECRET_KEY signs session cookies and JWTs and encrypts OAuth credentials, so changing it after deployment logs every user out and breaks stored OAuth credentials. Rotation therefore needs a planned window, a notice to users and a re-entry plan for OAuth connections. Keep the value in a secrets store rather than in shared files, and record which deployments hold which version. The check is a login test after any rotation, and a review of which plugin and OAuth connections still authenticate.
Questions teams ask before locking down Dify sign-up
How much effort does a locked-down Community Dify setup take?
The effort depends less on the Dify settings themselves and more on what surrounds them. Turning off open registration, controlling workspace creation, and reviewing login buttons are short configuration changes. The larger items are confirming how invitation and login emails reach users, testing each path with real accounts, and documenting who may invite people and how accounts are removed. Ask any partner to split its quote into configuration, mail and identity dependencies, test cases, and handover documentation, so you can see which parts scale with your number of user groups and mail domains.
Can our own team lock down Dify sign-up without a partner?
Yes, if you have people comfortable with Docker Compose, environment files and your mail and identity systems. The Community edition is configured through environment variables documented in the Dify environment reference, so the change itself is within reach of an experienced platform team. Where teams usually need outside help is in proving the result: testing every sign-up, invitation, password reset and login path, and producing a record of the configuration. Decide early which of those tasks your team will own and which you want to hand to a partner under a written scope.
What do we need from our mail and identity owners?
Invitation and email code login depend on working outbound mail, so your mail owners must confirm the sending service, sender domain, authentication records and rate limits before you change sign-up behavior. Your identity owners decide whether social OAuth buttons are acceptable at all, and they should approve which identity providers and account domains are permitted. Agree on who approves an invitation, who removes accounts when people leave, and how account email changes are verified. Without these decisions, a locked-down instance can still allow the wrong people in through an unmanaged login path.
How long does testing take, and what sets that duration?
Testing length is set by the number of login and invitation paths in use, the number of roles and workspaces, and how many mail flows must be verified end to end. A deployment with email code login, one social provider and a single workspace has fewer cases than one with several providers and multiple teams. Ask for a written test matrix that lists each sign-up and login path, the expected result, the account type used, and the evidence captured. Also ask how retests are handled after a Dify upgrade, since minor releases arrive roughly monthly and may change login behavior.
Do we need Enterprise SSO to control who signs in?
Not necessarily. Community deployments can restrict who registers and who is invited, which covers many small internal instances. Enterprise SSO is the stronger option when you need your identity provider to govern access centrally, with supported protocols such as OpenID Connect, SAML and OAuth2 and separate scopes for workspace and web app access. The Enterprise edition is custom priced, so compare its cost against the operational work of managing local accounts across your user population. Ask the vendor to confirm the exact Enterprise features and license terms in writing before you decide.
What breaks if SECRET_KEY changes during a policy change?
Changing SECRET_KEY after deployment logs out all users, according to the Dify environment reference. The key also encrypts OAuth credentials, so social login configurations and any credentials depending on them can fail after rotation. Do not rotate it as part of a sign-up policy change. Plan any rotation as a separate, scheduled window with user notice, a tested rollback copy of your environment file and a check of OAuth-dependent integrations afterward. Keep the policy change and the key change in separate change records so a failure can be traced to one of them.
What should we ask a partner for in a fixed-scope quote?
Ask for a written scope that names the sign-up and login settings to change, the social providers and mail flows in scope, and the test cases you will receive. The quote should state deliverables, such as an updated configuration baseline, test evidence and an operations note for adding and removing users. Also ask what is excluded, including mail server changes, identity provider configuration and post-upgrade retesting, and whether ongoing support is offered as a separate retainer. Confirm who approves changes during the engagement and how acceptance is recorded before work starts.
Limits to confirm in your environment before you rely on this policy
The policy you set for Dify sign-up depends on the release you run, the login paths it exposes and the mail setup behind invitations. Each card below is a question to answer against the vendor documentation for your version and your own environment before you treat a closed registration setting as a control.
Exact variable names and defaults
Ask which variables control registration, workspace creation and each login method in your release, and what each one defaults to on a fresh install. Look at the .env.example file shipped with your version, because names and defaults can change between releases and an upgrade may add variables you have not reviewed. Record the values you actually run, not the values you intended to set.
Social provider availability in your build
Confirm whether social login buttons such as GitHub or Google can be turned on, turned off, or configured with your own credentials in the Community build you deploy. Do not assume that a button hidden in the console is disabled at the API level. Test each provider with a new account after you change the setting, and check that the login endpoints refuse sign-in when the provider is off.
Invitation handling without mail
Find out what happens to invitations when no mail server is configured. Confirm whether the console shows an invitation link you can copy, whether the link expires, and who can see it. If your policy relies on email invitations, mail delivery becomes a dependency you must test before the policy goes live, and your operations team needs a documented process for that case.
Login options after registration closes
Verify which login paths still work once new registration is closed, including email code login, password sign-in and social sign-in for accounts that already exist. Confirm whether an invited user who has not yet signed in can still finish setup. Test from a logged-out browser with a fresh session so you see what an outsider or a removed user can still reach.
Treatment of existing accounts
Confirm what changes for accounts created before the policy was tightened. Check whether existing users keep access, whether their login methods change, and whether a password reset or email change re-opens registration paths. Also ask how you disable or remove an account in your release, and whether removed users lose active sessions immediately or only at token expiry.
Enterprise edition for identity controls
Decide whether the identity controls you need exist in Community or only in Enterprise. The pricing page lists SSO and multiple workspaces as Enterprise features, so confirm whether your required protocol, provider, or workspace model is available without that edition. Ask the vendor for the feature matrix in writing before you design around Community limits.
How DeployOpen scopes and delivers an invite-only Dify setup
DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own infrastructure, including Dify. For sign-up, login and invitation policy, we start from a written scope that names every entry point to the instance, then build, test and hand over the controls with the evidence your team needs to review them.
How we scope
- Inventory every sign-in path, including sign-up, invitations, email code login and any social OAuth buttons enabled on the instance
- Confirm whether the instance stays on Community or needs Enterprise SSO, based on the workspace and identity requirements you set
- Agree in writing which mail delivery service sends invitations and login codes, and who owns its configuration and monitoring
How we build
- Set the registration, workspace creation and invitation settings to match the approved user model, then test each path from a clean browser session
- Configure email delivery and verify that invitation and login code messages arrive, expire and cannot be reused as designed
- Review how account email changes are handled and document the approval steps your administrators must follow for them
How we hand over
- Deliver a written configuration record listing each sign-up and login setting, its value, its owner and the reason it was chosen
- Provide test results for invited, uninvited, expired and reused invitation scenarios, so your security team can repeat them
- Document the steps for adding and removing users, and for checking the policy again after each Dify upgrade
How we support
- Fixed-scope engagements have written deliverables and timelines agreed before work starts, with any change handled through the scope
- Ongoing support, upgrades and continuous testing are available as a retainer, which can cover re-checking this policy at each release
- Ask us to confirm the current behavior of any login setting against the version you run, since settings can change between releases
