White-label embedded Superset dashboards

Making embedded Superset dashboards look like part of your product

Your customer opens a dashboard inside your product and sees the Superset header, the Superset menus, a login-style logout and default colors. White-labeling covers the work that removes those signals: applying your theme and brand tokens, hiding Superset navigation and logout, serving dashboards and permalinks from your own domain, and allowing the web fonts your brand needs under the Content Security Policy. Teams need this work when the analytics are part of the product they sell, not an internal tool that staff reach through a separate login. The decision is not whether to brand, but how far to go and who owns each layer. Apache Superset is licensed under Apache-2.0 and has no paid edition, so there is no vendor-supplied white-label option to buy. Every change is configuration or build work your team or your implementation partner owns: theme settings, custom front-end assets, host page integration and the security headers that let the browser load them. That ownership carries upkeep. Each Superset upgrade can change the markup or styling you overrode, so plan a regression pass on the embedded views for every release, and confirm which customization hooks your target version supports before you commit to a design.

Start by listing every surface a customer can reach: the dashboard, filter panels, chart tooltips, permalink URLs, error pages, and any export or share menus. Each one can expose Superset branding or navigation, and each may need a different control. Then decide where the outer shell belongs. Many teams let the host application render the frame, navigation and sign-out, and keep the embedded dashboard free of Superset chrome. Confirm with your Superset version which UI elements can be hidden through configuration and which require overriding styles, because the second option is more fragile. Before launch, test the result in the browsers and screen sizes your customers use, and check that font and stylesheet requests are allowed by your Content Security Policy without loosening it for unrelated content. Confirm that permalinks resolve on your domain and do not reveal internal hostnames. Ask your partner to show the rendered output on a staging instance, and keep a written list of every branding change so the next upgrade review knows what to retest.

The four parts of a white-label Superset embed

A white-label embed is less a single setting than four separate decisions, each owned by a different layer of your stack. Theme tokens, navigation visibility, link domains and browser policy all affect what the viewer sees, and a change in one often shows up as a broken or off-brand result in another.

Theme and brand tokens

Theme and brand tokens set colors, typography and other visual values so that dashboards and charts match your product's design system. You control these values, but their reach depends on the Superset version you run and the theming mechanism it exposes at that version. Before committing to a palette, confirm in your target release which elements accept overrides and which still fall back to Superset defaults. Test with your heaviest dashboard, since charts and tables are where gaps usually appear.

Navigation and logout visibility

Hiding Superset's own navigation, menus and logout control is what makes an embedded dashboard read as part of your product rather than a separate tool. What you can hide depends on how the embed is built, since the embedded SDK renders only the dashboard content while a full Superset page carries its own chrome. Confirm which navigation elements remain visible in your embed mode, and make sure the host app supplies its own sign-out path so users are not stranded.

Permalinks on the host domain

Permalinks let users share a specific dashboard state, including filters, and they are generated by Superset. In a white-label embed, the links users copy should point to your domain, not to the Superset host, which may be an internal address. Decide which base URL Superset uses to build these links, and verify that the host domain resolves to the same deployment and that sharing still respects the viewer's access.

Fonts and assets under the CSP

Custom fonts, logos and images must be allowed by the Content Security Policy that Superset sends and that your host page applies. A font served from a CDN will fail silently if the font source is not listed, and the dashboard falls back to a default face. Inventory every external asset your theme references, then set font and image sources explicitly in the policy. Coordinate these settings with the frame-ancestors and cookie rules that govern the embed as a whole.

Which branding approach fits which embedding model

Configuration overrides are the lowest-effort option and the one most likely to survive upgrades. Theme and branding values are set through the Superset configuration file, which you manage with the rest of the deployment. Changes live in version-controlled settings, so they are easy to review and reproduce across staging and production. See the configuration documentation for the keys your release supports.

