github-starred/open-webui
2
0
Fork 0
mirror of https://github.com/open-webui/open-webui.git synced 2026-05-21 09:01:47 -05:00
Code Issues 2.3k Packages Projects Releases 129 Wiki Activity

[GH-ISSUE #20389] issue: ENABLE_SIGNUP not working properly #34706

New Issue
Closed
opened 2026-04-25 08:48:14 -05:00 by GiteaMirror · 18 comments
GiteaMirror commented 2026-04-25 08:48:14 -05:00
Owner
Copy Link

Originally created by @jayteaftw on GitHub (Jan 5, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/20389

Check Existing Issues

  • I have searched for any existing and/or related issues.
  • I have searched for any existing and/or related discussions.
  • I have also searched in the CLOSED issues AND CLOSED discussions and found no related items (your issue might already be addressed on the development branch!).
  • I am using the latest version of Open WebUI.

Installation Method

Docker

Open WebUI Version

v0.6.43

Ollama Version (if applicable)

No response

Operating System

macOS

Browser (if applicable)

No response

Confirmation

  • I have read and followed all instructions in README.md.
  • I am using the latest version of both Open WebUI and Ollama.
  • I have included the browser console logs.
  • I have included the Docker container logs.
  • I have provided every relevant configuration, setting, and environment variable used in my setup.
  • I have clearly listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc).
  • I have documented step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation. My steps:
  • Start with the initial platform/version/OS and dependencies used,
  • Specify exact install/launch/configure commands,
  • List URLs visited, user input (incl. example values/emails/passwords if needed),
  • Describe all options and toggles enabled or changed,
  • Include any files or environmental changes,
  • Identify the expected and actual result at each stage,
  • Ensure any reasonably skilled user can follow and hit the same issue.

Expected Behavior

When I set the env ENABLE_SIGNUP to True, that Enable New Sign Ups should be True

Actual Behavior

When I set the env ENABLE_SIGNUP to True, Enable New Sign Ups is False

Steps to Reproduce

Start the following docker-compose file

services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:v0.6.43
    ports:
      - "8080:8080"
    environment:
      - LOG_LEVEL=DEBUG
      - ENABLE_SIGNUP=true
      - WEBUI_AUTH=true

Navigate to Admin-Panel -> General -> Enable New Sign Ups and you will it is not turned on

Logs & Screenshots

Image

Within the sqlite database if you run the query SELECT * FROM config, you will see this

1|{"version": 0, "ui": {"enable_signup": false}}|0|2026-01-05 21:18:13|

Additional Information

No response

Originally created by @jayteaftw on GitHub (Jan 5, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/20389 ### Check Existing Issues - [x] I have searched for any existing and/or related issues. - [x] I have searched for any existing and/or related discussions. - [x] I have also searched in the CLOSED issues AND CLOSED discussions and found no related items (your issue might already be addressed on the development branch!). - [x] I am using the latest version of Open WebUI. ### Installation Method Docker ### Open WebUI Version v0.6.43 ### Ollama Version (if applicable) _No response_ ### Operating System macOS ### Browser (if applicable) _No response_ ### Confirmation - [x] I have read and followed all instructions in `README.md`. - [x] I am using the latest version of **both** Open WebUI and Ollama. - [x] I have included the browser console logs. - [x] I have included the Docker container logs. - [x] I have **provided every relevant configuration, setting, and environment variable used in my setup.** - [x] I have clearly **listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup** (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc). - [x] I have documented **step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation**. My steps: - Start with the initial platform/version/OS and dependencies used, - Specify exact install/launch/configure commands, - List URLs visited, user input (incl. example values/emails/passwords if needed), - Describe all options and toggles enabled or changed, - Include any files or environmental changes, - Identify the expected and actual result at each stage, - Ensure any reasonably skilled user can follow and hit the same issue. ### Expected Behavior When I set the env ENABLE_SIGNUP to True, that Enable New Sign Ups should be True ### Actual Behavior When I set the env ENABLE_SIGNUP to True, Enable New Sign Ups is False ### Steps to Reproduce Start the following docker-compose file ``` services: open-webui: image: ghcr.io/open-webui/open-webui:v0.6.43 ports: - "8080:8080" environment: - LOG_LEVEL=DEBUG - ENABLE_SIGNUP=true - WEBUI_AUTH=true ``` Navigate to Admin-Panel -> General -> Enable New Sign Ups and you will it is not turned on ### Logs & Screenshots <img width="1994" height="135" alt="Image" src="https://github.com/user-attachments/assets/754167f6-70bc-488b-9ca8-5dec857dd377" /> Within the sqlite database if you run the query SELECT * FROM config, you will see this ``` 1|{"version": 0, "ui": {"enable_signup": false}}|0|2026-01-05 21:18:13| ``` ### Additional Information _No response_
GiteaMirror added the bug label 2026-04-25 08:48:14 -05:00
GiteaMirror commented 2026-04-25 08:48:16 -05:00
Author
Owner
Copy Link

@owui-terminator[bot] commented on GitHub (Jan 5, 2026):

🔍 Similar Issues Found

I found some existing issues that might be related to this one. Please check if any of these are duplicates or contain helpful solutions:

  1. #18737 issue: Admin user creation fails for ENABLE_SIGNUP=false
    by IronD7 • Oct 30, 2025 • bug

  2. #19993 issue: Microsoft SSO signup doesn't work after 0.6.41 update
    by avatsaev • Dec 16, 2025 • bug

  3. #19792 issue: OAuth Login redirects to https://openwebui.domain.org/oauth/oidc/openwebui.domain.org after succesful login
    by StNiosem • Dec 06, 2025 • bug

💡 Tips:

  • If this is a duplicate, please consider closing this issue and adding any additional details to the existing one
  • If you found a solution in any of these issues, please share it here to help others

This comment was generated automatically by a bot. Please react with a 👍 if this comment was helpful, or a 👎 if it was not.

<!-- gh-comment-id:3712141172 --> @owui-terminator[bot] commented on GitHub (Jan 5, 2026): 🔍 **Similar Issues Found** I found some existing issues that might be related to this one. Please check if any of these are duplicates or contain helpful solutions: 1. [#18737](https://github.com/open-webui/open-webui/issues/18737) **issue: Admin user creation fails for ENABLE_SIGNUP=false** *by IronD7 • Oct 30, 2025 • `bug`* 2. [#19993](https://github.com/open-webui/open-webui/issues/19993) **issue: Microsoft SSO signup doesn't work after 0.6.41 update** *by avatsaev • Dec 16, 2025 • `bug`* 3. [#19792](https://github.com/open-webui/open-webui/issues/19792) **issue: OAuth Login redirects to https://openwebui.domain.org/oauth/oidc/openwebui.domain.org after succesful login** *by StNiosem • Dec 06, 2025 • `bug`* --- 💡 **Tips:** - If this is a duplicate, please consider closing this issue and adding any additional details to the existing one - If you found a solution in any of these issues, please share it here to help others *This comment was generated automatically by a bot.* Please react with a 👍 if this comment was helpful, or a 👎 if it was not.
GiteaMirror commented 2026-04-25 08:48:17 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (Jan 5, 2026):

https://docs.openwebui.com/getting-started/env-configuration#important-note-on-persistentconfig-environment-variables

<!-- gh-comment-id:3712142381 --> @Classic298 commented on GitHub (Jan 5, 2026): https://docs.openwebui.com/getting-started/env-configuration#important-note-on-persistentconfig-environment-variables
GiteaMirror commented 2026-04-25 08:48:18 -05:00
Author
Owner
Copy Link

@jayteaftw commented on GitHub (Jan 5, 2026):

@Classic298 Sorry but can you explain what I am doing wrong?
My assumption would be by default that users would be able to create accounts and sign in since ENABLE_SIGNUP defaults to true. However when manually setting or not setting at all ENABLE_SIGNUP to true, the Enable New Sign Ups is False.

<!-- gh-comment-id:3712162862 --> @jayteaftw commented on GitHub (Jan 5, 2026): @Classic298 Sorry but can you explain what I am doing wrong? My assumption would be by default that users would be able to create accounts and sign in since ENABLE_SIGNUP defaults to true. However when manually setting or not setting at all ENABLE_SIGNUP to true, the Enable New Sign Ups is False.
GiteaMirror commented 2026-04-25 08:48:18 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (Jan 5, 2026):

@jayteaftw

ENABLE_SIGNUP is a PersistentConfig variable, so after the first run its value is taken from the database, not from the environment, even if you change the env var later. [Env config]

In your case, the DB already has enable_signup: false, so the UI shows “Enable New Sign Ups” as off, regardless of ENABLE_SIGNUP=true in Docker.

To fix it, use one of these approaches:

  1. One-time clean reset

    • Stop the container
    • Delete the volume (or config table) so it’s a truly fresh install
    • Start again with ENABLE_SIGNUP=true set before first launch

  2. Temporarily disable persistence

    • Start with ENABLE_PERSISTENT_CONFIG=False and ENABLE_SIGNUP=true
    • Adjust in Admin Panel if needed
    • Optionally re‑enable persistent config later

Your assumption about the default (True) is correct, but only for the very first startup before any config is stored.

Please read the docs URL i sent above

<!-- gh-comment-id:3712170974 --> @Classic298 commented on GitHub (Jan 5, 2026): @jayteaftw ---------------------- `ENABLE_SIGNUP` is a **PersistentConfig** variable, so after the first run its value is taken from the database, not from the environment, even if you change the env var later. [[Env config](<https://docs.openwebui.com/getting-started/env-configuration/#general>)] In your case, the DB already has `enable_signup: false`, so the UI shows “Enable New Sign Ups” as off, regardless of `ENABLE_SIGNUP=true` in Docker. To fix it, use one of these approaches: 1. **One-time clean reset** - Stop the container - Delete the volume (or `config` table) so it’s a truly fresh install - Start again with `ENABLE_SIGNUP=true` set before first launch 2. **Temporarily disable persistence** - Start with `ENABLE_PERSISTENT_CONFIG=False` and `ENABLE_SIGNUP=true` - Adjust in Admin Panel if needed - Optionally re‑enable persistent config later Your assumption about the default (`True`) is correct, but only for the **very first** startup before any config is stored. ---------------------- Please read the docs URL i sent above
GiteaMirror commented 2026-04-25 08:48:19 -05:00
Author
Owner
Copy Link

@jayteaftw commented on GitHub (Jan 5, 2026):

@Classic298

Thank you for informing me about that but from what your describing is sounds like ENABLE_SIGNUP should default to true on first start up.

However, on first startup it is actually setting enable_signup to false within the database.

For example
when running a docker container without a volume attached

docker run -d -p 3000:8080 --name open-webui ghcr.io/open-webui/open-webui:main

I get the same result with Enable New Sign Ups still being turned off.

Image

and when I dig into the database on first startup, I can see that the command SELECT * FROM config; produces the following

#Before first user is created
''

# After first user is created
1|{"version": 0, "ui": {"enable_signup": false}}|0|2026-01-05 22:18:21|

# After enable signup is manually set inside of admin panel
 1|{"version": 0, "ui": {"enable_signup": true, "default_user_role": "pending", "default_group_id": "", "enable_community_sharing": true, "enable_message_rating": true, "enable_user_webhooks": true, "pending_user_overlay_title": "", "pending_user_overlay_content": "", "watermark": ""}, "webhook_url": "", "auth": {"admin": {"show": true}, "enable_api_keys": false, "api_key": {"endpoint_restrictions": false, "allowed_endpoints": ""}, "jwt_expiry": "4w"}, "webui": {"url": ""}, "channels": {"enable": false}, "notes": {"enable": true}, "ldap": {"enable": false}}|0|2026-01-05 22:18:21|2026-01-05 22:19:17.337163
<!-- gh-comment-id:3712289273 --> @jayteaftw commented on GitHub (Jan 5, 2026): @Classic298 Thank you for informing me about that but from what your describing is sounds like ENABLE_SIGNUP should default to true on first start up. However, on first startup it is actually setting enable_signup to false within the database. For example when running a docker container without a volume attached ``` docker run -d -p 3000:8080 --name open-webui ghcr.io/open-webui/open-webui:main ``` I get the same result with Enable New Sign Ups still being turned off. <img width="636" height="160" alt="Image" src="https://github.com/user-attachments/assets/07a827fb-c49c-477c-8a5b-3b0adc302675" /> and when I dig into the database on first startup, I can see that the command `SELECT * FROM config;` produces the following ``` #Before first user is created '' # After first user is created 1|{"version": 0, "ui": {"enable_signup": false}}|0|2026-01-05 22:18:21| # After enable signup is manually set inside of admin panel 1|{"version": 0, "ui": {"enable_signup": true, "default_user_role": "pending", "default_group_id": "", "enable_community_sharing": true, "enable_message_rating": true, "enable_user_webhooks": true, "pending_user_overlay_title": "", "pending_user_overlay_content": "", "watermark": ""}, "webhook_url": "", "auth": {"admin": {"show": true}, "enable_api_keys": false, "api_key": {"endpoint_restrictions": false, "allowed_endpoints": ""}, "jwt_expiry": "4w"}, "webui": {"url": ""}, "channels": {"enable": false}, "notes": {"enable": true}, "ldap": {"enable": false}}|0|2026-01-05 22:18:21|2026-01-05 22:19:17.337163 ```
GiteaMirror commented 2026-04-25 08:48:20 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (Jan 5, 2026):

Thank you for informing me about that but from what your describing is sounds like ENABLE_SIGNUP should default to true on first start up.

It should not. People will install open-webui on public servers and then get spammed with signups.

Also "secure by default" is a thing and enabling signups for everyone by default is NOT secure.

to enable signups you need to do so via the UI or disable persistent config if you want to work with environment variables

<!-- gh-comment-id:3712296606 --> @Classic298 commented on GitHub (Jan 5, 2026): > Thank you for informing me about that but from what your describing is sounds like ENABLE_SIGNUP should default to true on first start up. It should not. People will install open-webui on public servers and then get spammed with signups. Also "secure by default" is a thing and enabling signups for everyone by default is **NOT secure.** --- to enable signups you need to do so via the UI or disable persistent config if you want to work with environment variables
GiteaMirror commented 2026-04-25 08:48:21 -05:00
Author
Owner
Copy Link

@jayteaftw commented on GitHub (Jan 5, 2026):

Totally makes sense why you wouldn't want by default people being able to signup.

However does the enable ENABLE_SIGNUP environment variable correspond to Enable New Sign Ups or is there a different environment variable for that?

If not, is there another environment variable that accomplishes that so that you don't have to disable ENABLE_PERSISTENT_CONFIG?

<!-- gh-comment-id:3712326992 --> @jayteaftw commented on GitHub (Jan 5, 2026): Totally makes sense why you wouldn't want by default people being able to signup. However does the enable ENABLE_SIGNUP environment variable correspond to Enable New Sign Ups or is there a different environment variable for that? If not, is there another environment variable that accomplishes that so that you don't have to disable ENABLE_PERSISTENT_CONFIG?
GiteaMirror commented 2026-04-25 08:48:23 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (Jan 5, 2026):

@jayteaftw no you cannot edit the ENABLE_SIGNUP value by editing the ENABLE_SIGNUP environment variable without disabling persistent config

<!-- gh-comment-id:3712328896 --> @Classic298 commented on GitHub (Jan 5, 2026): @jayteaftw no you cannot edit the ENABLE_SIGNUP value by editing the ENABLE_SIGNUP environment variable without disabling persistent config
GiteaMirror commented 2026-04-25 08:48:24 -05:00
Author
Owner
Copy Link

@jayteaftw commented on GitHub (Jan 5, 2026):

@Classic298

Okay I set the following environment variables

ENABLE_SIGNUP=true
ENABLE_PERSISTENT_CONFIG=false

and I am getting the same result. I am sorry if I am totally misunderstanding what this env variable is suppose to do

<!-- gh-comment-id:3712342855 --> @jayteaftw commented on GitHub (Jan 5, 2026): @Classic298 Okay I set the following environment variables ``` ENABLE_SIGNUP=true ENABLE_PERSISTENT_CONFIG=false ``` and I am getting the same result. I am sorry if I am totally misunderstanding what this env variable is suppose to do
GiteaMirror commented 2026-04-25 08:48:24 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (Jan 5, 2026):

@jayteaftw

check if you can sign up now

and if you use a systemd file dont forget to daemon-reload after adding the new environment variables

<!-- gh-comment-id:3712346715 --> @Classic298 commented on GitHub (Jan 5, 2026): @jayteaftw check if you can sign up now and if you use a systemd file dont forget to daemon-reload after adding the new environment variables
GiteaMirror commented 2026-04-25 08:48:25 -05:00
Author
Owner
Copy Link

@jayteaftw commented on GitHub (Jan 5, 2026):

@Classic298

I am running this inside of a stateless docker container using docker compose and I can do the first sign in but Enable New Sign Ups is still greyed. Every time i rebuild the container, I am having to create a whole new user.

To be clear, were you saying in your early post that if you disable persistent config and enable singup that Enable New Sign Ups will be set to True? Or is that not possible in anyway with the current available settings?

<!-- gh-comment-id:3712365126 --> @jayteaftw commented on GitHub (Jan 5, 2026): @Classic298 I am running this inside of a stateless docker container using docker compose and I can do the first sign in but Enable New Sign Ups is still greyed. Every time i rebuild the container, I am having to create a whole new user. To be clear, were you saying in your early post that if you disable persistent config and enable singup that Enable New Sign Ups will be set to True? Or is that not possible in anyway with the current available settings?
GiteaMirror commented 2026-04-25 08:48:26 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (Jan 5, 2026):

"To be clear, were you saying in your early post that if you disable persistent config and enable singup that Enable New Sign Ups will be set to True?"

Yes — with the current behavior, the only way to reliably drive “Enable New Sign Ups” via ENABLE_SIGNUP in a stateless Docker setup is:

environment:
  - ENABLE_PERSISTENT_CONFIG=false
  - ENABLE_SIGNUP=true

With ENABLE_PERSISTENT_CONFIG=false, env vars take precedence and the DB value is ignored on startup, so ENABLE_SIGNUP=true will be applied each time you (re)start the container. [Enable persistent config; Persistent note]

If ENABLE_PERSISTENT_CONFIG=true, then after the first run the DB value (which in your case is enable_signup: false) will always override the env var, so you cannot keep “Enable New Sign Ups” on purely via ENABLE_SIGNUP across rebuilds. [Env config; Issue 20389]

"Every time i rebuild the container, I am having to create a whole new user."

That indicates you did not add a volume for the DATA directory

<!-- gh-comment-id:3712382611 --> @Classic298 commented on GitHub (Jan 5, 2026): > "To be clear, were you saying in your early post that if you disable persistent config and enable singup that Enable New Sign Ups will be set to True?" Yes — with the **current** behavior, the only way to reliably drive “Enable New Sign Ups” via `ENABLE_SIGNUP` in a stateless Docker setup is: ```yaml environment: - ENABLE_PERSISTENT_CONFIG=false - ENABLE_SIGNUP=true ``` With `ENABLE_PERSISTENT_CONFIG=false`, env vars take precedence and the DB value is ignored on startup, so `ENABLE_SIGNUP=true` will be applied each time you (re)start the container. [[Enable persistent config](<https://docs.openwebui.com/getting-started/env-configuration/#enable_persistent_config>); [Persistent note](<https://docs.openwebui.com/getting-started/env-configuration/#important-note-on-persistentconfig-environment-variables>)] If `ENABLE_PERSISTENT_CONFIG=true`, then after the first run the DB value (which in your case is `enable_signup: false`) will always override the env var, so you cannot keep “Enable New Sign Ups” on purely via `ENABLE_SIGNUP` across rebuilds. [[Env config](<https://docs.openwebui.com/getting-started/env-configuration/#general>); [Issue 20389](<https://github.com/open-webui/open-webui/issues/20389>)] --- > "Every time i rebuild the container, I am having to create a whole new user." That indicates you did not add a volume for the DATA directory
GiteaMirror commented 2026-04-25 08:48:27 -05:00
Author
Owner
Copy Link

@jayteaftw commented on GitHub (Jan 5, 2026):

@Classic298

It does not seem like the intended functionality you are describing is working

With ENABLE_PERSISTENT_CONFIG=false, env vars take precedence and the DB value is ignored on startup, so ENABLE_SIGNUP=true will be applied each time you (re)start the container. [Enable persistent config; Persistent note]

I have set ENABLE_PERSISTENT_CONFIG=false and ENABLE_SIGNUP=true.
I am able to create and sign in with the first user; however I am unable to create and sign in with a second user and the Admin panel is showing the following

Image
<!-- gh-comment-id:3712433491 --> @jayteaftw commented on GitHub (Jan 5, 2026): @Classic298 It does not seem like the intended functionality you are describing is working > With ENABLE_PERSISTENT_CONFIG=false, env vars take precedence and the DB value is ignored on startup, so ENABLE_SIGNUP=true will be applied each time you (re)start the container. [[Enable persistent config](https://docs.openwebui.com/getting-started/env-configuration/#enable_persistent_config); [Persistent note](https://docs.openwebui.com/getting-started/env-configuration/#important-note-on-persistentconfig-environment-variables)] I have set ENABLE_PERSISTENT_CONFIG=false and ENABLE_SIGNUP=true. I am able to create and sign in with the first user; however I am unable to create and sign in with a second user and the Admin panel is showing the following <img width="717" height="160" alt="Image" src="https://github.com/user-attachments/assets/43d04367-70db-4923-a873-4fa0e79e64aa" />
GiteaMirror commented 2026-04-25 08:48:28 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (Jan 5, 2026):

the admin panel is less relevant now; what do you see in the login screen? is there no sign up button?

<!-- gh-comment-id:3712434913 --> @Classic298 commented on GitHub (Jan 5, 2026): the admin panel is less relevant now; what do you see in the login screen? is there no sign up button?
GiteaMirror commented 2026-04-25 08:48:29 -05:00
Author
Owner
Copy Link

@jayteaftw commented on GitHub (Jan 5, 2026):

No

Image
<!-- gh-comment-id:3712437135 --> @jayteaftw commented on GitHub (Jan 5, 2026): No <img width="633" height="335" alt="Image" src="https://github.com/user-attachments/assets/61059415-ac29-4cb3-a3d2-163287c43c81" />
GiteaMirror commented 2026-04-25 08:48:30 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (Jan 5, 2026):

MOST interesting.

I will try to replicate this tomorrow.
Either you found a bug or for some reason in your local deployment the environment variables are not correctly read.

In the meantime, join our discord, and talk to our smart AI bot in the #questions channel it can help with issues specifically like such

<!-- gh-comment-id:3712441182 --> @Classic298 commented on GitHub (Jan 5, 2026): MOST interesting. I will try to replicate this tomorrow. Either you found a bug or for some reason in your local deployment the environment variables are not correctly read. In the meantime, join our discord, and talk to our smart AI bot in the #questions channel it can help with issues specifically like such
GiteaMirror commented 2026-04-25 08:48:31 -05:00
Author
Owner
Copy Link

@jayteaftw commented on GitHub (Jan 7, 2026):

@Classic298 Hi, were you able to replicate the issue?

<!-- gh-comment-id:3720160195 --> @jayteaftw commented on GitHub (Jan 7, 2026): @Classic298 Hi, were you able to replicate the issue?
GiteaMirror commented 2026-04-25 08:48:32 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (Jan 7, 2026):

no cannot reproduce, works absolutely perfectly here.

When ENABLE_PERSISTENT_CONFIG is false, and ENABLE_SIGNUP is true, even when the database has ENABLE_SIGNUP is false, signup will be enabled and it works.

<!-- gh-comment-id:3720183237 --> @Classic298 commented on GitHub (Jan 7, 2026): no cannot reproduce, works absolutely perfectly here. When ENABLE_PERSISTENT_CONFIG is false, and ENABLE_SIGNUP is true, even when the database has ENABLE_SIGNUP is false, signup will be enabled and it works.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
confirmed
confirmed issue
core
documentation
enhancement
good first issue
help wanted
non-core
pull-request
Mirrored from GitHub Pull Request
 python
question
testing wanted
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/open-webui#34706
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?