Apache Superset for the public sector: what changes for agencies
Agencies that run Superset need two different answers from one platform: public dashboards that anyone can open, and internal reporting on sensitive records that only named staff may see, sometimes on networks with no internet path at all. A self-hosted deployment of Apache Superset, released under the Apache License 2.0 with no paid edition, lets the agency keep both on infrastructure it controls, with the source code available for review. That licensing and hosting model suits the split, but it is a starting point, not an authorization. The Apache Software Foundation project does not provide certification, accreditation or data classification. Those remain the agency's job, carried out against its own system boundary, impact level and control catalog, with independent assessors where the program requires them.
The design change from a commercial deployment is that the public and internal workloads should not share a Superset instance, metadata database or role model. Plan separate instances or at least separate tenants with their own SECRET_KEY values, database connections and access policies, and treat anything served publicly as a deliberate export of data that has already been cleared for release. Row level security and role mapping must be tested against the agency's actual groups, since AUTH_ROLES_MAPPING only maps what the identity provider sends. Confirm with your security office which data categories may leave the internal instance and who approves each published dashboard.
Restricted networks change the build as much as the access model. Before installation, confirm which Python packages, container images and chart dependencies you can mirror into the enclave, and whether the metadata database, caching layer and Celery workers can run without outbound calls. The architecture documentation makes Redis and Celery workers necessary for alerts, reports and thumbnails, so each of those components needs its own approved hosting and patch path. Ask your assessor early which NIST SP 800-53 control families apply to the system, and write the evidence plan (configuration baselines, logs, patch records and upgrade tests) around the upgrade steps in the project's documentation.
Which public sector requirements shape an Apache Superset build
This table lists the federal, criminal justice, defense and accessibility requirements that most often shape a Superset build for agencies, with the source of each and what it means for design. Applicability is decided by the agency's authorizing official and auditors, so treat each row as a question to confirm, not a finding.
| Requirement | Source and what it asks | What it means for the Superset build |
|---|---|---|
| NIST SP 800-53 Rev. 5 baselines | NIST federal control catalog; SP 800-53B low, moderate and high baselines select 149, 287 and 370 controls and enhancements (Release 5.2.0) | Confirm the system impact level with the agency first, then map Superset controls to that baseline. Each baseline needs its own evidence set. |
| FISMA and OMB Circular A-130 | Federal law and policy behind SP 800-53; Inspectors General independently assess agency system security and report to OMB | Expect an independent assessor to test Superset controls directly. Keep configuration, change and access records ready for that review. |
| CJIS Security Policy v6.1 | FBI rules for criminal justice information, effective 26 June 2026; FIPS 140-3 modules or AES-256 keys and at least monthly vulnerability scanning | If CJI reaches Superset, confirm the encryption modules and key sources for the database connection, TLS and storage, and schedule scanning evidence. |
| 32 CFR 2002.14(h)(2) for CUI | Federal agencies must use NIST SP 800-171 for CUI on non-federal systems unless the CUI category sets other safeguards | If a contractor or partner hosts Superset with CUI, the safeguards follow SP 800-171 requirements set by the agency. Confirm the CUI category first. |
| FedRAMP scope for cloud services | Applies to cloud services that create, collect, process, store or maintain federal information for an agency, per OMB M-24-15 scope | A hosted or shared Superset service handling federal data may be in scope. A system run only for one agency on its own cloud infrastructure may be out of scope. Confirm with the agency. |
| WCAG 2.1 Level A and AA (ADA Title II) | Applies to state and local government web content, including content from contracts, from 26 April 2027 for large entities and 26 April 2028 for smaller ones | Public open-data dashboards and embedded charts need accessible colors, labels, keyboard use and text alternatives. Ask the agency which entity size date applies. |
Apache Superset settings agencies must set before sensitive data loads
Superset's defaults suit a trial, not a government system holding sensitive records. The cards below cover the settings that decide where metadata lives, how users sign in, what data each role can see, and how exports leave the platform. Each one needs an owner inside the agency before any sensitive dataset is connected.
Metadata database choice
Superset stores dashboards, users, roles and connection definitions in a metadata database. The SQLite default used by Quickstart and PyPI installs is not recommended for production, so the agency should choose PostgreSQL or MySQL within the supported versions and run it on infrastructure with tested backups. Ask who owns that database, where its backups are kept and how restores are rehearsed before accreditation.
Secret key and rotation
Superset refuses to start without a user-specified SECRET_KEY, and the key signs sessions and encrypts stored credentials. Agencies should generate it in their own secrets tooling, keep it out of version control and document who can read it. When the key must change, PREVIOUS_SECRET_KEY lets the instance keep working during rotation, so the rotation procedure should be written and tested in staging first.
Sign-in and group-to-role mapping
Local accounts are a weak fit for an agency workforce. Superset supports OAuth2 with providers such as Azure and custom OAuth2 servers using the code flow, as well as LDAP. AUTH_ROLES_MAPPING translates directory groups into Superset roles, so the agency must supply its directory, group naming, certificate chain and a list of which groups may hold Admin rights. Test that a leaver loses access the same day their directory account is disabled.
Role and row-level data access
Roles decide which dashboards, datasets and databases a user can open, while row-level security filters the rows returned from a shared dataset. For sensitive records, such as case files or benefit data, each filter needs a named data owner who signs off on the predicate. Build the role model from the agency's need-to-know rules, then verify with test accounts that a user outside a program cannot reach its data through a chart, a saved query or an export.
Export and download controls
Charts, dashboards and SQL Lab results can leave Superset as CSV, Excel or image files, which can move regulated data outside the approved boundary. Agencies should decide which roles may export, whether SQL Lab results may be saved, and how scheduled reports are delivered and to which addresses. Record these decisions in the system security plan so an assessor can trace each export path to a documented owner.
Caching, workers and report delivery
Alerts and reports, async queries and dashboard thumbnails depend on a caching layer and Celery worker and beat processes, usually Redis and Celery. Each component adds a service to patch, monitor and include in the boundary, and scheduled reports can carry data to recipients. The agency should confirm who operates these services, which network segments they reach and which report recipients are approved.
Separate public open-data content
Public open-data dashboards and internal reports on sensitive data should not share a Superset instance, a role model or a database connection. A separate instance keeps public publishing, public dashboards and anonymous access away from internal datasets and reduces the risk of a misconfigured role exposing records. The agency should decide the boundary early, assign each dashboard an owner and confirm that public content meets its accessibility obligations.
Separating public open-data dashboards from internal sensitive reporting
Agencies usually keep published open-data dashboards apart from internal reporting on personal, case or law enforcement records because the two carry different exposure if something goes wrong. A public dashboard is reachable by anyone, so a single misconfigured role, cached result or export setting can publish data that was never meant for release. Separation puts the public content on its own Superset instance with its own metadata database, its own SECRET_KEY, and its own connections to read-only, publication-approved datasets. Internal reporting stays on a separate instance behind the agency's identity provider, where role mapping and row level security can be audited on their own. Before any build work, the team should settle three questions: which datasets are public by law or policy, which databases hold restricted fields such as identifiers, case notes or CJI, and who signs off on each publication. Those answers decide how many instances exist and which database accounts each one uses.
The split also changes caching and export behavior, which teams often overlook. Caching and alerts depend on the caching layer and Celery workers described in the Superset architecture documentation, so a shared Redis or worker pool can let a cached result from an internal chart surface on a public page if keys or databases are not isolated. Export settings, CSV downloads, scheduled reports and thumbnails should be switched off or restricted on the public instance and reviewed on the internal one. Public pages also carry accessibility obligations. Under the ADA Title II rule, state and local government web content must meet WCAG 2.1 Level A and AA from the dates set for the entity's size, and that duty extends to content provided through contracts or licenses. Agencies should ask the Apache Software Foundation project, and their own accessibility staff, what the current Superset accessibility posture is, then test the public dashboards with assistive technology before launch.
Apache Superset deployment options by network model
This model fits an agency that operates its own cloud account or data center and can reach package registries and container sources directly or through an approved egress path. The install can follow the standard Superset path, with a container image or PyPI package, a PostgreSQL or MySQL metadata database that the agency runs, and optional Redis and Celery workers for alerts, reports and async queries.
- Install method: Container or PyPI install on servers or Kubernetes, with the metadata database set to PostgreSQL or MySQL in a supported version rather than the SQLite default.
- Updates and scanning: Upgrades pull from the project's release channels, so the agency should confirm which release sources its egress rules allow and how image scanning is scheduled.
- Secrets and keys: Store the required SECRET_KEY and database credentials in the agency's secrets manager, and plan a rotation that uses PREVIOUS_SECRET_KEY.
- Kubernetes choice: Decide between the official Helm chart and the Apache Superset Kubernetes Operator before the build. The operator is alpha with a v1alpha1 API, so production use needs a plan for schema changes between releases.
Confirm with the agency's security team which egress paths are approved and who owns the upgrade calendar before the first deployment.
This model fits agencies whose hosts have no general internet route but can reach internal package mirrors, an internal container registry or a proxy for approved sources. Superset is installed from mirrored artifacts, so the mirror becomes part of the supply chain that the agency must govern.
- Install method: Build or pull the image into an internal registry, then install from an internal PyPI mirror or the registry copy, pinning the release that was tested in staging.
- Updates and scanning: Mirror each new release and its dependency set after review, and run the scanning and vulnerability checks against the mirrored copy, not against the public source.
- Secrets and keys: Keep SECRET_KEY, database passwords and OAuth client secrets out of image layers and mirrored build files, and inject them at runtime.
- Operator status: Treat the alpha operator as a candidate for lab or non-production clusters unless the agency accepts the risk of schema changes between releases and has a tested rollback.
Confirm which mirror tools and proxy rules the agency already operates, and whether the mirror keeps a record of what was approved and when.
This model fits enclaves with no route to external networks, where images, packages and documentation move in through approved media and a documented transfer process. The install is fully offline, so every dependency, base image and scanner database must be staged before the change window opens.
- Install method: Assemble a transfer bundle with the Superset image, Python dependencies, database drivers and deployment manifests, then install from the enclave registry and package store.
- Updates and scanning: Each release needs a new transfer, a new scan on the enclave side and a documented approval record. Confirm how vulnerability data reaches the enclave, since public feeds are not reachable.
- Secrets and keys: Generate SECRET_KEY and database credentials inside the enclave, never on the transfer media, and rotate them under the same change control as other enclave credentials.
- Kubernetes choice: Prefer the Helm chart path if the enclave team needs a more established install method, and keep the operator in a test cluster until its v1alpha1 schemas are stable for the agency's release cadence.
Confirm with the enclave owner which media, approvals and scan tools are permitted before scoping the transfer bundle.
Kubernetes is the one environment where the agency must choose between two install paths. The Superset 6.1.0 documentation describes the official Helm chart, while the current development documentation marks that chart as deprecated and points new deployments to the Apache Superset Kubernetes Operator. The operator is built with the Go Operator SDK, is in alpha and uses a v1alpha1 API whose custom resource schemas may change between releases.
- Helm chart path: Matches the 6.1.0 documentation, so it is easier to align with a documented release, but the current docs mark it deprecated for new installs.
- Operator path: Matches the current development direction, but its alpha status means custom resource changes can arrive between releases.
- Impact on upgrades: Whichever path is chosen, the upgrade plan must back up the metadata database, run the documented upgrade steps and test in staging first.
- Documentation: Record the chosen path and the reason in the architecture decision record, so auditors see a deliberate decision.
- Re-evaluation: Plan a review point before each Superset major upgrade, since the install path may change.
Confirm which path the agency's platform team will support for the full lifecycle, not only the first install.
Which NIST SP 800-53 control areas Superset evidence supports
A well-configured Superset deployment produces records that map to several NIST SP 800-53 control families. The cards below show which areas those records support, what each one looks like in practice, and what to check before you hand evidence to an assessor. NIST does not certify tools, and independent assessors decide whether controls are met in your system.
Access control and least privilege
Superset roles, permissions and row-level security (RLS) rules determine which datasets, dashboards and rows each user can see. The role definitions, RLS filter clauses and access reviews are the evidence for AC-2 and AC-3 style controls. Check that roles follow need-to-know, that no broad admin role is used for daily work, and that RLS filters are tested against real user accounts before go-live.
Identification and authentication
Login through your directory, using OAuth2 or LDAP, means user identity is established by your authoritative source rather than local Superset accounts. Group-to-role mapping through AUTH_ROLES_MAPPING produces the record of who holds which role and why. Confirm that local fallback accounts are disabled or tightly controlled, and that deprovisioning in the directory removes Superset access.
Audit and accountability
Superset's event and audit logging, combined with logs from the web tier, the metadata database and the reverse proxy, shows who viewed, exported or changed content and when. These records support the audit and review controls in the AU family. Decide where logs are shipped, how long they are retained and who reviews them, because an assessor will ask for samples and review evidence, not just a logging setting.
Configuration management and change control
Dashboards, datasets and configuration managed as code, plus staged upgrades, give change records under the CM family. Before each upgrade, back up the metadata database, run the migration in staging, and read UPDATING.md for breaking changes. Keep the test results, approvals and rollback plan together so each change has a traceable record.
System and information integrity
Patching records, dependency scans and scheduled vulnerability scans of the Superset image and host support the SI and RA families. Track which Superset release runs in production, when it was last patched, and what the scan results showed. Note that Superset is released under the Apache License 2.0 with no paid edition, so patch timing depends on your own process and on the project's release cadence.
Cryptographic protection and secret handling
Encrypted connections between users, Superset and the metadata database, along with a user-specified SECRET_KEY and documented rotation using PREVIOUS_SECRET_KEY, support the SC family, including SC-13 and SC-28. Confirm that TLS settings, key storage and database credentials meet the cryptographic standards your authorizing body requires, such as FIPS-validated modules where they apply, and record how keys are generated and rotated.
How a public sector Apache Superset rollout moves from pilot to production
This sequence moves a Superset deployment from an agreed control baseline to a cut-over with a tested rollback, with each approval recorded before the next phase starts. The agency's own review cycles set the pace, not a vendor timetable.
Confirm data classification and baseline target
The agency's security office confirms which datasets Superset will query, how each is classified, and which control baseline applies to the system. This is where the authorizing official, privacy office and procurement team are identified and their sign-off points are written down. Scope decisions also cover whether any dataset is controlled unclassified information or criminal justice information, since those bring their own requirements. The step closes with a signed scope statement and a sign-off calendar that follows the agency's review cycles, not a vendor timetable.
Build a staging instance on the approved platform
The implementation team builds a staging Superset on the infrastructure the agency has approved, using the metadata database and optional caching and worker components the design calls for. The team confirms the metadata database version is on the supported list in the configuration documentation, generates a unique SECRET_KEY, and records the exact Superset release in the build record. The step closes when staging starts cleanly, the build matches the approved bill of materials, and the security office accepts the hosting boundary in writing.
Integrate identity and map roles
The team connects Superset login to the agency's approved identity provider or directory and maps groups to Superset roles through the documented group mapping setting. Each role is tied to a named access need approved by the data owner, and no role is granted by default. The step closes with a role matrix that lists each group, its Superset roles, and the datasets it can reach, reviewed and approved by the agency before any real user logs in.
Load one public and one restricted dataset
The team connects one dataset that is approved for public release and one restricted dataset, each through a database account with the least privileges its queries need. Row-level security and dataset permissions are applied to the restricted data and tested against the role matrix. The step closes when the data owner confirms the loaded fields match the approved classification and the restricted dataset is invisible to users outside its approved groups.
Run access and export tests
Testers work through the role matrix with test accounts for each group and try to reach data they should not see, including through direct chart URLs, saved queries, exports, scheduled reports and any public dashboard setting. Each result is logged with the test case, expected result, actual result and retest outcome. The step closes when every failed case is fixed and retested, and the security office signs off on the evidence package. This evidence feeds the assessment work, but DeployOpen does not issue audit reports or certifications.
Complete a documented upgrade rehearsal
The team copies the staging metadata database, applies the planned upgrade in a separate rehearsal environment, and follows the project's upgrade steps: back up the metadata database, run the database upgrade and initialization commands, and review the release's breaking-change notes in UPDATING.md. Before rehearsal, the team confirms the release path with the vendor's current documentation. The step closes with a written runbook that records timings observed in the rehearsal, the checks that passed, and the steps that needed changes.
Cut over with a tested rollback plan
The team schedules the production cut-over within the agency's approved change window and runs the verified runbook with a named operator and approver for each step. The rollback plan restores the pre-cut-over metadata database backup and the previous container or package version, and it is rehearsed before the window opens. The step closes when production passes the smoke tests, the change record is signed by the agency, and the rollback was either unused or documented if it was used.
Hand over operations and evidence
The agency receives the runbooks, role matrix, test evidence, backup and restore records, and the list of open risks with owners. Operators are trained on user administration, backups, and the upgrade process so that day-two work stays with the agency's team or a retained support provider. The step closes with a handover acceptance signed by the agency's system owner, which marks the system as in production under the agency's own governance.
Keeping an agency Superset patched without breaking reports
The project's upgrade guidance sets the order of work: back up the metadata database first, then run superset db upgrade and superset init, and test the result in staging before production. Before any move, read UPDATING.md for breaking changes between your current and target versions. For an agency, the metadata database holds dashboards, charts, roles and the row level security rules that protect sensitive data, so a backup is also the recovery point for your access model. Confirm that backups are encrypted, stored off the application host, and restored successfully in a test environment at least once before you rely on them. The upgrade guide is the authoritative source for these steps, so cite it in your change records.
Release timing shapes the plan. According to PyPI, Apache Superset 6.1.0 was published on May 13, 2026, and the GitHub releases page lists 7.0.0rc2 as a pre-release dated October 16, 2026. A release candidate is not a production target, so do not schedule a major move around it until a stable release is published and your own staging tests pass. Pin the exact version in your container image or package lock, and record the pinned version in your system security plan. Track security fixes as a separate stream from feature releases: review the project's release notes for each patch, decide within a set window whether it applies to your deployment, and test it on its own rather than bundling it with a feature upgrade. This keeps a critical fix from waiting on a larger migration, and it keeps your change history readable for assessors.
The operator is in alpha. The Apache Superset Kubernetes Operator is built with the Go Operator SDK, uses a v1alpha1 API, and its documentation says custom resource schemas may change between releases. The Helm chart is marked deprecated for new deployments. For a long-lived government system, that means you should not treat the operator as a stable foundation without a plan. If you use it, pin its version, keep your custom resource manifests in version control, and budget for rework at each operator release. Alternatively, confirm with your platform team whether a supported deployment method fits your authorization boundary. Either way, record the decision and the owner of the upgrade path, because an unmaintained deployment becomes an audit finding over time.
What does an agency Apache Superset deployment cost and need?
What drives the cost of an agency Superset deployment?
The cost is driven mainly by the network model, the number of data sources, identity integration, accessibility and evidence work, and the number of control baselines the agency must map to. A Superset deployment on a connected cloud account with one directory and two warehouses is a different job from an air-gapped deployment with row level security across several sensitive datasets. Ask any provider to price each driver separately in the written scope, so you can see which choices move the total. Superset itself is Apache-2.0 licensed with no paid edition, so the license is not a cost driver. The work is the platform build, the integrations and the evidence you must produce.
Which Superset costs are one-time and which recur?
One-time costs include discovery, architecture, the initial build, identity and database integration, branding or accessibility fixes, and the first evidence package. Recurring costs include Superset upgrades, vulnerability remediation, patching of the operating system and database tier, backup testing, access reviews and any support retainer. Superset upgrades follow the project's documented steps: back up the metadata database, run superset db upgrade and superset init, test in staging, and check UPDATING.md for breaking changes. Each upgrade cycle repeats that work, so ask for the upgrade effort to be stated separately from the build.
Can the agency's own staff run a Superset deployment after launch?
Yes, if the team has Linux, container or Kubernetes operations skills, a database administrator for the metadata database, and someone who owns Superset roles and data access. The metadata database must be PostgreSQL or MySQL in production, since the SQLite default and the Docker Compose PostgreSQL container are not recommended for production. Alerts, reports and async queries need the caching layer and Celery workers, so the operations team must also run Redis and workers. Agencies with a small platform team often keep the build with a partner and move day-two tasks in-house once runbooks and monitoring are in place.
What must the agency provide before a Superset build can start?
The agency must provide directory access for identity integration, a named owner for each dataset, a written access model that says who may see which rows and columns, and a sign-off authority for each stage. It must also provide network paths to the databases, the approved container or package sources for a restricted network, and access to the staging environment used for upgrade testing. Missing data owners are the most common reason build schedules slip, because role and row level security rules cannot be written without them. Confirm these responsibilities in the scope document before work begins.
How long does an agency Superset engagement take?
Duration depends on scope, not on a fixed template. The main variables are the number of data sources, whether the environment is connected or air-gapped, how many identity groups must map to roles, how many accessibility and evidence items must be produced, and how quickly the agency's data owners and approvers respond. Ask for a timeline that lists the discovery, build, test, staging upgrade rehearsal and handover phases with the dependencies between them. Be cautious of any timeline quoted before the access model and data inventory are written down.
How do NIST SP 800-53 baselines change the effort?
The baseline sets how many controls the evidence must cover. NIST's OSCAL profiles for SP 800-53B Release 5.2.0 select 149 items for the low baseline, 287 for moderate, 370 for high and 96 for the privacy baseline, counting base controls and enhancements together. Moving from low to moderate roughly doubles the number of items to map, which is why the target baseline should be fixed early. Note that SP 800-53 controls are not certifications. The agency's authorizing official and independent assessors decide whether the system meets them, and DeployOpen prepares the system, controls and evidence for that assessment.
What should an agency ask for in a fixed-scope Superset quote?
Ask for a written scope that lists the in-scope databases, identity providers, network model, deployment target, baseline and evidence items, and accessibility target. The quote should separate one-time build work from recurring upgrades, remediation and support, and state what the agency must provide. Ask which items are excluded, how change requests are priced, what acceptance criteria apply to each deliverable, and who signs off each phase. Ask how the provider verifies Superset upgrades in staging and what documentation the agency keeps after handover. DeployOpen does not publish a price list, so the written scope is the basis for any quote.
How DeployOpen works on this
DeployOpen plans, implements, hardens, documents and supports self-hosted Apache Superset inside the agency's own cloud accounts, data centers or restricted networks. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Written scope lists which dashboards, datasets and user groups are in the first release.
- Scope records the classification of each data source and the access model each dataset needs.
- Scope names the metadata database, identity provider, network zones and hosting environment the agency already operates.
How we build
- Deploy Superset on infrastructure you control, with PostgreSQL or MySQL as the metadata database and no SQLite in production.
- Configure roles, row level security and group mapping from your directory, then test access with named test accounts.
- Set the SECRET_KEY, caching and worker components, and verify alerts, reports and exports against the agreed requirements.
How we hand over
- Deliver a configuration record, role matrix, network diagram and access test results as written deliverables.
- Document the upgrade procedure, including metadata database backup, superset db upgrade, superset init and staging tests.
- Train your administrators on user onboarding, dashboard promotion and reviewing audit and event logs.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainer work can include reviewing each Superset release's breaking change notes before your planned upgrade.
- Confirm with your assessor which control evidence they expect, since DeployOpen prepares evidence but does not issue audit reports or certifications.