Upgrade effort: Settings usually need a review only, but a key can be renamed or removed in a later release.
Reproducibility: One configuration file can be applied to every environment, so branding can be tested in staging before production.
Depth limits: Token-level changes cover values such as colors and fonts. Layout changes and hidden navigation usually need one of the other two approaches.
Key verification: Confirm the exact configuration keys for your release before writing them, instead of copying keys from older examples.
Ownership: Name who edits the configuration and who approves the change, since a small edit can alter every embedded dashboard at once.

Before each upgrade, check UPDATING.md for renamed or removed keys, then test the branding on a staging copy that uses your production configuration.

Configuration options and when each one fits

This table compares the main ways to brand embedded Superset dashboards, from the embedding layer to the browser and proxy. Read each row for what it changes, where it is set and how it behaves across upgrades. Start with the option closest to the host application, and move to proxy or frontend changes only when the simpler options cannot reach the element you need.

Option	What it changes and where it is set	How it survives upgrades	When to choose it
Embedded SDK theme and layout options	Colors, fonts and layout inside the embedded frame, set in your application code when the SDK mounts the dashboard	Lives outside Superset's code, but confirm each key in your version's SDK docs	Choose first when only the embedded view must match your brand
Guest token and embed display options	Which dashboard and filters a viewer gets, plus any display options your SDK version exposes for hiding parts of the view	Set from your backend per token, so check option names after each SDK update	Choose when navigation or logout must stay out of the customer view
Instance-wide branding keys in superset_config.py	Application name, logo and favicon for every user of the instance, including internal staff, set in the config file	Survives upgrades if the file is under version control and the key still exists; check UPDATING.md	Choose when the whole instance should carry your brand
Dashboard-level custom CSS	Style overrides for one dashboard, stored with that dashboard's properties	Can break when Superset class names or markup change between releases, so retest after every upgrade	Choose for small visual fixes on a few dashboards
Reverse proxy rewrites and headers	The domain, path and response headers the browser sees, so embeds and permalinks can sit on your domain	Lives outside Superset, so it survives Superset upgrades but needs changes when hostnames change	Choose when permalinks and iframes must be served from your domain
Font loading through CSP font-src	Permits brand fonts from a CDN or your own host in the embedding page's Content Security Policy	Survives upgrades if headers are managed outside Superset; confirm the directives your version needs	Choose when brand fonts are hosted outside Superset's default assets
Custom frontend build or plugin	Changes Superset's own UI code, including navigation components that settings and CSS cannot reach	Highest maintenance: changes must be rebased and retested on each release	Choose only after the options above fail for a specific element

How to set up white-labeling in order

This sequence takes an embedded Superset dashboard from a brand specification to a tested embed that reads as part of your product. Each step closes with a check, so problems surface on staging before any customer sees the result.

Agree the brand specification
Product, design and engineering agree in writing which brand elements the embedded dashboards must carry: colors, typography, logo placement, chart palette, and which Superset navigation, menus and logout controls must disappear for embedded viewers. Confirm which font files and hosts the design needs, since those decisions feed the Content Security Policy step later. The step is done when one signed-off document lists every item, and each item names an owner and a test case.
Configure theme tokens in staging
Apply the brand specification to a staging Superset instance using its theme and brand token settings, starting with a single representative dashboard. Check how the theme handles charts, filters, headers and dark or light contrast, and record any element the theme does not reach, since those gaps usually need custom work or a documented exception. The step is done when a reviewer compares the staging dashboard against the specification and signs off each item or logs a gap.
Hide navigation and logout for embedded viewers
Configure the embedded view so that embedded viewers see the dashboard content without the Superset top bar, navigation menus, explore links or logout control. Confirm the setting works with the embedding method your application uses, and check that the hidden controls cannot be reached through direct URLs to other Superset pages. The step is done when a test session that opens the embed shows no Superset chrome, and a second test session confirms that navigating to restricted pages returns an access error rather than a full Superset interface.
Set up permalinks on the host domain
Decide which domain serves the embedded dashboard and configure permalinks so that links generated for viewers point to your product domain rather than the internal Superset hostname. Confirm the reverse proxy forwards the correct host and protocol headers, and that the public URL setting matches the address customers actually use. The step is done when a permalink generated in staging opens on the host domain, resolves to the same dashboard state, and does not expose the internal hostname in the browser address bar.
Update the CSP for approved font sources
Add only the font sources approved in step one to the Content Security Policy that serves the embed, typically a font-src directive for the font hosts named in the brand specification, and keep every other directive as narrow as the embed allows. Coordinate this change with the team that owns the browser security settings, since frame-ancestors and CORS rules for the host origin are part of the same header set. The step is done when the browser console shows no font-related CSP violations on the staging embed, and the policy review records each new source with its reason.
Test the staging embed end to end
Load the white-labeled dashboard inside a staging build of your product, using a test account for each customer tenant and a test account with restricted access. Check theme rendering, hidden navigation, permalink behavior, font loading, responsive sizing and error states, and compare the result against the brand specification. Run the same checks after any Superset upgrade or configuration change. The step is done when every test case in the brand specification passes on staging and the results are filed with the release record.

