Why SaaS teams put Apache Superset in their own infrastructure
A product or data team that needs analytics for its own staff and for customers inside the product usually chooses self-hosted Apache Superset for two reasons. The project is released under the Apache License 2.0, and its packages and repository show no paid edition, so the licensing cost does not scale with users, dashboards or tenants. More important for a SaaS company, a self-hosted deployment lets you decide where tenant data is queried: in your cloud accounts, against your warehouses, with connections and credentials that never leave your environment. Before committing, confirm the license terms of every extension, theme or plugin you plan to add, since the core license does not cover them automatically.
Once customer-facing dashboards exist, access control stops being an internal administration task and becomes part of the product. Internal analysts can be trusted with broad roles, but a customer who sees a dashboard must see only their own rows, and that boundary has to hold through embedding, public links, exports and cached results. In Superset this means designing row level security rules, the roles that apply them, and the guest token claims your application issues for each embedded session, then testing those paths together rather than one at a time. Ask your engineering team to write down which tenant identifier is authoritative, where it is set, and who can change it, because that decision will be examined in a SOC 2 assessment as well as in your own incident reviews.
Plan the evidence from the start. Auditors reviewing a SOC 2 will ask how access was granted, reviewed and removed, and how configuration changes were approved, so keep the role mappings, RLS definitions, upgrade records and access reviews in version-controlled or logged form instead of reconstructing them later. Confirm with your assessor which trust services criteria are in scope for your report and how they map to your Superset controls, because the security criteria apply to every SOC 2 while the other categories apply only when included. The AICPA's Trust Services Criteria are the reference your auditor will use to test these controls.
Internal product analytics and embedded customer dashboards are different builds
Internal analysts and customers viewing dashboards inside your product both use Superset, but they arrive through different identities and need different scoping. Treat them as two components with shared infrastructure, not one configuration with a few exceptions.
Internal analysts exploring product usage
Internal users are product managers, growth analysts and data staff who build charts on event tables and warehouse models. They sign in through your workforce identity provider, so group membership in that directory should map to Superset roles. Scoping is by dataset and role, with row level security where analysts may see only some accounts or regions. What breaks when this fails is usually over-broad SQL Lab access, where an analyst can query tables that were never meant for them. Check which roles can run SQL, export data and create datasets before anyone is added.
Customers viewing embedded dashboards
Customers are external users who never hold a Superset login. Your application requests a guest token for each session, and that token names the dashboard and carries the filter values that limit rows to one tenant. Scoping depends entirely on the token claims and the RLS rules behind them, so a missing or wrong tenant filter exposes another customer's data. Confirm that the backend, not the browser, creates tokens, and that tokens are short-lived and bound to a single dashboard.
Identity paths that must stay separate
Analysts sign in through OAuth2 or LDAP, while embedded customers need no Superset account and should never be placed in an internal role. Keep these paths apart in configuration so a customer session cannot reach the Superset interface, and so an internal group change does not grant a customer any extra rows. Document which identity provider and role mapping serves each audience, and test that a guest token cannot open the main application.
Tenant isolation in shared datasets
Most SaaS companies query one shared warehouse table with a tenant column. Row level security is the control that separates tenants, and it has to be applied to every dataset a dashboard touches, including datasets used by charts inside the same dashboard. A chart that joins a second dataset without its own rule can leak rows that the dashboard filter hides visually. Test each chart with two tenant identifiers and compare the results at the query level, not only on screen.
Cached results across tenants
Caching speeds up dashboards for customers, but a cache keyed only on dashboard and chart can return one tenant's data to another. Cache keys must reflect the RLS filters and guest token claims, and the caching layer and worker components used for async queries need the same isolation review as the web tier. Ask your team how cache entries are keyed for embedded sessions and what happens after a customer's data is deleted.
Evidence for SOC 2 reviewers
Auditors testing a SOC 2 will ask who can see customer data through each path and how that access was approved, changed and removed. Internal access evidence comes from role assignments, group mappings and access reviews. Embedded access evidence comes from the token issuing code, its configuration, and test results showing tenant separation. Keep the two evidence sets separate in your control matrix, because a single report for both audiences will not show how each one is governed.
Which SaaS requirements shape the Superset build
This table maps each SaaS requirement to its source and to the Superset build decision it forces, covering roles, row level security, the metadata database and upgrades. Read each row as a question to answer before the build starts, not as a finished design. The main takeaway is that tenant isolation and SOC 2 access evidence both depend on decisions made early in roles and RLS.
| Requirement | What it asks for | What it means for the Superset build |
|---|---|---|
| Tenant isolation | Customers see only their own data in internal and embedded analytics | Define roles and row level security rules per tenant before dashboards are built, and test them with non-admin accounts. Confirm how embedded guest tokens scope each viewer to a tenant. |
| SOC 2 CC6 access controls | Logical access is restricted, granted on need, and reviewed under the AICPA 2017 Trust Services Criteria | Map Superset roles and group mappings to documented access rules, keep role assignment changes traceable, and collect access review evidence for the audit period. |
| GDPR Article 28(3) processor terms | Processing only on documented instructions and Article 32 security measures | Where Superset processes customer personal data for you, document the instructions in the processor contract and align the metadata database, logs and cached results with those terms. |
| EU Data Act switching rights | Customers can switch to another provider or to on-premises infrastructure, with switching charges ending from 12 January 2027 | Keep dashboards, datasets, roles and RLS rules exportable as configuration, and document the metadata database contents so a move to another instance stays practical. |
| Cyber Resilience Act for software products | Products with digital elements, including software, must meet CRA obligations; the regime applies from 11 December 2027 | If you ship Superset-based features as a product, plan vulnerability handling and patch records, and confirm with counsel which conformity assessment module applies. |
| Metadata database choice | Production metadata database on a tested engine, not the SQLite default | Use PostgreSQL or MySQL in a supported version range, with backups taken before every upgrade, since the metadata database holds roles, RLS rules and dashboard definitions. |
| Upgrade planning | Controlled version changes with staging tests and breaking change review | Plan upgrades around UPDATING.md, run superset db upgrade and superset init in staging first, and schedule releases so customer-facing dashboards are not exposed to untested changes. |
How row level security and guest tokens isolate tenants
A single dataset serves every tenant, and row level security (RLS) filters rows at query time based on a clause tied to the tenant identifier. This keeps one set of charts, one database connection and one upgrade path, so operating effort stays low as tenant count grows. The main risk is that isolation depends on every query path honoring the filter, so a chart, saved query or SQL Lab session built without the clause can expose other tenants' rows.
- Filter design: Define the RLS clause against a tenant key that the application sets in the guest token, not against a value a user can edit in the browser.
- Coverage gaps: Check every dataset, virtual dataset and chart that touches the shared table, since a missing rule on one of them is a leak path.
- Database role: Give the Superset database user only the privileges it needs, so the warehouse cannot bypass the filter through other routes.
- Test accounts: Log in as at least two tenant accounts and confirm each sees only its own rows across dashboards, filters and exports.
- Change control: Treat RLS rule edits as access changes that go through review and are logged.
Before you rely on this model, confirm the current RLS and guest token behavior in the Superset documentation for your release, and record the test results as evidence.",
Each tenant gets its own dataset or database schema, so the warehouse itself separates rows by location rather than by a filter. This reduces the chance that a missing RLS clause exposes data, because a tenant's queries never reach another tenant's tables. The cost is operational: each new tenant means new datasets, dashboards, permissions and sometimes schema provisioning, and changes to a shared chart must be repeated across copies.
- Provisioning automation: Script dataset and dashboard creation so onboarding does not depend on manual clicks, and keep the scripts under version control.
- Drift control: Compare definitions across tenants on a schedule, since a chart edited for one tenant can silently diverge from the rest.
- Warehouse permissions: Use separate database roles per tenant or schema group, and confirm that one role cannot read another schema.
- Upgrade effort: Estimate how many copies a version upgrade must touch and ask your partner to size that work in the written scope.
- Metadata isolation: Confirm which Superset roles can see datasets belonging to other tenants, because metadata visibility can leak tenant names and table structures.
Ask your partner to show how provisioning, drift checks and warehouse role tests will be verified before you commit to this model for a large tenant base.",
A dedicated Superset deployment for each tenant places metadata, users, roles, caches and embedding keys in a separate boundary. A fault, misconfiguration or compromised account in one tenant's instance cannot reach another tenant's metadata. The trade-off is the heaviest operating load: each instance needs its own database, secret key, upgrades, backups, monitoring and certificates, and cost grows with every tenant added.
- Platform tooling: Plan automated deployment, configuration and upgrade pipelines so the instance count does not multiply manual work.
- Secrets per instance: Each instance needs its own SECRET_KEY and embedding secrets, so a leak in one tenant does not expose the others.
- Upgrade coordination: Stagger upgrades across instances and keep a documented rollback for each, using the upgrade guidance in the Superset documentation.
- Shared components: Decide which components, such as the caching layer and workers, may be shared and how that affects tenant separation.
- Operational evidence: Auditors will ask how instance configuration is kept consistent, so keep configuration as code and test each instance's guest token settings.
Confirm the instance-level configuration and guest token settings against the current Superset documentation before rollout, and test embedded sessions with real accounts from each tenant.",
Configuration that matters in a SaaS Superset
In a multi-tenant product, a few Superset settings decide whether one customer can see another's data and whether the platform stays up under load. The cards below cover the secrets, identity mapping, metadata database, background processing and database privileges that tie tenant isolation to the configuration you deploy and can verify.
SECRET_KEY set and rotated
Superset requires a user-specified SECRET_KEY to start, and it signs sessions and other security-sensitive values. A default or shared key across environments means anyone holding that key can forge trust in your deployment. Store the key in your secrets manager, generate it per environment, and plan rotation using PREVIOUS_SECRET_KEY so existing sessions survive the change. Verify that staging and production keys differ and that rotation has been rehearsed.
AUTH_ROLES_MAPPING from identity groups
AUTH_ROLES_MAPPING translates groups from your LDAP directory or OAuth provider into Superset roles. In a SaaS product, a mapping that grants broad roles to a loosely defined group can expose customer dashboards to staff who should not see them. Map only named, owned groups, keep customer-facing and internal roles separate, and confirm that removing a user from a group removes their access on next login.
PostgreSQL or MySQL metadata database
The metadata database stores dashboards, users, roles and embedding configuration, so it holds the access model itself. Superset is tested with PostgreSQL and MySQL, and the SQLite default and the Docker Compose PostgreSQL container are not recommended for production. Confirm that your engine falls within the supported versions, that backups are tested before every upgrade, and that the database is not shared with other applications.
Caching layer and Celery workers
Alerts, reports, async queries and dashboard thumbnails depend on the caching layer and Celery worker and beat processes, and most installations run Redis and Celery for them. For a SaaS product, a single shared worker pool lets one tenant's heavy scheduled reports slow every other tenant. Size the workers for peak report load, isolate queues where possible, and verify that scheduled deliveries reach only the recipients the tenant's roles allow.
Database user privileges
Each database connection in Superset runs queries with the privileges of the account you configure, and row level security filters only what Superset generates. A connection that uses a warehouse account with broad read access can return rows that no Superset filter hides when someone writes raw SQL. Create a read-only account per connection, grant it only the schemas each tenant group needs, and test that the account cannot write or read outside its scope.
Rolling out internal analytics first, then customer-facing dashboards
This sequence proves the data model, identity mapping and tenant isolation on internal users before any customer sees a dashboard. Each phase closes with a check that gates the next one, so customer exposure starts only after the controls have been tested.
Map data sources and the tenant model
The product, data and security owners list which analytics databases Superset will query, which tables hold tenant identifiers, and how each customer's data is separated. Engineering confirms the tenant key on every table and records where a row could leak across tenants. The step is done when the team signs off a written tenant model that names each data source, its owner and its isolation method.
Stand up a non-production Superset instance
The platform team installs Superset in a non-production environment with PostgreSQL or MySQL as the metadata database, since the SQLite default is not recommended for production. Redis and Celery are added if alerts, reports, async queries or thumbnails are in scope. The step closes when the instance starts with a user-specified SECRET_KEY, connects to a test copy of one analytics database, and renders a sample chart.
Map identity provider groups to Superset roles
The identity team connects Superset login to the company's OAuth2 or LDAP directory and maps groups to Superset roles with AUTH_ROLES_MAPPING. Internal staff roles are kept separate from any service or embedding account used later. The step is complete when test users from each group log in and see only the datasets and dashboards their role allows.
Design row level security and guest tokens
The security and data engineering teams write row level security rules that filter each dataset by tenant, and design how the embedding backend issues guest tokens that carry the tenant claim. Tests confirm that a token for one tenant cannot return rows belonging to another, including through filters, drill-downs and exports. The step closes when the rules and token design are reviewed and every test case passes against dedicated tenant test accounts.
Run staging embed tests with tenant test accounts
Engineers embed the target dashboards in a staging copy of the customer application using the test tenants and exercise the full path from login to rendered chart. They check browser security settings, cross-tenant access attempts and the behavior of expired or tampered tokens. The step is done when the test results are archived as evidence and any failures have been fixed and retested.
Pilot with a controlled group of customers
The product team enables embedded dashboards for a small, agreed set of customers, with the pilot scope, support contacts and rollback steps written down beforehand. Support and engineering monitor query load on the warehouse, access logs and any tenant-related tickets during the pilot. The step closes when the pilot owners review the results and approve or stop the wider release in writing.
Promote to production with backups and monitoring
The platform team deploys the approved configuration to production, with the metadata database backed up before the release and monitoring in place for web, worker and database health. Secret key handling and the upgrade routine are documented: back up the metadata database, run superset db upgrade and superset init, test in staging, and review UPDATING.md for breaking changes. The step is done when a restore from the backup has been tested and the runbook is handed to operations.
What SOC 2 evidence a Superset deployment can produce
A SOC 2 examination is judged against the AICPA 2017 Trust Services Criteria, and the security common criteria CC1 to CC9 apply to every SOC 2 report regardless of which other categories are in scope. For a Superset deployment, the evidence that matters most sits under the logical access criteria (CC6), change management (CC8) and monitoring of system operations (CC7). A Type 1 report describes the system and whether controls were suitably designed as of a single date, while a Type 2 report adds an opinion on whether those controls operated effectively over a period. SaaS teams should decide early which report they need for customer due diligence, because a Type 2 depends on evidence collected continuously from the first day of the observation window.
On the access side, Superset can produce role definitions and their assignments through its Flask-AppBuilder security model, group-to-role mappings from the OAuth or LDAP provider (configured with AUTH_ROLES_MAPPING), row level security rules per dataset, and the list of users and their status exported from the metadata database. Change evidence comes from the infrastructure-as-code repository that holds superset_config.py, the container image tags deployed, and the staging test records kept under the upgrade procedure. Logging evidence depends on the audit and event logs you enable, the retention of web and worker logs, and the access controls on the metadata database. Confirm with your auditor which populations and samples they will test, and confirm that each source is retained for the full period.
DeployOpen prepares the system, controls and evidence for a SOC 2 examination, including access reviews, change records and log retention, but it does not issue the report. The attestation is performed by a CPA firm, which obtains written representations from management and forms the opinion. Your own team owns the controls, the policies and the quarterly reviews those controls depend on, and the auditor will ask for proof that they ran. Before scoping the build, ask the auditor which Trust Services categories beyond security they expect to include, and whether a customer-facing embedded dashboard changes the system boundary, since guest token configuration and tenant isolation are then part of what gets examined.
What buyers ask before hiring help for Superset in a SaaS product
What drives the effort of an embedded Superset build for a SaaS product?
The biggest drivers are how many tenants the product serves, how tenant boundaries are enforced, and how much of the embedding flow is new to your team. Each embedded dashboard needs a guest token issued by your backend, row level security rules that limit data per tenant, and a decision on whether viewers share one dataset or use per-tenant datasets. Browser security settings, branding, and the number of charts and datasets add work too. So does testing that one tenant cannot see another tenant's rows through filters, cached results or exports. Expected end-user concurrency shapes caching and worker design, so include it in scope. Ask any partner to list each driver as a line item with its test plan.
Can our internal team deploy and run Superset for embedding without outside help?
Often yes, if the team already runs Python web services, PostgreSQL, Redis and containers, and has someone who has built token-based embedding before. Superset is licensed under the Apache License 2.0 with no paid edition, so the costs are mainly people, infrastructure and any support you buy. The steps that tend to need more than general engineering skill are tenant isolation design, RLS testing and staged upgrades that follow the breaking change notes in UPDATING.md. Deployment choices may also shift, since the current development documentation marks the Helm chart as deprecated. Confirm who owns the metadata database and SECRET_KEY, who runs upgrades, and who reviews tenant tests. Base the decision on a written skills list and an honest count of available time.
What does the work need from our engineers and security staff?
Your engineers and security staff stay involved throughout, and their time belongs in the scope. Typical needs include:
- Backend engineers to issue guest tokens from your application, map tenant identifiers to RLS rules and handle session expiry.
- Platform engineers to provide the metadata database, Redis, Celery workers, secrets storage, ingress and backups in your environment.
- Security staff to approve the SECRET_KEY process, authentication setup, export controls, logging and the evidence for tenant separation.
Confirm named owners, review dates and sign-off steps in writing before work starts.
How long does a SOC 2 Type 2 observation period run?
The period is set by your service auditor and agreed with your organization, so confirm its length with your auditor before planning. A Type 1 report covers the system description and control design as of one date, while a Type 2 report adds an opinion on operating effectiveness over a period. Controls must operate throughout that window, and evidence such as access reviews, change tickets and backup logs has to exist for the whole time. DeployOpen prepares the Superset systems, controls and evidence for that period, but it does not issue the report. An independent CPA firm does. Ask your auditor which trust services categories are in scope and how they will sample evidence. The AICPA SOC 2 overview explains the report types.
What does the EU Data Act mean if we later switch hosting providers?
The Data Act governs data processing service providers, so its main effect is on the cloud or hosting provider you contract with, not on Superset, which is open-source software you run. Where a provider is in scope, Regulation (EU) 2023/2854 has applied since 12 September 2025. It requires providers to let customers switch to another provider or to on-premises infrastructure, with a maximum two-month notice period and a 30-day transitional period. From 12 January 2027, providers may not impose switching charges. For Superset, a move involves the metadata database, configuration, dashboards as code, datasets and user accounts. Ask counsel to confirm whether your hosting contract is in scope.
How does a quote follow from a written scope for a Superset engagement?
A quote follows from a written scope, and DeployOpen does not publish a price list. Most engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts. To compare proposals, ask each provider to state:
- The deployment target, number of tenants, datasets and expected users.
- Which embedding, RLS, SSO and logging items are included, and which your team owns.
- The acceptance tests, including tenant isolation tests, and the evidence delivered.
- One-time work separated from recurring items such as upgrades, monitoring and retainer support, plus who pays for cloud infrastructure.
Ongoing support, upgrades and continuous testing are available as retainers, so request them as separate line items.
Running Superset as a product dependency after launch
Once Superset backs customer-facing dashboards, every upgrade is a change to a product dependency, so the first rule is that no version moves to production without a staging run. Before each upgrade, back up the metadata database, run superset db upgrade and superset init against a copy of production, and read UPDATING.md for breaking changes between the versions involved. Your staging check should replay embedded dashboards with guest tokens and RLS filters, since those paths break quietly while internal charts still render. The Superset upgrade documentation sets out this sequence, and your team should own a written rollback plan that includes restoring the metadata database.
Monitoring has to cover the optional components too. Alerts and reports, async queries and dashboard thumbnails depend on the caching layer and Celery workers, so a stalled worker can look like a healthy web tier while scheduled customer reports silently stop. Track worker queue depth, failed report runs and the health of Redis, and confirm alerting for each. Tenant administration is also recurring work: onboarding and offboarding customers means creating roles, RLS rules, and guest token issuance logic that must be reviewed whenever the data model changes. Confirm with your engineers who approves those changes and how removed tenants are verified to have lost access.
Plan your deployment tooling with the maturity of each option in mind. The Helm chart is documented for Kubernetes installs in the 6.1.0 docs, but the current development documentation marks it as deprecated and points new deployments to the Apache Superset Kubernetes Operator. That operator is in alpha with a v1alpha1 API whose custom resource schemas may change between releases, so ask your platform team to confirm the chart or operator path for your version before go-live, and budget for manifest changes on every upgrade. Keep backups of the metadata database on a tested schedule, since it holds dashboards, roles and tenant configuration that customers depend on.
How DeployOpen works on this
DeployOpen plans, implements, hardens, documents and supports self-hosted Apache Superset inside your own cloud accounts or data centers. For SaaS and technology companies, we scope the internal analytics and embedded tenant model together, so row level security, guest tokens and evidence for SOC 2 reviews are designed before the build begins.
How we scope
- We map which dashboards are internal product analytics and which are embedded in customer-facing products.
- We document the tenant model, row level security rules and the roles each group needs before any build starts.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.
How we build
- We deploy Superset with a production metadata database, caching and workers in your infrastructure, not the SQLite default.
- We configure identity mapping, embedded guest token flows and browser security settings, then test tenant isolation against defined cases.
- We run security tests on the embedded surface and the SQL execution paths before release.
How we hand over
- You receive architecture notes, configuration records, runbooks for upgrades and backups, and the access control matrix.
- We prepare control descriptions and evidence for the Trust Services Criteria areas in your SOC 2 scope, for your auditor to test.
- DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or attestations.
How we support
- Ongoing support, Superset upgrades and continuous security testing are available as retainers.
- Upgrade work follows the project's guidance: back up the metadata database, run the documented upgrade steps and test in staging first.
- Ask for the support scope, response expectations and upgrade plan in writing as part of your quote.
