Embedded analytics for the public sector

Why embedded analytics for the public sector is different

An agency leader who wants a public dashboard needs three things at once: anonymous visitors must be able to read it without a login, the content must meet accessibility rules, and the data and the hosting must stay under government control. For most agencies, the answer is Apache Superset for internal performance reporting and embedded views inside staff or partner applications, and CKAN where the goal is a published data portal with open datasets sitting next to the dashboards. The constraints come from the data, the audience and the hosting rules, not from the charting tool. Before selecting Superset or Metabase, confirm the license and paid-feature position with the vendor, since Metabase's commercial license applies to its enterprise directory and some features may require a paid plan.

The data decides what can be public. Each dataset needs a classification and a sign-off on which fields, aggregates and geographies may be published, because a chart that is harmless internally can expose individuals when filtered to a small area or a short time window. Anonymous access also changes the security model: a public link should query a published, aggregated dataset or a read-only view, never the operational database, and the team should confirm how Superset handles guest or public access and how its query load is kept away from production systems. Internal dashboards need the opposite discipline, with SSO through the agency's identity provider, role mapping from groups and row-level security so that staff see only their own districts, programs or cases.

Hosting rules shape the architecture more than any feature list. Confirm where the metadata database, caches, worker processes and dashboard thumbnails will run, because Superset's alerts, reports and async queries depend on a caching layer and Celery workers, and its production metadata database should be PostgreSQL or MySQL rather than the SQLite default. Ask whether the workload falls under FedRAMP, CJIS or CUI requirements, and whether the agency's accessibility obligations under the ADA Title II rule apply to the dashboards and the portal. Those answers, not the charts, determine whether the platform runs in the agency's own cloud account or a sovereign data center, and they should be written into scope before any build starts.

Which rules shape the build, and what each one means

This table maps the rules most likely to shape a public sector dashboard build to what each one changes in the design, hosting and operations. Read each row as a question to answer for your own entity, since applicability depends on your jurisdiction, funding, data types and whether the system is cloud hosted.

Rule	What it asks for	What it means for the build
ADA Title II web accessibility (28 CFR 35.200)	WCAG 2.1 Level A and AA for state and local government web content, including content delivered through contracts or licenses. Compliance dates are 26 April 2027 for entities serving 50,000 or more people and 26 April 2028 for smaller entities and special districts.	Public dashboards and embedded views must be tested against WCAG 2.1 A and AA, including chart alternatives, keyboard navigation and color contrast. Confirm your population category and whether the vendor's embedded components fall under your contract.
NIST SP 800-53 baselines and FedRAMP scope	SP 800-53B low, moderate and high baselines select 149, 287 and 370 controls and enhancements. FedRAMP covers cloud services that handle federal information on behalf of an agency, but not single-agency systems on cloud infrastructure that are not offered as a shared service.	If federal information sits in a cloud-hosted dashboard, select the baseline with your authorizing official and confirm whether FedRAMP applies. Hosting location and key ownership usually follow from this decision.
CJIS Security Policy v6.1	Version 6.1 took effect 26 June 2026. It requires FIPS 140-3 validated modules or FIPS 197 AES with keys of at least 256 bits for criminal justice information in transit and at rest outside physically secure locations, and vulnerability scanning at least monthly.	Where dashboards show criminal justice information, enforce TLS and encrypted storage with approved cipher choices, and schedule monthly or more frequent scans of the Superset or Metabase stack. Confirm with your CJIS Systems Officer which data elements count as CJI.
32 CFR 2002.14(h)(2) for CUI	Federal agencies must use NIST SP 800-171 when setting requirements to protect controlled unclassified information on non-federal systems, unless the CUI category's authority prescribes other safeguards.	If a contractor or grantee hosts a dashboard holding CUI, the build must meet the safeguards your agency specifies, typically tied to SP 800-171. Confirm the CUI categories in scope before choosing public links or guest access.
NIS2 for EU public administration	Covers central government entities regardless of size and lists public administration as a sector of high criticality. Member States may extend it to local administration. It does not apply to entities in national security, public security, defense or law enforcement.	For EU bodies in scope, self-hosted dashboards need documented incident handling, access control and supply chain oversight of open-source components. Confirm with your national authority whether you are covered and whether the exclusions apply to your analytics.

Public links without login versus internal performance reporting

Public dashboards are read by residents, journalists and other outside parties who have no account. The access path must therefore be designed around anonymous viewing rather than around users who authenticate. In Apache Superset, the usual pattern is to publish a dashboard for embedding through a guest-style token issued by the hosting application, so that viewers never reach the login screen and the anonymous role has no rights beyond the dashboard itself. The more important design decision is what the public viewer can reach behind the chart. Published dashboards should read from a curated, aggregated dataset rather than from the operational source database, so a public link cannot become a query path into systems of record.