Why permalinks and fonts are where white-labeling breaks

Permalinks and web fonts are the two parts of a white-labeled embed that cross origins, and both fail quietly when they are not planned. A permalink generated by Superset points at the Superset host, so a user who copies or follows it from your product lands outside your domain unless the link is built on your side. Confirm which Superset base URL the embedded dashboard and its share actions use, and decide whether shared links should resolve through a path on your own domain that proxies to Superset. Test the full path from a logged-in customer session, because a link that works for an administrator may still break for an embedded viewer who has no Superset login. Note that the permalink behavior depends on your routing and proxy configuration, not only on theme settings.

Fonts are the second break point. A brand font served from a CDN or font host is a separate origin, and the browser will refuse to load it unless the Content Security Policy allows that origin for font sources. The tempting fix is to add the font host to the policy, but each allowed source widens what the page is permitted to load and execute from that origin, not only the font file. Keep the list to the exact hosts you need, prefer self-hosting the font files on your own domain so the font-src directive can stay at 'self', and record who approved each addition and why. The same policy governs the iframe that carries the dashboard, so review it with your embedding team.

Treat the CSP and cookie settings as a single change set rather than separate tickets. The sibling topic on browser security settings for embedded Superset covers frame-ancestors, SameSite and CORS in detail. Before you change any font or permalink setting, ask your security owner to review the full policy, run the embedded dashboard in a staging environment with the production policy, and check the browser console for blocked resources. Document the final directives so that a later theme change does not quietly reopen a source you removed.

Security risks that white-labeling can introduce

White-labeling changes what viewers see, not what they are allowed to see. The risks below share one root cause: a branding change can quietly remove a control that was doing security work, so each change needs a matching check in the data layer, the browser and the session settings.

Hidden navigation is not access control

Removing the Superset menu, logout button and explore links only changes what a viewer can click. A user who knows a dashboard or dataset URL, or who calls the API directly, can still reach data their role allows. Data scoping has to live in guest token resources and row level security rules, which the server enforces on every query. Test each embedded role by calling the API and loading restricted datasets directly, not only by checking the rendered page.

Loosened frame and CSP settings

Brand work often pulls in extra font hosts, style sources or host pages that need to frame the dashboard, and the quickest fix is to widen the Content Security Policy or set frame-ancestors to a wildcard. Each widened source gives a hostile page a way to frame the dashboard for clickjacking or to inject script where the dashboard runs. Allow only the named host origins and fonts you use, and record each exception with the reason it exists.

Permalinks can expose filter state

Permalinks and shareable dashboard URLs carry filter state in the link itself. When these links sit on your domain, a customer who copies one can pass the filter values to another person, and an internal filter value may reveal a tenant name, account ID or record count. Decide which filters are safe to share, confirm whether links can be used by people outside the tenant, and keep tenant identifiers out of URL parameters where possible.

