Bug description
Setting "THEME_ALLOW_THEME_EDITOR_BETA": True shows up the Theme Editor in the dashboard and multiple components can be customized using AntDesign theme editor, but when same JSON is added to "THEME" inside superset_config_docker.py, it doesn't work.
Reproduction steps:
Add superset_config_docker.py inside docker/pythonpath_dev and create a "THEME" dict. A simple one could be changing the primary color i.e. "THEME" = {"token": {"colorPrimary": "#E4A21E"}}
Expected Behaviour:
The primary color of the dashboard should change to #E4A21E but it doesn't change rather the default values are shown.
Screenshots/recordings
No response
Superset version
master / latest-dev
Python version
3.9
Node version
16
Browser
Chrome
Additional context
To play around with the dynamic theming, "THEME_ALLOW_THEME_EDITOR_BETA" is set to True in FEATURE_FLAGS in superset_config_docker.py
Checklist
- [x] I have searched Superset docs and Slack and didn't find a solution to my problem.
- [x] I have searched the GitHub issue tracker and didn't find a similar bug report.
- [x] I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section.
Comment From: dosubot[bot]
Hi @HeisenCommits! I'm Dosu and I’m helping the superset team.
The most likely reason your THEME config in superset_config_docker.py isn't taking effect is that Superset's frontend loads and applies any theme customizations stored in your browser's localStorage, which are set when you use the Theme Editor. These localStorage values override the backend THEME config sent from the server, so changes in superset_config_docker.py won't show up unless you clear your browser's localStorage for the site. This is by design to allow persistent user customizations via the Theme Editor, but it can be confusing if you're expecting backend changes to always apply.
To see your THEME config changes, clear localStorage for your Superset site (open DevTools → Application → Local Storage → right-click and clear for your Superset domain), then reload the page. The backend THEME config should now be applied as expected. If you use the Theme Editor again, it will save new customizations to localStorage, which will again take precedence over the backend config.
Your Docker Compose setup and config file placement look correct, and the THEME variable is supported for Ant Design V5 tokens in this way reference. There are no feature flags or config options to force the backend THEME to override localStorage; this override is hardcoded in the frontend logic reference.
If you still don't see your theme changes after clearing localStorage, double-check that your config file is in docker/pythonpath_dev/superset_config_docker.py and that you've restarted your containers reference.
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other 
Comment From: HeisenCommits
@dosu Even after clearing browser's local storage and cookies, THEME is not applied to the dashboard. What you mentioned is correct. After applying theme using theme editor in the dashboard it does gets saved in local storage but even after I cleared everything from the local storage and rebuilt superset using docker compose, my custom theme mentioned as part of "THEME" in superset_config_docker.py does not work.
Comment From: dosubot[bot]
This is a known limitation in Superset's current theming system: the backend THEME from superset_config_docker.py is only applied on the initial page load, and after any theme action (like using the theme editor, switching modes, or resetting), the app falls back to the default theme—not your backend THEME. Even after clearing localStorage, if you use any theme controls, the backend config is not re-applied, and there's no error or warning—this is a structural issue in how the frontend ThemeController is wired up and affects all deployments on master/latest-dev (source).
To confirm your config is being loaded: check your Superset container logs for a message like Loaded your Docker configuration at [...] and inspect the theme field in the frontend bootstrap data (in DevTools, look for the data-bootstrap attribute on the #app element or hit /api/v1/security/bootstrap). If your THEME config appears there, your setup is correct and you're hitting this limitation.
If you want to rule out config issues, try a minimal THEME like THEME = {"token": {"colorPrimary": "#E4A21E"}} and make sure there are no syntax errors. But if your theme is present in the bootstrap data and still not persistent after theme actions, it's not a misconfiguration—it's a current product limitation (source).
Let me know if you want more details on how to inspect the bootstrap data or logs.
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
Comment From: hainenber
There is an ongoing PR to enhance the new theming configuration. I believe it'll touch upon your issue as well.
Regards,