Published datasets: Build public charts on a separate schema or extract that holds only approved aggregates, refreshed on a schedule.
Caching: Use the caching layer for dashboard results so repeated anonymous views do not repeat heavy queries.
Rate limits: Apply limits at the reverse proxy or API gateway in front of the embedding endpoint to contain scraping and abuse.
Separate roles: Keep the anonymous role free of permissions for internal datasets, SQL Lab and chart editing.
Logging: Record access at the gateway, since anonymous viewers produce no user identity in the metadata database.

Confirm with the vendor and your security team exactly which guest-token and public embedding options your chosen version supports before committing to the design.

Which open-source platforms fit public sector analytics

Public sector analytics usually splits into three jobs: dashboards for staff and the public, a portal that publishes the underlying datasets, and a catalog that governs where those datasets come from. The options below cover each job, and each card names the trade-off an agency should test before committing to a platform.

Apache Superset for dashboards and embedding

Superset is Apache-2.0 licensed with no paid edition, so the licensing decision is simpler than with dual-licensed tools. It suits internal performance reporting and public dashboards that sit in an agency's own hosting. The trade-off is operational: production use needs PostgreSQL or MySQL as the metadata database, plus a caching layer and Celery workers for alerts, reports and thumbnails. Confirm who will own those components and the upgrade path, since each release requires a metadata backup and a staging test. Check that guest or public access can be limited to published dashboards only.

Metabase for internal reporting

Metabase has a quick setup for questions and dashboards, and it is a common choice for staff reporting. Its open source code is AGPL outside the enterprise directory, which uses a commercial license. Agencies should ask which features they need, such as SSO, granular permissions or embedding options, and whether those fall under the commercial license before they design around them. Public release of modified code also triggers AGPL source obligations, so legal review belongs in the selection step. Confirm the paid feature list in writing before the design is fixed.

CKAN for open data portals

CKAN is built to run data hubs and open data portals, and it is the strongest fit when the agency must publish datasets for download and reuse. The DataStore keeps structured resources in PostgreSQL with a read-only role for public queries, and the ckanext-dcat extension adds DCAT-AP metadata and RDF endpoints. CKAN is AGPL v3.0, so any modifications you publish or host for others carry source obligations. Plan for Python, PostgreSQL, Solr and Redis, and check the release policy, since minor releases can contain breaking changes.

DataHub or OpenMetadata for catalog governance

A catalog records what datasets exist, who owns them, how they are classified and where they came from. DataHub and OpenMetadata are both Apache-2.0 licensed, which keeps the governance layer free of distribution restrictions. Their value grows when the agency runs several source systems and needs lineage for audit questions. The trade-off is that a catalog only helps if owners maintain metadata, so confirm stewardship roles and who reviews classifications before rollout. Pick one based on connector coverage for your existing systems.

Airflow for scheduled data pipelines

Airflow is a supporting component rather than a reporting tool. Apache-2.0 licensed and released as 3.3.2 on September 17, 2026, it schedules the jobs that load source extracts into the analytics database and the open data portal. Its value for agencies is repeatable, monitored refreshes that carry a clear run history. The trade-off is that Airflow adds its own scheduler, workers and database to operate, so use it only when the refresh volume justifies that footprint. Dashboards that refresh on a simple schedule may not need it.

Dify only where workflows need an AI layer

Dify is a workflow and LLM application platform, and it is not a dashboard tool. It is worth considering only if an agency wants an AI assistant that answers questions over published reports or datasets. Its license is a modified Apache License 2.0 that requires a commercial license to run a multi-tenant service from the source code, so a public-facing deployment for many users needs a license review first. Keep it out of the analytics core unless that specific use case is confirmed.

Integration points and deployment pattern for agencies

An agency embedding Superset dashboards in a public or internal portal connects a small set of components: identity, metadata storage, background workers, the analytics data, the open data catalog and the hosting zone. Each one carries a decision that the agency, not the vendor, must own before the rollout starts.

Identity provider and group mapping

Superset is built on Flask-AppBuilder and supports OAuth2 providers and LDAP. Group membership from the agency directory is mapped to Superset roles with AUTH_ROLES_MAPPING, so staff access follows the directory rather than local accounts. The agency must decide which groups can publish, which can view internal dashboards, and who approves changes to those mappings. For public links without login, confirm that anonymous access is limited to published dashboards and that no internal role can be granted through a public path.

Metadata database: PostgreSQL or MySQL