Secret key and session settings

Themed embedding does not replace the core settings that protect sessions. Superset requires a user-specified SECRET_KEY to start, a requirement added in version 2.1.0, and supports rotation with PREVIOUS_SECRET_KEY. Confirm that the key is set in your deployment, that rotation is planned, and that cookie flags and session lifetimes still apply to embedded viewers, since a custom host page can change how the iframe handles cookies.

Custom theme overrides and host scripts

Brand tokens and custom CSS are powerful because they change markup on the page, but they also become a place where untrusted content can be inserted. Logos, footers and help text that come from a tenant profile or a CMS must be treated as data, not markup. Review who can edit theme files and host-page snippets, keep them under version control, and confirm that no tenant-supplied value is rendered as HTML.

Upgrades can reset brand changes

Overrides to templates, styles and plugins can break or silently drop when Superset changes between versions, and a branded build can miss a security patch if teams avoid upgrading it. Keep the branding layer small and separate from the upstream code, then retest the security checks above after every upgrade. Check UPDATING.md for breaking changes before you move the version, and keep the release notes with the change record.

Questions teams ask before white-labeling Superset

What drives the cost of white-labeling embedded Superset dashboards?

The cost follows the size of the visual change and how much of it touches Superset's own interface. Theme and brand token work on colors, logos, typography and chart palettes is the smallest part. Hiding Superset navigation, logout and menus, serving permalinks on your domain and reviewing fonts against the Content Security Policy each add design and engineering steps. Custom frontend work, such as chart overrides or plugins, adds the most effort because it must be rebuilt and tested with each release. Testing across tenants adds more, since every tenant view must be checked for visual and data leaks. Fixed-scope work is priced from a written list of these items, so ask for each one to be listed separately in the quote.

How long does white-labeling take in general terms?

Duration depends on how many screens are in scope, how many brand decisions are still open, and how many review cycles the security and front-end teams need. A theme-only change on a few dashboards moves much faster than a full navigation and domain rework that spans several tenants. Delays usually come from late brand approvals, CSP changes that need security sign-off, and staging reviews that surface layout problems on real data. Ask the partner to state the phases, the review gates and which items depend on your decisions, rather than a single total. Any firm timeline should appear in the written scope, where it can be checked against those dependencies.

What does our internal team need to provide?

Most of the input must come from your side before build work starts. Expect to supply brand assets such as logo files, color values, font licenses and usage rules, plus a named owner who can approve decisions quickly. You will also need a staging environment that mirrors production Superset and includes representative embedded dashboards, so visual and security checks run on realistic configuration. Reviewers are needed from three groups: a front-end reviewer who knows your product UI, a security reviewer who owns the Content Security Policy and cookie settings, and a product owner who signs off on what the end user should and should not see.

Can our team white-label Superset without outside help?

A team with strong front-end skills, access to the Superset source, and time to test can do theme and branding work alone. The harder parts are removing Superset navigation safely, keeping the Content Security Policy strict while allowing brand fonts, and proving that tenant data stays separated after each change. Those tasks need security review and repeatable test cases that many product teams do not maintain. Ask yourself who will rebuild the frontend after each upgrade, who will run the cross-tenant tests, and who will answer for the CSP. If those answers are unclear, a fixed-scope engagement can cover the build and hand over documented steps your team can run.

Does white-labeling make Superset upgrades harder?

Yes, it usually adds effort, because every custom style, template override or frontend change depends on Superset internals that can move between versions. Before each upgrade, check the project's UPDATING.md notes for breaking changes, then test the embedded views in staging, since a theme can break silently when class names or components change. Keep customizations in version-controlled files, keep the changes as small as possible, and record which selectors and components each override touches. Ask any partner to include the upgrade regression tests and a list of customized components in the handover, so future upgrades are scoped by known changes.

Which security checks should white-labeling include?

