Apache Superset for manufacturing: why self-hosted BI fits plant data
Production, quality and ERP data in a manufacturer usually sit in several places: a historian or time-series store at each plant, a quality system, an ERP instance that may be central or local, and spreadsheets that fill the gaps. Shift leads, quality engineers and planners need to see the same figures without someone exporting them to a file and mailing it around. Apache Superset is a practical fit for that visualization layer because it is an Apache Software Foundation project under the Apache License 2.0 with no paid edition, so the software itself carries no license fee and the data never has to leave infrastructure you control. Confirm the exact license terms of any bundled components with your legal team before the design is signed off.
Self-hosting changes the build in three concrete ways. First, access must follow the site model: a quality engineer at one plant should not see another plant's scrap rates, so row level security, roles and the group mapping from your identity provider need to be designed around sites before the first dashboard is published. Second, time-series sources such as historian exports are queried differently from ERP tables, so you need to decide which database connections Superset reads, whether it queries live data or a replicated reporting store, and how query limits protect the historian from dashboard load. Third, the OT boundary matters. Superset should sit on the business network or a dedicated analytics zone, reading from data replicas rather than reaching into control networks, and the design should be checked against the segmentation approach your OT team already follows.
This page is specific to manufacturing. It does not repeat a general Superset overview, and it assumes you already have a reason to self-host. The sections that follow cover the sites, sources and dashboards involved, the controls that protect plant data, and the questions to settle with your OT and IT teams before a build starts. A useful first step is to list every data source a dashboard would need, mark which site owns each one, and note which of them are allowed to leave that site.
Which industry requirements shape a manufacturing Superset build
This table compares the main industry requirements that touch a manufacturing analytics platform and translates each one into a placement, data access or evidence decision for Superset. Read each row as a question to answer before the build starts: where the Superset instance may sit, which plant or ERP data it may read, and what records you will need to show. Several requirements apply to the manufacturer rather than to the analytics tool, so the takeaway is to scope Superset as part of a wider OT and product program.
| Requirement | What it means for Superset | Build impact |
|---|---|---|
| ISA/IEC 62443 zones and conduits | Superset is a business-level application, so it should sit outside the industrial control zones and reach OT data only through a defined conduit. | Map the zone model first. Place Superset in an IT or DMZ zone and document every allowed flow from historians or MES into it. |
| ANSI/ISA-62443-3-2-2020 risk assessment | The risk assessment for system design should name Superset as a dependency that reads production data and holds credentials to data sources. | Record the data sources, service accounts and dashboards in scope so the assessment covers the analytics path. |
| ISA-62443-3-3-2013 system security requirements | Requirements for security levels apply to the systems that carry and store plant data, including the analytics layer and its metadata database. | Confirm which security level the zone targets and align authentication, logging and encryption of the Superset stack to it. |
| NIST SP 800-82 Rev. 3 (September 2023) | Guidance covers OT performance, reliability and safety. Analytics queries must not slow historians, PLC-facing systems or SCADA polling. | Route dashboards to replicas or a warehouse, set query timeouts and keep heavy refresh jobs off plant-facing networks. |
| NIS2 Annex II, manufacturing | Manufacturing divisions under NACE Rev. 2 are listed as a critical sector, so the operator may be an in-scope entity regardless of Superset. | Confirm with counsel whether your entity is in scope, then include Superset logs and access records in your incident response inputs. |
| NIS2 incident reporting timelines (Article 23(4)) | In-scope entities must send an early warning within 24 hours, a notification within 72 hours and a final report within one month. | Keep audit logs, user activity and data source access records exportable so the team can reconstruct events within those windows. |
| Machinery Regulation 2023/1230, Annex III 1.1.9 | Machinery must be protected so that connecting another or remote device does not create a hazardous situation, which makes any write-back or control path from analytics a design concern. | Keep Superset read-only against operational data, with no path that sends commands or setpoints to machinery. |
| Cyber Resilience Act (applies from 11 December 2027) | Products with digital elements are covered, so any custom plugin or embedded product you ship may fall under its vulnerability handling duties. | Track Superset releases and custom plugin dependencies, and confirm with your legal team which products are in scope. |
Where Superset runs relative to the plant network
This option runs Superset in the corporate IT network and points it at replicated extracts of ERP and historian data. The plant network stays closed to inbound analytics traffic, and the data team manages the instance with the same tooling it uses for other internal applications. The trade-off is freshness: dashboards are only as current as the last replication job, and shop floor users generally have no direct path to the instance.
- Data path: Replication jobs copy ERP tables and historian extracts into a warehouse or reporting database that Superset queries.
- Components: The metadata database (PostgreSQL or MySQL), the Superset web application and, if you use alerts or reports, the caching layer and Celery workers.
- Access by site: Row level security is applied in Superset against the replicated data, so plant-level filtering depends on how the extracts carry site keys.
- Operational burden: Lowest for the plant team, since patching, backups and upgrades sit with the IT platform group.
- Freshness: Set by the replication schedule, which you should confirm against how often production and quality managers need numbers.
Check whether your replicated extracts keep the site and line identifiers that your row level security rules depend on.
A DMZ instance sits between the plant network and the corporate network. A data platform in the DMZ receives pushed or pulled data from plant systems, and Superset runs beside it so that plant data reaches dashboards without Superset itself reaching into control networks. This placement usually gives better freshness than replicated extracts, but it adds firewall rules, a second environment to maintain and more careful credential handling between zones.
- Data path: Plant systems publish to a data platform in the DMZ, and Superset queries that platform rather than the historian or ERP directly.
- Components: Superset web and metadata database in the DMZ, plus the caching layer and Celery workers if alerts or async queries are needed.
- Access by site: Site-scoped roles can be enforced in Superset, but the data platform's own access model needs to match them.
- Operational burden: Higher than the corporate option, because the DMZ has its own patch cycle, network approvals and monitoring.
- Connectivity: Each cross-zone flow should be listed, approved and tested, and you should confirm which direction your security policy permits.
Confirm with your OT security owner which zone boundary rules apply before you choose the data platform's location.
A fully isolated site instance runs Superset inside one plant's own network with no route to corporate systems. It suits sites with strict change control, limited or no external connectivity, or local teams that need dashboards during a network outage at head office. The cost is duration: each site becomes its own installation with its own upgrades, backups, user administration and evidence, which multiplies as the number of plants grows.
- Data path: Superset reads the local historian and site ERP database directly or through a local data store.
- Components: A local metadata database (PostgreSQL or MySQL, since the SQLite default is not for production), the web application, and optional caching and Celery workers sized for the site.
- Access by site: Access is naturally scoped to the site, but cross-site views for corporate reporting require a separate mechanism.
- Operational burden: Highest, since every site needs its own patching, backup testing and upgrade window.
- Standards context: Plant network segmentation is usually assessed against the ISA/IEC 62443 series, so document zones and conduits alongside the deployment.
Ask how many sites would run an instance and who will operate each one before comparing the cost to a shared model.
Which Superset modules and settings matter on the factory floor
A manufacturing Superset rollout depends on a short list of decisions: which plant data sources it reads, how row-level rules keep each site to its own lines, how directory groups become roles, and how secrets, alerts and exports are controlled. Each card below names one of those decisions and the check to make before production use.
Plant data source connections
Superset reads ERP, MES, quality and time-series stores through database connections, so each source needs its own read-only account. For scrap-rate and OEE views, confirm which tables hold shift, line and work order keys, and whether the time-series store can handle dashboard query load without slowing the historian. Ask the database owner to confirm query timeouts and which schemas the Superset service account can see. Connection details should be reviewed with the owners of each system before any chart is built on top of it.
Row-level security by plant and line
Row-level security filters the rows a user can query, so a quality engineer at one site sees only scrap data for that site's lines. Define the filter on the plant and line keys in the source data, not on dashboard labels, which users can change. Test each filter with a user from every plant, including users who belong to more than one site, and confirm that filtered charts and their underlying queries both respect the rule.
Directory groups mapped to Superset roles
Plant access usually follows directory groups such as site quality teams or line supervisors. The AUTH_ROLES_MAPPING setting translates those LDAP or OAuth groups into Superset roles, so access changes in the directory flow through at the next login. Document which groups map to which roles, remove stale mappings when a line closes, and test that a plant operator cannot reach an admin role through a group they should not hold.
SECRET_KEY management and rotation
Superset refuses to start without a user-specified SECRET_KEY, and that key protects session and encrypted data. Store it in your secrets manager, not in a configuration file checked into source control. When rotating, set PREVIOUS_SECRET_KEY to the old value so existing sessions and encrypted fields remain readable during the change. Plan the rotation as a change window with a tested rollback, since a mistake here affects every user at once.
Threshold alerts and scheduled reports
Alerts and reports can notify a supervisor when scrap or downtime crosses a threshold, but they depend on the caching layer and Celery workers. Confirm which workers run in your plant network, where report delivery goes, and who owns the alert threshold values. Limit recipients to people who can act on a breach, and decide whether a report containing line data may leave the plant network by email.
Dashboard export controls
Users can often export chart data to CSV or Excel, which can move plant production figures into spreadsheets outside any access rule. Decide which roles may export, and whether exports from a restricted line dashboard are allowed at all. Confirm the export setting in your Superset version, then test it with a plant user to see what leaves the system. Record the decision so that quality and IT agree on it before go-live.
How a manufacturing Superset rollout runs in phases
The sequence moves from agreed dashboards and sites to a zoned, access-controlled instance that plant users have validated, then to an operating routine where every upgrade is tested before it reaches production. Each phase closes with a document or working artifact the client keeps.
Scope dashboards and sites in writing
The first phase defines which production, quality, maintenance and supply chain dashboards are in scope, which plants and lines they cover, and who approves each one. DeployOpen runs working sessions with plant managers, quality leads and the BI owner, then records the result as a scope document with a dashboard inventory and a site list. The step is complete when the client signs off on that scope, since the fixed-scope agreement and any quote depend on it.
Map data sources and named owners
Each dashboard is traced to its source: historian or time-series tags, MES and quality records, ERP tables for orders, stock and production, and any spreadsheets still in use. For every source, the client names a data owner who confirms what the field means, how current it is and which site it belongs to. The deliverable is a data source register with connection type, owner and refresh expectation, which later drives the database privileges and row-level rules.
Decide the deployment zone with OT and IT security
Before any server is provisioned, OT engineering, IT security and the Superset owners agree which network zone hosts the instance and which flows cross the boundary. The discussion covers whether Superset reads from a replicated analytics store instead of live control networks, and how the ISA/IEC 62443 zone and conduit model applies to your plant architecture. The output is a zone and conduit diagram with approved ports, source systems and direction of each flow, signed by both OT and IT.
Build the instance with production metadata services
DeployOpen installs Superset in your infrastructure with PostgreSQL or MySQL as the metadata database, since the SQLite default is not recommended for production, plus the caching layer and Celery workers needed for alerts, reports and async queries. Identity is connected to your directory, and a user-specified SECRET_KEY is generated and stored in your secrets system. The step closes with a build record listing versions, component layout, backup settings and a smoke test that a dashboard loads from a test source.
Configure site roles and row-level security
Directory groups are mapped to Superset roles so that users inherit access by site and function, for example a plant A quality role that cannot see plant B lines. Row-level security rules are written against the data owner's site field and tested with accounts from each site. The deliverable is a role and RLS matrix that lists each group, its permitted datasets and filters, and the test results showing that a user cannot see another site's rows.
Validate dashboards with plant users
Plant supervisors, quality technicians and planners use the dashboards against real shift and batch data in a staging instance. They check that figures match the source system for a sample period, that refresh timing suits shift handover and that shop floor displays render legibly on the planned screens. DeployOpen logs each defect, fixes it and retests. The step is complete when the named owners sign a validation record for each dashboard.
Operate with tested upgrades and backups
Once in production, a routine governs change. Before every upgrade, the metadata database is backed up and the release notes and UPDATING.md are reviewed for breaking changes. The upgrade is applied in staging, which runs superset db upgrade and superset init, and the dashboard validation checklist is repeated before production. The deliverable is a runbook with the backup procedure, the upgrade test checklist and a change log that your team can follow without DeployOpen on site.
Compliance questions manufacturers should settle before go-live
Manufacturers deploying Superset often discover that the platform itself is rarely the regulated item. The obligations come from the products they make, the sectors they serve and the records they keep, and those obligations shape who can see plant data, how incidents are reported and what evidence is kept. The cards below cover the checkpoints to settle before dashboards reach production.
NIS2 incident reporting timelines
Manufacturing is a critical sector under NIS2 Annex II, covering electronics, electrical equipment, machinery, motor vehicles and other transport equipment. In-scope entities must send an early warning within 24 hours, an incident notification within 72 hours and a final report within one month. Important entities face fines of at least EUR 7 million or 1.4% of worldwide turnover. For Superset, confirm that the dashboards, metadata database and worker logs are inside the incident response plan, and that someone can pull access and audit records quickly enough to meet those clocks.
Cyber Resilience Act obligations
The Cyber Resilience Act applies fully to products with digital elements from 11 December 2027, but manufacturers' Article 14 duties to report actively exploited vulnerabilities and severe incidents have applied since 11 September 2026. Superset is not a product you sell, so the Act does not make it a compliant item by itself. It does matter if your own connected products depend on data or software you publish. Confirm which of your products fall under the Act and who owns the reporting workflow for them.
Machinery Regulation safeguards
Regulation (EU) 2023/1230 applies from 14 January 2027 and adds an essential requirement that machinery be protected so that connecting another device or remote device does not lead to a hazardous situation. If a Superset dashboard or embedded view is linked to machine controls, alarms or operator screens, that connection needs a documented design. Keep analytics read paths separate from control networks and confirm with your compliance team whether any dashboard data can influence machine behavior.
21 CFR Part 11 for electronic records
Pharmaceutical and medical device manufacturers that keep batch, quality or release records electronically must meet 21 CFR Part 11 for electronic records and electronic signatures. Superset dashboards built on those records can become part of the controlled record set, depending on how they are used. Confirm which dashboards are reviewed for decisions, how access changes are logged, and whether exports are controlled. DeployOpen can prepare controls and evidence for this review, but the assessment itself is run by your quality function and its auditors.
Evidence and assessor roles
DeployOpen prepares systems, controls and evidence for compliance assessments, including access configuration, logging and change records. It does not issue audit reports, attestations or certifications, and independent auditors or certification bodies make those determinations. Ask early which evidence each regulator or customer will request, who signs off on it and how long it must be retained. Settling these answers before go-live avoids rebuilding logs and access records after the first assessment request.
What manufacturers ask before hiring a Superset partner
What drives the cost of a Superset implementation for a plant?
The largest cost drivers are the number of data sources, how much modeling and dashboard design the scope includes, the identity and network work required, and how many environments you need. Superset itself is Apache-2.0 licensed with no paid edition, so the cost is labor, hosting and infrastructure you run yourself. Cost splits into one-time items (discovery, data modeling, build, testing, handover) and recurring items (hosting, backups, upgrades, support). Ask any quote to itemize these, state who pays for hosting and licenses for supporting services, and list the assumptions about data access and OT approvals.
How long does a fixed-scope Superset build take?
Duration depends on how many sites, data sources and dashboards are in scope, how clean the source data is, and how quickly your data owners and OT contacts can review and approve access. Superset deployment is typically the shorter part; data modeling, security review and change control around plant networks usually take longer. No duration is set until the scope is written down. Ask the partner to tie the timeline to named deliverables, list the dependencies on your side, and state what happens if access approvals slip.
What must our team provide before a Superset project starts?
Plan to provide named data owners for each source, OT or controls contacts for any plant system, an identity provider or directory for sign-in, and a hosting environment with the network paths the design needs. Your team also needs to decide the site-based access model and who approves dashboard changes. Missing items usually show up as delayed access rather than technical failure, so ask the quote to list each dependency with an owner and a date you agree to.
Can an internal team deploy and run Superset without a partner?
Yes, a capable internal platform team can install and run Superset, and the project is open source with public documentation. The harder work is governance: row level security by site, role mapping from your directory, secure configuration and ongoing patching. Superset requires a user-specified SECRET_KEY to start and the production metadata database should be PostgreSQL or MySQL, not the SQLite default. Decide honestly whether your team has time to own these tasks for the life of the platform, then compare that against a partner scope.
How are Superset upgrades handled when breaking changes ship?
Upgrades follow the project's upgrade guide: back up the metadata database, run superset db upgrade and superset init, test in staging first, and read UPDATING.md for breaking changes between versions. Version 6.1.0 was published on May 13, 2026, and 7.0.0rc2 is listed as a pre-release, so plan an upgrade path rather than assuming a single step. Ask partners how they test dashboards, RLS rules and embedded views after an upgrade, and whether upgrades are in scope or sold as a retainer.
Can Superset query historian data directly?
Superset can connect to any database it has a driver and a supported connection for, so a historian is possible if it exposes a SQL interface through a supported engine. In practice, historians often store time-series data in ways that are slow to query at dashboard scale, and direct queries can add load to the historian. Confirm the historian vendor's SQL access and licensing terms, whether read-only replicas exist, and whether a warehouse or analytics store should sit between them. Ask the quote to state how query limits and caching are configured.
What compliance rules could affect a manufacturer's Superset deployment?
Requirements depend on where you operate and what you make. The ISA/IEC 62443 series governs industrial automation and control systems, and NIS2 lists manufacturing as a critical sector with incident reporting obligations. The Cyber Resilience Act applies to products with digital elements from 11 December 2027. Superset itself is usually an analytics layer, so the question is whether it touches OT networks and how access is logged. Ask your partner which of these apply to your sites and which evidence the engagement will produce, but confirm final assessment with your auditors.
What to ask a partner before signing a manufacturing scope
Start with OT segmentation, because it decides where Superset can sit and what it may read. Ask the partner to state in writing which network zones the Superset web tier, metadata database, cache and workers will occupy, how traffic from plant networks reaches them, and which direction connections are allowed to flow. The ISA/IEC 62443 series organizes this work around zones and conduits, so the answer should map to the zone model your operations team already uses. If the partner cannot show this on a diagram before work starts, the fixed scope will not cover the firewall changes, the data paths and the approvals that follow from them, and those tend to be the largest unplanned items in a plant project.
Next, confirm which Superset components are in scope. Superset is more than the web application: alerts and reports, async queries and dashboard thumbnails depend on the caching layer and Celery workers, and the metadata database must be PostgreSQL or MySQL rather than the SQLite default. Ask whether the quote includes the Redis cache, the worker and beat processes, the production metadata database, and the Kubernetes path (the official Helm chart is marked deprecated, and the Apache Superset Kubernetes Operator is alpha, so the chosen route should be named and its risk accepted in writing). Each item you leave out becomes a change order later.
Ask how row-level security by site is designed and tested. Plant users should see only their own site's production and quality data, and that restriction should hold for every chart, dataset and export. Request the test cases in writing: which test accounts are created for each site, which datasets are checked, and whether the partner tests through the API and the embedded paths as well as the UI. Also ask who owns the group-to-role mapping through AUTH_ROLES_MAPPING and how changes to plant groups in your directory reach Superset. Finally, settle dashboards as code: confirm whether dashboards are exported into version control, who reviews changes, who holds the deployment credentials after handover, and what happens to the repository when the engagement ends. Support and upgrade terms belong in the same document, including the named upgrade path, the staging test, the metadata backup, and the review of UPDATING.md before each major version, along with whether those tasks are fixed-scope deliverables or a separate retainer.
How DeployOpen scopes and delivers Superset for manufacturers
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including Apache Superset for manufacturing. Engagements start from a written, fixed scope so plant, IT and OT stakeholders agree on data sources, access rules and deliverables before build work begins.
How we scope
- Inventory the plant and ERP data sources Superset will query, and confirm which databases hold time-series and quality records.
- Map site-based access rules to Superset roles and row level security, and record who approves each data group.
- Agree in writing where Superset runs, which network zones it reaches, and which OT data paths stay out of scope.
How we build
- Deploy Superset with PostgreSQL or MySQL as the metadata database, the caching layer and Celery workers for alerts and reports.
- Configure SECRET_KEY handling, LDAP or OAuth group mapping through AUTH_ROLES_MAPPING, and database connections under least privilege.
- Build production and quality dashboards and shop floor displays, then test access by site and refresh behavior in staging.
How we hand over
- Document the architecture, configuration keys, role mappings, RLS rules and the staging-to-production change steps.
- Provide a backup and upgrade runbook covering metadata database backups, superset db upgrade, superset init and UPDATING.md review.
- Walk your platform, plant IT and security teams through operation, and confirm the handover items in the written scope.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, scoped separately from the original build.
- Plan each Superset version upgrade in staging before production, with a rollback point taken from the metadata database backup.
- Confirm with your team how new plants, sites and data sources are onboarded, and price those changes through a written scope.