Superset stores dashboards, users and permissions in a metadata database. The configuration documentation lists supported versions as PostgreSQL 10 to 17 and MySQL 5.7 and 8.x. The SQLite default used by quickstart and PyPI installs is not suitable for production, and the Docker Compose PostgreSQL container is not recommended for production either. The agency must choose a managed or self-run database inside its hosting zone, define backup and restore testing, and keep the SECRET_KEY in a secrets store, because Superset will not start without one.

Redis and Celery for background work

Alerts and reports, async queries and dashboard thumbnails depend on the caching layer and the Celery worker and beat processes, and most installations use Redis and Celery for them. Without these components, scheduled reports to staff and thumbnails in portal listings will not run. The agency must decide whether scheduled report delivery is in scope, where report files are sent and retained, and who operates the queue and its patching cycle inside the hosting zone.

Analytics database separate from operational systems

Dashboards should query a copy or reporting store, not the systems of record that case workers or payment systems use. A separate analytics database limits load during public traffic spikes and keeps read-only access scoped to the reporting layer. The agency must decide what data is extracted, how often it refreshes, which team owns the pipeline, and how personal data is removed or aggregated before it reaches a public-facing dashboard.

CKAN with PostgreSQL, Solr and Redis

Where the agency also publishes open datasets, CKAN handles the catalog, and its DataStore keeps structured resources in a separate PostgreSQL database with a read-only user for the Data API. A source install requires PostgreSQL 12 or newer, Solr 9 (recommended) or Solr 8, and Redis, with uWSGI and Nginx recommended for production. The agency must decide which datasets are published, how they link to dashboards, and how CKAN patch and minor releases are scheduled, since minor releases may include backwards-incompatible changes.

Hosting zone and accessibility obligations

The hosting zone determines which data rules apply: a government cloud, an agency data center or an air-gapped network. Where federal information is handled by a cloud service, FedRAMP scope questions apply, and criminal justice data falls under the FBI CJIS Security Policy. Public web content is also subject to the ADA Title II rule, which requires WCAG 2.1 Level A and AA from 26 April 2027 for entities serving 50,000 or more people. The agency must confirm the authorization status of each cloud service and test dashboards against WCAG before publication.

How an agency rollout moves from scoping to public launch

The sequence turns a public dashboard idea into a launched, tested and operated service, with each phase closing on a written output that the agency's owners approve before the next phase starts. Scope, data decisions, access design and accessibility testing come before any public link is created.

Map scope and applicable rules
The agency's program owner, legal counsel and the security lead list the dashboards, audiences and data sources in scope, then identify which rules apply: the ADA Title II web accessibility rule for state and local government content, FISMA-linked federal baselines such as NIST SP 800-53 if federal systems are involved, FedRAMP only where a cloud service handles federal information, and FBI CJIS Security Policy where criminal justice information is present. DeployOpen maps each rule to a control set and a hosting decision. The step closes with a signed scope document and a rule map that names the owner of each obligation.
Classify data and set publication rules
Data owners classify each source by sensitivity and decide which fields, aggregates and time ranges may appear on a public page and which stay internal. Privacy and records staff review small-cell counts, geographic detail and any linkage that could re-identify a person. Where the agency publishes raw datasets, the team also decides on a catalog format and whether a CKAN portal sits beside the dashboards. The step closes with a publication register listing each dataset, its owner, its classification and its approved public form.
Design identity and role access
The team separates public, staff and partner audiences and maps each to an access path. Public dashboards need no login, so the design keeps them on a read-only, pre-approved dataset that cannot reach internal schemas. Staff views connect to the agency identity provider through OAuth2 or LDAP, with group-to-role mapping set in the configuration. DeployOpen tests that a user outside a group cannot see restricted dashboards by a direct URL or API call. The step closes with a role matrix and test results that show each audience sees only its approved content.
Build and test to WCAG 2.1 AA
Developers build the dashboards, portal pages and any mobile content, then test them against WCAG 2.1 Level A and AA. Testing covers keyboard navigation, screen reader output for charts and filters, color contrast, text alternatives for chart data and focus order in embedded frames. Accessibility specialists review results with the agency, and open defects are fixed and retested. The step closes with an accessibility report that lists each criterion tested, the result and the remediation record, so the agency can show its compliance position against the 26 April 2027 and 26 April 2028 dates in the ADA rule.
Run security testing and vulnerability scanning
The security team tests the application, its APIs and the hosting environment before any public exposure. Scope includes the metadata database, the caching and worker components, secret handling for the Superset SECRET_KEY, network exposure of internal ports, and scanning cadence. Where the data is CJI, the scanning and encryption controls follow the CJIS Security Policy version 6.1 requirements, including monthly vulnerability scanning and FIPS-validated cryptography. The step closes with a findings register where every high-severity item is fixed or formally accepted by the agency.
Stage and rehearse the upgrade procedure
The platform is deployed to a staging environment that mirrors production, including the metadata database, Redis and Celery where alerts, reports or thumbnails are used. The team rehearses the upgrade path from the Apache Superset documentation: back up the metadata database, run the database upgrade and initialization commands, check UPDATING.md for breaking changes, and test dashboards and data refresh afterward. The step closes with a tested runbook and a recorded rollback test, so the agency knows how to change versions without taking public pages offline unplanned.
Launch publicly under controlled conditions
The team releases public links in a limited stage first, watching query load on the analytics database, caching behavior and error rates while the public audience grows. Communications staff confirm the published notice, the data limitations statement and the contact route for corrections. Rollback steps are rehearsed and assigned before go-live. The step closes with a signed launch approval from the program owner and the security lead, and a log of the first production checks.
Hand over operations and support
DeployOpen transfers runbooks, monitoring dashboards, backup and restore procedures, patch and upgrade calendars, and access administration steps to the agency's operations team. The agency confirms who handles incidents, data corrections and new publication requests. Where the agency wants continuing support, upgrades or recurring testing, these are scoped separately as a retainer. The step closes with a handover acceptance record that lists each owner and each procedure the agency has tested.