The main checks cover the Content Security Policy, cookie behavior for embedded sessions, and whether hidden navigation still exposes routes that lead to other data. Confirm that font and asset sources you add are listed explicitly in the policy and not opened to broad origins. Verify that permalinks on your domain do not reveal dashboards outside a viewer's guest token scope. Test that the Public role and any anonymous access are unchanged by the branding work. Ask for written results from these checks, and keep them as evidence for your own security reviews, since DeployOpen prepares controls and evidence but does not issue audit reports.

What should we ask for in a white-labeling quote?

Ask for a written scope that lists each screen, theme token group, navigation item to hide, permalink route, font source and CSP change. Request the testing plan, including which tenants, browsers and data sets are used for cross-tenant checks. Confirm which deliverables are one-time, such as the initial theme and the security review, and which recur, such as retesting after each Superset upgrade or a retainer for support. Also ask what is excluded, who owns the source code and documentation after handover, and which decisions you must make before work starts.

How the written scope protects the brand and the data boundary

White-label work is scoped with its security checks from the start, not added as visual polish at the end. DeployOpen agrees scope, deliverables and timelines in writing before work starts. For embedded dashboards, that written scope should list the data-isolation and browser security checks alongside the theme work: which guest token resources and row level security rules are in place, how tenant filters are tested for leaks between customers, which Content-Security-Policy frame-ancestors values and font sources are allowed, and how cookie and CORS settings are verified for the host origin. A scope that covers only colors, logos and hidden navigation leaves the data boundary untested, and the reader should not accept one that does.

Ask for the scope to name each deliverable and the evidence that comes with it. For example, a theme configuration file, a list of the Superset navigation and logout elements removed, a record of the permalink domain and the fonts allowed by the CSP, and test results showing that a guest token for one tenant returns no rows from another. Confirm with the partner which of these checks run in a staging environment that mirrors your production identity provider, and who signs off before the embedded views are released. Also confirm what is excluded, such as custom visualization plugins or translations, since those are usually separate work items with their own timelines.

Support after launch is handled separately. Ongoing support, upgrades and continuous testing are available as retainers, which matter because each Superset release can change how theme tokens, embedded SDK options and browser security behavior work. No price list is published, so a quote follows from the written scope. When comparing quotes, check that each one states what is one-time and what recurs, which checks are included, and how a change to the scope is priced and approved. A quote that cannot be traced back to named deliverables should be questioned before it is compared on cost.

How DeployOpen delivers white-labeled Superset embeds

DeployOpen plans, builds, documents and supports self-hosted Apache Superset inside your own cloud accounts, data centers or air-gapped networks. For white-labeled embeds, we treat branding, navigation hiding, permalinks and browser security settings as one piece of work, so the embedded experience matches your product without weakening the controls that protect your data.

How we scope

Written scope lists each dashboard, chart and page that will appear embedded, with the branding elements in each.
We record which Superset navigation, logout and menu items must be hidden, and which remain available to internal users.
Fixed-scope engagements agree the permalink domain, font sources and CSP origins in writing before any build starts.

How we build

We apply theme and brand tokens to your embedded dashboards and test them against your product's light and dark modes.
We configure the permalink and embedding domain, then verify the CSP allows only the font and style sources you approved.
We test hidden navigation and logout behavior in each supported browser and check that no Superset chrome leaks through.

How we hand over

You receive a configuration record covering theme tokens, hidden elements, domains, font sources and CSP directives.
Documentation explains how to change branding safely, including which settings need a security review before release.
We walk your engineering and security teams through the test cases used to confirm the white-label result.

How we support

Ongoing support is available as a retainer, covering Superset upgrades that may change theme or embedding behavior.
Before each Superset upgrade, we retest branding, permalinks and CSP settings in staging, following the project's upgrade guide.
Continuous testing of embedded pages can be added to a retainer so regressions in branding or security headers surface quickly.

White-labeling embedded Superset dashboards