When teams need Apache Superset branding and what it changes
Teams need Apache Superset branding when analysts, executives or embedded customers open dashboards and should see the organization's name, logo and colors instead of the upstream project's. The short answer is that you can replace the logo and brand area, set the application name through brandAppName, swap the favicon, and apply a custom color palette through a theme. Those are the visible elements. Branding changes how Superset looks and reads to users, but it is a presentation layer, not a security control. Access still depends on roles, data permissions and authentication, so a rebranded instance needs the same access review as a default one.
Apache Superset is licensed under the Apache License 2.0 and has no paid edition, so there is no vendor license to buy for branding. The cost is internal engineering and configuration effort: deciding which assets to replace, wiring the settings into your deployment, testing across light and dark modes, and keeping those settings intact through upgrades. Confirm with your own team which settings your installed version exposes, because the configuration keys and theme options can change between releases. Check the configuration documentation for your target version before you scope the work, and budget time for regression checks after each upgrade.
Branding also leaves some Superset references in place. Login pages, error messages, documentation links, default email templates, and some report or export output may still mention Superset unless you change them separately. Decide early whether those surfaces matter for your users, especially for embedded analytics where a customer may see the product's name in unexpected places. Make a written inventory of every user-facing surface, record which items your branding settings cover, and assign an owner to each remaining item so that gaps are found before rollout rather than by users.
Which parts of the interface you can brand and how
The logo sits in the top navigation bar and is set through the configuration file rather than the theme. Superset exposes a small set of brand area keys in superset_config.py that control the image, the link it points to and any text shown beside it. Confirm the exact key names and accepted image formats against the configuration documentation for your Superset version, because these keys have changed across releases.
- Logo image: Point the logo setting at an image file your deployment serves, and keep it in a location your web server or static asset path can reach.
- Logo target: Set the link the logo opens so users land on your internal portal or home dashboard instead of the default page.
- Tooltip and adjacent text: Check whether the logo keys include tooltip or right-side text options, and set them only if your standards call for them.
- Image sizing: Test the logo at the widths used by the navigation bar, including narrow browser windows, since oversized marks can crowd the menu.
- Image changes after upgrades: Recheck the logo after each version upgrade, because navigation markup changes can move or hide the brand area.
Before sign-off, confirm the logo on login, dashboard and chart pages in a staging build, and compare it with your brand guidelines.
The application name appears in the browser context, the page header and some product text, and it is set in the configuration file. The name you choose should be the one users recognize from internal communications, so set it once and keep it consistent across environments. Confirm whether your version reads the setting from a key such as APP_NAME or from a brand-specific key, since the configuration documentation is the authority for the name your release respects.
- Configuration source: Set the name in the Superset configuration file used by your deployment, not in a UI field, so every replica and environment reads the same value.
- Environment consistency: Use the same name in development, staging and production so testers see what users will see.
- Consistent wording: Choose a name that avoids the word Superset if your policy requires full removal, and document that decision for reviewers.
- Trademark review: Check with your legal or brand owner before using Apache or Superset marks in a product name, since the project license does not replace trademark guidance.
- Restart and cache effects: Restart the web processes after changing the name and clear browser caches during testing.
Before release, search the rendered pages and exported files for leftover references to the default name, and record the final string in your deployment runbook.
The favicon is the small icon shown in browser tabs, bookmarks and history. It is configured in the application configuration rather than the theme, and it needs to be served from a path the browser can fetch. Because browsers cache favicons aggressively, a changed icon can appear to fail even when the configuration is correct. Confirm the expected file sizes, formats and key names in the configuration documentation for your version.
- Multiple sizes: Provide the icon sizes the configuration documentation lists so the browser can choose the best match for tabs and bookmarks.
- Served path: Confirm the static path is reachable through your reverse proxy and that it is not blocked by content security rules.
- Cache busting: Rename the icon file or add a version parameter when you change it, so users see the update without clearing caches.
- Embedded contexts: Test favicon behavior when Superset pages load inside an iframe or a portal, since some hosts override it.
- Source control: Store the icon files in the same repository as the configuration so branding changes go through review.
Before release, open the application in two different browsers, check the tab, and confirm that the icon loads without console errors.
Colors are controlled through the Ant Design theme system rather than the configuration file. A theme is a set of tokens that define values such as primary color, background, text and link colors, and it can be created and managed in the UI or defined in code, depending on how your deployment is run. Changes to colors affect charts, controls and navigation together, so test them as a complete set. Confirm which token names your Superset version supports, because tokens are part of the theme interface and can change between releases.
- Theme definition: Define the palette as a theme with tokens, then apply it as the system default or as a dashboard-level theme.
- UI administration: Use the theme administration screens when your administrators need to manage themes without redeploying, and confirm which roles can access them.
- Contrast and accessibility: Check text and background contrast for every token you change, including hover and disabled states.
- Chart colors: Remember that chart palettes are separate from interface tokens, so confirm chart colors in a chart test dashboard.
- Invalid values: Test how Superset behaves with an incorrect token, since a bad value can fall back to defaults and make the brand look inconsistent.
Before release, review light and dark modes, every dashboard you expose to users, and a printed or exported report to confirm the palette holds.
Login pages, menus, footers and help links carry text that Superset does not always expose as a simple setting. Some of this text comes from the Flask-AppBuilder layer and some from the frontend, so changing it may require templates, translation files or a custom build rather than a single key. Treat this surface as the one most likely to still show default wording after you have finished branding, and plan a review step that covers it explicitly.
- Login page: Check whether your identity setup lets you change the sign-in heading, helper text and footer, and note which changes need template overrides.
- Navigation labels: Identify menu items and help links that point to upstream documentation, and decide whether to relabel or remove them.
- Translation files: If your deployment uses translation builds, confirm whether custom strings must be added to translation catalogs and rebuilt.
- Error and email text: Review error pages and any emails sent through alerts or reports, since they can keep default product wording.
- Upgrade impact: Record every template or string override in a list, because upgrades can overwrite or break them.
Before release, sign in with a new account, click through each menu, trigger an error page and check any scheduled report, then compare the results with your leftover-branding checklist.
Branding options and when each one fits
This table compares the main branding levers in a self-hosted Superset: logo and brand area settings, the application name, favicon, system-wide theme tokens and per-dashboard themes. Read each row for the effort it takes, who can change it, and how easily it drifts out of step with the rest of the instance. Most teams should start with the configuration settings and a single system theme, then add dashboard-level themes only where a team genuinely needs them.
| Branding option | Effort and who changes it | Risk of inconsistency | When it fits |
|---|---|---|---|
| Logo and brand area | Low. Set in the configuration file by the platform team and applied on redeploy | Low, because one setting covers every user | Any instance that needs an organization logo in the header |
| Application name (brandAppName) | Low. Set once in configuration by the platform team | Low, but browser titles and some labels may still show Superset (confirm in your version) | Instances that should not present the Superset name to end users |
| Favicon | Low. Requires a file the browser can fetch from your hosting location | Low, but cached favicons can show the old icon for some users | Internal tools where browser tabs should match the corporate identity |
| System theme tokens (Ant Design) | Medium. Defined by the platform team and tested across light and dark views | Medium, since charts, menus and modals must all read the same tokens | Organizations with one visual standard across all dashboards |
| Per-dashboard themes | Medium to high. Owners or admins apply themes and must keep them current | High, because dashboards can drift from the system look over time | Teams with a documented need for distinct dashboard styling only |
| Logo and image hosting | Medium. Files must be reachable from the browser and permitted by your Content Security Policy | Medium, since blocked images fail silently and look broken | Every instance that serves its own logo or favicon from internal storage |
How to apply a Superset brand in staging before production
This sequence proves the brand settings work in a staging build before anything reaches users. It produces a tested configuration that moves to production as the same artifact, with each surface checked against the approved assets and colors.
Collect brand assets and approved colors
The brand owner and the Superset administrator agree on a single asset set: the logo in the formats the configuration will reference, a favicon, the application name, and the approved palette with hex values for primary, accent, and text colors. Store these in the same repository as the Superset configuration so every later change is traceable. The step is done when the asset list is signed off by the brand owner and each file opens and renders correctly at its intended size. Confirm with your brand team whether a dark-mode logo is required, since that changes how many files you need.
Set branding keys in a staging configuration
The platform engineer adds the branding keys to the Superset configuration file used by the staging build, including the application name, logo and favicon paths, and any default brand settings the version supports. Check the configuration reference for your Superset version before setting each key, because names and behavior can differ between releases. Keep secrets out of this file. The step is done when staging starts without configuration errors and the Superset logs show the branding values loaded, not defaults.
Apply a theme through the admin interface
A user with administrator rights creates the theme in the Superset UI from the approved palette and sets it as the system theme in staging. Record the theme tokens exported from that session so the same values can be reapplied from code later. The step is done when the theme appears in the theme list with the expected name and the saved token values match the approved palette. Avoid editing colors ad hoc in the browser without writing them back to the source record.
Verify login, dashboards, charts and exports
Test in a fresh private browser window and after clearing the browser cache, since cached assets often show the old logo or favicon. Check the login page, the top navigation, a dashboard, a chart with a custom color scheme, and a chart export to image and CSV. Confirm that the browser tab title and favicon match the configured values. The step is done when each surface shows the approved logo, name and colors, and any remaining default Superset text is logged in a list for the next step.
Test with a non-admin role
Sign in as a standard analyst or viewer account that has no administrator rights, then repeat the checks from the previous step. Branding is often applied for administrators first, and some elements can behave differently for restricted roles, including pages reached through shared links. Compare what the non-admin role sees against the approved assets. The step is done when a non-admin account shows the same brand on every page it can reach, and any gaps are recorded with the page, role, and version.
Log remaining Superset references
Review the list of places that still say Superset, such as documentation links, footer text, error pages, email notifications, and some dialog strings. For each item, decide whether to change it through configuration, accept it, or raise it with the vendor or your integrator as a limitation. Confirm each decision against the version you run, because strings and their locations change between releases. The step is done when every remaining reference has a recorded decision and an owner.
Promote the same configuration through your image pipeline
Build the production image from the same commit, configuration file, and theme token export used in staging, so no brand value is edited by hand in production. Deploy it through your normal release process and rerun the verification checklist against production with a non-admin account. Keep the staging checklist as the acceptance record. The step is done when production shows the same results as staging and the image digest, configuration version, and theme record are documented together.
What still says Superset after branding
Changing the logo and app name in the UI does not remove the Superset name from everything a user or auditor can see. Before you call branding finished, check each of the places where the name usually survives: the browser tab title and page metadata, the favicon in your own build, default documentation and help links in the user menu, the about or version dialog, and the footer or error pages. Confirm each item in your own version, because which ones remain depends on your release and on what your templates and configuration override. Record the result as a short checklist so the next upgrade repeats the same review.
Outside the web interface, the name appears in messages and technical artifacts. Email notifications from alerts and reports carry the sender name and body text that your configuration and templates may or may not replace, so send a test report to an external mailbox and read the full message, including headers. The API documentation page, the error responses returned by the API, and the source code and Python package names inside your container image also keep the original naming. Treat these as things to verify and document, not as things you expect to change, and ask your team whether internal support staff will need to explain them to users.
Keep the license notices in place. Superset is licensed under the Apache License 2.0, and that license requires redistributed copies to keep the copyright and license notices, so removing attribution is not a licensing action and can create a compliance problem if you distribute the software or your modified image. Brand the user-facing surface, but leave the LICENSE and NOTICE files and the project's copyright headers intact. If you want your own notice or a product statement, add it alongside the existing text. Confirm the exact notice requirements with your legal or open-source review team before you publish a modified build.
Security and operational risks of custom branding
Branding looks cosmetic, but each change touches assets, configuration and the people who see the output. The cards below cover the risks that most often surface after a branding change goes live, and the control that keeps each one contained.
External assets and CSP conflicts
A logo, favicon or font served from a third-party host must pass your Content Security Policy and any egress rules on the network. If the host is blocked, the login page and dashboards can load with broken images or fallback fonts, and browser consoles fill with policy violations. Pin each asset to a URL you control, serve it from the same origin where possible, and test the header policy on a staging build before release.
Configuration keys that move between releases
Branding is set through configuration values such as the brand logo, app name and theme settings, and the keys and their defaults can change between Superset versions. A change that worked on one release can silently stop applying after an upgrade, leaving the old branding in place or breaking the layout. Record every branding key in version control, read the release notes for each upgrade, and confirm the branding still renders in staging before production.
Inconsistent themes across instances
Organizations often run separate Superset instances for development, staging, production or business units, and each one can end up with a different theme, logo or app name. Users then see different branding for the same dashboard, and support teams cannot tell whether a fault is in the content or the environment. Keep one branding source of truth, deploy it with the same pipeline to every instance, and compare the rendered login and home pages after each release.
Exported PDFs and screenshots with old branding
Reports, PDF exports and thumbnails are generated by the server and can keep the branding that was active when they were rendered, or the branding of a cached asset. Recipients of scheduled reports may receive files that show an old logo, a former app name or a color scheme that no longer matches the brand guide. Regenerate a sample of exports after each change, check how cached thumbnails are refreshed, and decide who owns the sign-off for externally shared files.
Untested changes reaching production
Color and logo changes look low risk, so they are often edited directly on a production host or pushed without review. A malformed value, an oversized image or a palette with poor contrast can break the login page for every user at once. Route branding changes through the same change review as code, run a staging test covering login, a sample dashboard and an export, and keep the previous asset set so a rollback takes minutes.
Admin-only theme access and ownership
Theme and branding changes depend on which accounts can edit them. If several administrators can change system-wide settings, or if a shared admin account is used, a change can happen without a record of who made it or why. Limit theme administration to a named group, use individual accounts, log the changes in your operations records and review that group during access reviews.
How branding survives Superset upgrades
Do Superset branding settings survive an upgrade automatically?
Not reliably, so treat them as configuration you own and re-check on every upgrade. Logo paths, brandAppName, favicon references and theme definitions live in your configuration and assets, and the upstream project can rename, move or deprecate keys between releases. Keep these files in version control, deploy them through the same pipeline as the rest of your Superset image or configuration, and confirm after each upgrade that the login page, navigation and exported views still show your brand.
What steps does the upgrade guide require before changing branding?
The upgrade guide asks teams to back up the metadata database, run superset db upgrade and superset init, and test the new version in staging before production. It also says to check UPDATING.md for breaking changes between versions. Branding work belongs in that same staging run, because a changed configuration key or asset path can fail quietly while the core application still starts. Record which branding settings you verified so the next upgrade starts from a known list.
Why can a theme break after an upgrade even when my config still loads?
Superset's visual layer is built on Ant Design, and changes to the UI components can rename or change the effect of theme tokens. A color token that once tinted the header may stop applying to the same element, or a value may be ignored without an error. Compare your theme JSON against the token names documented for the target version, and check dashboards, charts, modals and the login page in staging, since a token change may only show in one area.
Which branding keys still apply in the version I plan to run?
Confirm this against the documentation and release notes for your target version rather than relying on an older guide or a blog post. Check the configuration reference for the branding keys, the theme documentation for the token names, and the UPDATING.md entries between your current and target versions. Ask whether any key was renamed, deprecated or moved to the UI administration area, because your own configuration file may still load a key the running version no longer reads.
How much effort does re-testing branding on each upgrade involve?
Effort depends on how much you customized and how many teams depend on the look. A logo and app name with one theme usually means a short visual check, while custom fonts, chart overrides, custom plugins or embedded dashboards add more surfaces to test. The main cost is staff time for review, plus any build work if an asset or plugin must be rebuilt into your image. Ask any implementation partner to price the upgrade check as a separate line from the upgrade itself, and to list which screens are covered.
Should branding changes be deployed through the same pipeline as the Superset image?
Yes, in most cases. Store the configuration file, theme definitions, logo files and favicon in a repository with reviewed changes, and build or deploy them with the same tagged version that runs the application. That makes it possible to roll back a branding change without rolling back data, and it shows auditors and security reviewers who approved each visual change. If your Superset runs on Kubernetes, check the deployment guide for your target version to see how configuration and assets are mounted before you design the pipeline.
Can our own team handle branding upgrades, or do we need a partner?
A team that already runs Superset in staging and production can usually handle routine branding checks internally, provided someone owns the upgrade checklist and has time to review release notes. A partner adds value when the branding involves custom plugins, translations, embedded analytics or a backlog of overrides that each need retesting. Whichever path you choose, agree in writing who maintains the branding repository, who signs off on visual changes, and how a failed check is handled before a fixed-scope engagement or retainer begins.
Limits to confirm in your environment
Branding in Superset touches configuration, static assets, embedding, translations and deployment tooling, and each of these can behave differently by version and install method. The checks below are the ones to run against the exact release and deployment path you plan to use before you commit to a brand package.
Keys for your exact version
Confirm which branding keys exist in the Superset release you will run, and whether their names or defaults changed between releases. Read the configuration documentation for that version, then test each key in a staging instance. Pay attention to which settings live in superset_config.py and which are exposed through the theme system, because a key that works in one place may not apply in the other. Record the version you tested so the result can be repeated during upgrades.
Logo and favicon hosting
Decide whether logos and favicons can be served from your CDN or must come from your own web tier. Confirm that your content security policy allows the image sources you choose and that the assets load for users on restricted networks. Check how a missing or blocked asset degrades, since a broken logo on a login page reflects on your brand. Keep the files in version control with the rest of your image build.
Embedded dashboard branding
Confirm whether dashboards embedded in your own product inherit the same app name, logo and palette as the standalone Superset interface. Embedding often runs under a different origin and sometimes a different theme assignment, so the visible brand can differ from the console. Test an embedded page in each browser and host combination your users run, and check any public or guest dashboards separately.
Translations and renamed labels
Confirm how a renamed app title or label interacts with translation builds. Strings that ship in language packs may still show the upstream product name, and a custom label may not be translated. Ask which strings you can override, test the default and each enabled language on the login page, menus and error messages, and decide who owns the wording for each locale.
Kubernetes config injection
Confirm how your Kubernetes install injects configuration. The Helm chart is marked deprecated in current development documentation, and the Kubernetes Operator is alpha with a v1alpha1 API whose schemas may change between releases. Check which resource or values file carries your branding settings, whether a config change triggers a rolling restart, and how the setting is versioned in your GitOps repository.
Remaining Superset references
Inventory every place the upstream name still appears after branding, including browser tab titles, email subjects, report footers, exported PDFs, API documentation pages, error pages and the package metadata in your image. Some of these come from templates and others from translated strings. Assign an owner to each item and test one export and one scheduled report before sign-off.
Questions buyers ask about Superset branding
How much effort does branding Apache Superset take?
Effort depends on how many surfaces you brand and how far past the built-in settings you go. Setting a logo, an application name and a favicon is a configuration exercise. Changing colors through a theme, and then checking every dashboard, chart type, modal, login page and exported report against the new palette, is a larger piece of work. The main drivers are the number of surfaces in scope, whether you need dark and light variants, whether you are changing chart colors or only the application chrome, and how many environments must match. Ask any partner for a written list of surfaces they will test before agreeing a price.
Can a non-developer change the Superset logo and colors?
A non-developer can prepare the brand assets and review the result, but applying the settings usually needs someone who can edit the deployment configuration and redeploy the application. Logo and application name settings live in the Superset configuration, and themes are defined as JSON token sets that someone must validate. Some theme administration can be done in the user interface by users with the right role, but the change should still be captured in configuration so it survives a rebuild. Plan for a technical owner to make the change and a business owner to approve the visual result.
Is Superset branding a security control?
No. Branding changes how the product looks, not who can access data or what users can run. Logos, names and colors do not protect dashboards, databases or exports. Do not treat a custom login page or brand area as evidence of access control. Access is governed by authentication, roles, row level security and database privileges, which need their own configuration and testing. Branding does need a review step, because a changed logo URL or custom asset that loads from an external host can affect your content security policy and what data leaves your network.
What needs to be redone after each Superset upgrade?
Anything you changed outside the core product can break or need checking after an upgrade. Review your brand configuration, theme JSON, any custom assets and template overrides against the release notes for each version you move to. Check the project's UPDATING.md for breaking changes before you apply the upgrade. Then repeat your visual checks in staging on the pages that matter most, including login, the home screen, a sample dashboard, an exported PDF and an alert email. Ask whether the chosen approach relies on internal markup that may change between releases.
Does the Apache Superset project charge for branding?
The project does not charge for branding. Apache Superset is released under the Apache License 2.0 and has no paid edition, so the logo, application name and color settings are available in the open-source release. Any cost you pay is for the work: design review, configuration, testing, documentation and ongoing upkeep, which a partner or your own staff would perform. Confirm the license terms for any third-party font, icon or tile service you add, because those carry their own conditions.
What must our team provide before branding work starts?
Your team should provide the brand assets in the formats needed, such as a logo in light and dark variants and a favicon, along with the approved application name and a palette with hex values. You also need a staging environment that matches production closely enough to test real dashboards, and a named owner who signs off the visual result. Provide a sample of the dashboards, charts and exports your users rely on so the test covers the surfaces that matter. Agree in writing who approves changes after go-live.
What still says Superset after branding is applied?
Several places usually keep the Superset name or default visuals. Examples to check include browser documentation links, some modal titles, error pages, the about or version information, API responses, email footers in alerts and reports, and any built-in help text. Text in translated language packs can also keep the original product name. Make a written inventory of these surfaces during scoping, and decide per item whether to change it, leave it or document it as a known gap.
How DeployOpen scopes and delivers Superset branding
DeployOpen treats Superset branding as a small, bounded change to a self-hosted installation that you control. We start from the written scope, apply the logo, app name and color settings in a staging copy first, and document what still shows the Superset name so you can decide what to change next.
How we scope
- Inventory which brand surfaces matter: login page, navigation area, favicon, browser title and exported files.
- Confirm the logo files, app name wording, color palette and the image hosting approach you want to use.
- Agree in writing which Superset references stay, such as documentation links, license notices and third-party text.
How we build
- Set the brand area, logo and app name configuration in your deployment configuration rather than editing the application code.
- Apply the color palette through the theme settings and check contrast on the login page and main dashboard views.
- Test the result in a staging environment on the same image and version you run in production before any rollout.
How we hand over
- Deliver the configuration files, asset locations and a record of each brand setting and where it is applied.
- Document a list of remaining Superset references, with notes on what each one is and whether it is user-facing.
- Include a short runbook for changing logos or colors later, including how to repeat the check after a version upgrade.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Re-check branding settings during each Superset upgrade, since upgrade notes may change how assets or themes are loaded.
- Ongoing support, upgrades and continuous testing are available as a retainer if you want branding maintained over time.