Evidence auditors and oversight bodies ask for

This table maps the evidence an assessor or oversight body typically requests to the Superset or CKAN component that produces it and the team that owns it. Read each row as a question to answer before an audit, not as a finished attestation. DeployOpen prepares this evidence, while independent auditors or certification bodies issue any assessment outcome.

Evidence	Where it comes from	What to confirm before an assessment
Access reviews and group mappings	Identity provider group membership and Superset AUTH_ROLES_MAPPING or LDAP group mappings	Who approves each mapping, how often reviews run, and whether leavers are removed from both systems
Role and row-level configuration exports	Superset role and row-level security definitions, exported and version-controlled	That each public and internal dataset has a documented filter, and that changes go through review before reaching production
Accessibility test reports	Test results against WCAG 2.1 Level A and AA for dashboards, embedded pages and any portal wrapper	Whether testing covers embedded charts, filters and keyboard navigation, and whether the entity's deadline under 28 CFR 35.200 applies
Vulnerability scan records	Scan results for the Superset host, metadata database, caching layer and CKAN components	Scan cadence, owner of each finding, and whether the requirement set by the applicable framework, such as monthly scanning under CJIS, is met
Encryption configuration	TLS settings, database and object storage encryption, and the modules or algorithms each component uses	That approved module choices and key lengths match the framework named in the contract, such as FIPS 140-3 modules and AES-256 for CJI
Backup and upgrade records	Metadata database backups, restore tests, and upgrade logs covering superset db upgrade and staging tests	Restore tests on a recent backup, and a record of UPDATING.md review for each Superset release applied
Published dataset inventory with DCAT metadata	CKAN catalog entries exposed as DCAT RDF through ckanext-dcat, with a dataset list for each publication	Which datasets are public, which are internal only, and whether publication decisions have a named approver
Hosting and authorization boundary	Architecture diagram and hosting records showing where data, backups and logs reside	Whether the hosting provider is in scope for FedRAMP or an equivalent authorization for the data classification involved

What to ask an implementation partner before hiring

How is anonymous public access isolated from internal data?

Public dashboards should read from a separate published dataset or a read-only database role that holds only approved aggregates, never the live internal schema. Ask the partner to show where the public tier sits on the network, which credentials it uses, and how an anonymous link is prevented from reaching internal dashboards, filters or drill-through paths. Ask for a written test plan that tries to escape the public tier from an unauthenticated session, and confirm who owns the approval step that moves a dataset from internal to public. Superset and Metabase both support public or guest access, but the exact isolation depends on your configuration, so have the partner confirm it against your own environment rather than a default install.

How is accessibility tested, and who does the testing?

Ask who runs the checks, against which standard, and whether the results come with a remediation log. Public web content of state and local governments is expected to meet WCAG 2.1 Level A and AA under the ADA Title II rule (28 CFR 35.200), with compliance dates of 26 April 2027 for entities serving 50,000 or more people and 26 April 2028 for smaller entities and special districts. Ask whether the partner tests charts, filters and tables with keyboard-only navigation and screen readers, whether it checks color contrast in your theme, and whether it covers the embedded pages as well as the surrounding portal. Confirm whether a separate manual audit by your own accessibility team or an outside firm is required, since DeployOpen prepares evidence but does not issue audit reports.

How will CKAN and Superset stay current within their release support windows?

Ask for a written upgrade calendar that names the versions in use and the support status of each. CKAN targets about two minor releases a year and supports the latest patch of the current minor and the previous minor, so a deployment on an older minor needs a planned move. Superset upgrades require backing up the metadata database, running superset db upgrade and superset init, testing in staging first and reading UPDATING.md for breaking changes. Ask how the partner tracks releases, how long a staging cycle takes in your environment, who approves production changes, and whether the retainer covers upgrades and emergency security patches. Confirm the current Superset release line and deployment method with the partner, since the Helm chart is marked deprecated in current docs.

Where are the data, logs and backups stored, and who can access them?

The answer should list each store: the CKAN DataStore in its own PostgreSQL database, the Superset metadata database, the caching and worker layer, application logs, and backups. Ask which accounts can read each one, whether access is through your identity provider with logged administrator actions, and whether all of it stays in your data center or cloud account. For AI-assisted features, confirm retention, since Article 19(1) of the EU AI Act requires providers of high-risk systems to keep automatically generated logs for at least six months unless other law sets a longer period. Ask how backups are encrypted and where keys are held, and confirm whether the systems fall under FedRAMP, CJIS or other rules that set their own storage requirements.

Which compliance rules does the partner assume apply, and how is that confirmed?

The partner should start with a written list of the frameworks it assumes, each tied to your jurisdiction, data types and whether the system is public or internal. Examples include NIST SP 800-53 controls for federal-facing systems, FedRAMP scope for cloud services that handle federal information, FBI CJIS Security Policy if criminal justice information is involved, and NIS2 for public administration in the EU. Ask who confirms the list: your legal counsel, your authorizing official, or your compliance office. DeployOpen prepares systems, controls and evidence for assessments but does not issue audit reports or certifications, so ask which independent assessor will review the evidence and when.

What does a fixed-scope embedded analytics deliverable include?

Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask for a deliverable list that names the dashboards, data sources, public datasets, identity integration, accessibility testing, hardening, backup and runbook documentation, and training for your staff. Clarify what is excluded, such as content creation, data quality remediation in source systems, or changes to your identity provider. Ask how change requests are priced, what acceptance tests close each deliverable, and what a post-launch retainer covers for upgrades, monitoring and continuous testing. The quote should follow directly from this written scope.

Can our own team run the platform after launch?

It depends on your staffing, your change process and how much of the platform you want to own. Ask the partner which tasks transfer to your team, such as dataset publishing, user administration and dashboard edits, and which stay with a retainer, such as upgrades, patching and security testing. Ask for a runbook, a documented restore procedure tested on your infrastructure, and a handover plan with named skills your staff need. Confirm what the partner delivers in writing and how knowledge transfer is verified before the engagement closes.

How does the partner handle security testing on public-facing dashboards?

Ask whether the partner tests the public tier as an attacker would, including unauthenticated access, guest tokens or public links, the API behind each chart, and the CKAN web and API surfaces. Confirm whether testing covers application and API security, cloud and infrastructure configuration and the AI features if you add them. Ask for the findings format, how severity is rated, how fixes are verified and whether retests are included in scope. Testing results support your own assessment evidence, but they are not an audit report, so confirm how your assessor will use them.

How DeployOpen scopes and supports public sector analytics

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source analytics inside the agency's own cloud accounts, data centers or air-gapped networks. For public sector dashboards, the work starts with the audiences, the data classes and the accessibility and hosting obligations that apply before any tool is chosen.

How we scope

Map which dashboards are public, which are staff-only and which contain data that must never be published.
Confirm the data classification of each source, including whether any criminal justice or controlled unclassified information is involved.
Agree in writing the accessibility target, hosting location, public link behavior and the open data publishing steps.

How we build

Deploy Apache Superset or Metabase with a metadata database and caching layer sized for public traffic and scheduled reports.
Configure SSO for staff editors and a separate, read-only publishing path for public dashboards without login.
Test keyboard navigation, contrast and screen reader behavior of published dashboards against WCAG 2.1 Level AA before release.

How we hand over

Deliver architecture diagrams, configuration records, role mappings and a list of which dashboards are reachable without authentication.
Document the upgrade path, including backing up the metadata database and testing each release in staging first.
Provide runbooks for publishing, retiring and reviewing public dashboards so agency staff can operate them independently.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope delivery ends.
Re-run accessibility and exposure checks when dashboards change or when the agency's accessibility deadlines approach.
Keep compliance evidence current for assessors, including access logs, configuration baselines and vulnerability scan results.