Grafana for manufacturing: plant floor implementation

Why Grafana fits manufacturing monitoring and where the plant floor changes the build

Grafana for manufacturing starts with a simple problem: production data sits in historians, PLC-fed databases and SQL systems spread across lines and sites, and the IT team has to show it to engineers, supervisors and managers without giving anyone a path into operational technology. A self-hosted Grafana instance inside the plant network answers that need. Queries run from a server the plant controls, against data sources the plant already operates, so the dashboard layer does not become a new route into control systems. The platform is open source under the AGPLv3 license, and Grafana Enterprise is offered as a commercial option that is not under the AGPL, which matters if your legal team has views on how modified code is shared.

A generic install differs from a plant install in four places. The first is data source choice: historians, IoT brokers and SQL replicas each need a read-only account, a defined query scope and a network route that exists only for that purpose. The second is network zones: Grafana should sit in a level that can reach the historian or replica but cannot initiate sessions into controllers, and the data flows across that boundary should be written down before the build. The third is shift displays, which usually run on a screen with no named user, so the access model for kiosk views needs its own decision rather than a shared admin login. The fourth is retention, because production teams often want years of time series that the monitoring team never planned to store.

Confirm each of these with your own environment and your Grafana version before committing to a design. Check which data source plugins your historian vendor supports, whether your OT network permits the planned flows, and how your team will receive and test Grafana patches when the network cannot reach the internet. Grafana's upgrade guidance describes an annual major release, bi-monthly minor releases and at least monthly patch releases, so a patch process that works offline is a design requirement, not an afterthought. The section that follows covers the frameworks that set the controls for these choices.

Which manufacturing requirements shape the Grafana build

This table maps each manufacturing requirement to what it means for Grafana access, updates and network placement. Read each row as a design input to settle before dashboards, data sources and alert routing are built. The main takeaway is that OT segmentation, user access and patch control are decided by these frameworks, not by Grafana defaults.

Requirement	What it asks for	Impact on the Grafana build
ISA/IEC 62443 (asset owner program)	An IACS security program covering risk assessment, system security requirements and security levels, organized into general, policy, system and component groups	Set the zone and conduit model first, then decide which Grafana instance sits in which zone. Define user roles and access per zone, and document the security level targeted for each dashboard data path.
ISA/IEC 62443 (system security levels)	Defined security levels for each zone, with requirements for access control and component hardening	Restrict Grafana administrator access and data source credentials to the levels the zone requires. Plan hardening and authentication settings as part of the zone design, not after go-live.
NIST SP 800-82 Rev. 3	OT security countermeasures that keep performance, reliability and safety requirements in place	Confirm that Grafana queries and dashboards cannot stall or overload historians, PLC gateways or SCADA data paths. Test refresh rates and query load outside production hours and prefer read-only access to OT data.
NIS2 Annex II (manufacturing scope)	Manufacturers in NACE Rev. 2 divisions 26 to 30 and medical device makers are critical sector entities, with incident reporting obligations for in-scope entities	Monitoring data and alert history from Grafana may be needed to support incident timelines. Confirm whether your entity is in scope and retain alert and audit records long enough to support early warning, notification and final report steps.
NIS2 Article 23(4) reporting timelines	Early warning within 24 hours, incident notification within 72 hours and a final report within one month of significant incidents	Alert routing to incident response contacts must work outside business hours and be tested. Keep contact points and notification channels reachable from the OT side without exposing the OT network to the internet.
Cyber Resilience Act (Article 14 and application date)	Manufacturers' reporting of actively exploited vulnerabilities and severe incidents applies from 11 September 2026, and the regulation applies from 11 December 2027	Track Grafana and plugin versions in your asset inventory and keep a record of each patch applied. Plan for vulnerability reporting obligations if you ship products with digital elements that include Grafana components. Confirm applicability with counsel.
Machinery Regulation (Annex III, 1.1.9)	Machinery must be protected so that connecting another device or remote device does not lead to a hazardous situation, applicable from 14 January 2027	If Grafana is connected to machinery controls or remote access paths, document how connections are restricted and approved. Avoid write-back from dashboards to machine controls, and record connection changes in the change process.
Software and patch integrity (NERC CIP-013-2 pattern)	Procurement processes that verify software integrity and authenticity of vendor software and patches	Verify checksums or signatures for Grafana packages, plugins and container images before they cross into isolated OT zones. Keep an internal mirror or offline repository for approved versions.

Which Grafana modules, data sources and settings matter on the plant floor

Most plant dashboards read from a historian, a SQL database, an IoT or time-series back end, and sometimes Prometheus or Loki for infrastructure and log data. Grafana connects to these through data source plugins, and the plugin for each system is a separate decision. Confirm each data source plugin in the target environment, including whether it is built in, maintained by Grafana Labs or a third party, and whether it supports the exact version of your historian or database.

Historian connectors: Confirm the plugin supports your historian product and version, and whether it reads live tags, aggregated history or both.
SQL sources: Decide which database accounts Grafana uses. Use read-only accounts scoped to the views the plant needs, not production write accounts.
IoT and time-series back ends: Check query limits and retention, since high-frequency sensor data can load both the back end and the dashboard.
Prometheus and Loki: Where present, use them for infrastructure and application signals, and keep process data in its own source so ownership stays clear.
Plugin trust: Record every plugin version in use, because a plugin update can change query behavior.

Before go-live, ask the historian and database owners to confirm which tags, tables and time ranges each dashboard may query.

How segmented and offline OT networks change the deployment

Once Grafana sits between plant systems and business users, the network design decides what the dashboards can read, what they can reach and how updates arrive. The six decisions below connect placement, data paths, package delivery, outbound control, update verification and write restrictions into one deployment design.

Place Grafana in the IT or DMZ zone

Keep the Grafana servers and their database outside the control network, in the IT zone or a DMZ that the plant historians and SQL servers reach through a narrow, approved path. Operators view dashboards from the plant network through that boundary, so the design needs a documented list of which hosts, ports and protocols cross it. Ask your OT team to confirm the zone model against the ISA/IEC 62443 zone and conduit approach before any firewall rule is requested. A single shared database should sit in the same zone as Grafana, not on the plant side.

Read historians through read-only data paths

Grafana queries historians, time-series stores and SQL databases, so each data source should use a dedicated account that has only select rights on the tables or tags it needs. Replicated or read-only historian views are a common pattern because they keep dashboard load away from the process historian. Confirm with the historian vendor which replicas, query interfaces and connection limits are supported, and test that a dashboard cannot alter data. Use the data source integrations that match your historian, and confirm each plugin's read behavior before approving it.

Deliver packages and plugins through an internal mirror

Isolated networks cannot pull Grafana packages, Docker images, Helm charts or plugins from the public internet, so the team needs an internal mirror or media-based transfer for every artifact. Record the exact version, checksum and source of each package before it crosses the boundary. Confirm with Grafana Labs which installation packages, container images and plugins can be used fully offline, and whether any plugin fetches assets at runtime. Offline support is often a paid-edition feature for other vendors, so do not assume that Grafana Enterprise or any plugin is covered without written confirmation.

Control outbound traffic from the Grafana host

Dashboards, plugins, alert notifiers and data source connections can each open outbound connections, and an isolated plant should allow only the destinations on an approved list. Block general internet egress at the firewall, then add explicit rules for the historian, the database, the authentication source and the internal notification relay. Ask the security team to test that a plugin or alert contact point cannot reach an external address. Review the list whenever a new panel, plugin or contact point is added, because each addition changes the traffic pattern.

Verify updates before they cross the boundary

Grafana releases major versions once a year, minor versions every other month and patch releases at least monthly, so an isolated plant will see frequent update cycles. Each package should be checked against a published checksum or signature, then tested on a staging copy of the dashboards and data sources before it enters the plant. NERC CIP-013-2 is an electric sector control that requires supply chain processes to verify software integrity and authenticity, and it is useful only as a pattern for manufacturing. Ask the vendor for the verification method for each artifact and keep the evidence in the change record.

Keep Grafana out of PLC write paths

Grafana is a visualization and alerting tool, so it should have no route that writes setpoints, commands or configuration to a PLC, DCS or SCADA system. Limit each data source to read operations, and do not place Grafana on a network path that can reach controller write interfaces. Shift displays that show live values should read from the historian or a read-only replica, never from the controller itself. Ask the OT engineering team to confirm this in writing, and include a test that proves the account used by Grafana cannot issue a write.

How a manufacturing Grafana rollout moves from one line to the plant

The sequence starts with shared scope and zone decisions between OT and IT, then builds and proves the stack on one line before the same pattern extends to other sites under a documented update cycle.

Scope sites and data sources with OT and IT together
Plant engineers, controls staff, IT operations and the security team list each line, historian, PLC gateway, IoT feed and SQL source the dashboards will read, and record which ones are read-only and which network zone each sits in. The ask is a written inventory with the owner, protocol and data direction for every source. The step is done when each source has a named owner on both the OT and IT side and nobody is still unsure whether a dashboard may write back to a control system.
Run risk assessment and design zones and conduits
Using the inventory, the team runs a security risk assessment aligned with the ISA/IEC 62443 approach, groups assets into zones, and decides which conduits carry Grafana traffic and in which direction. Safety and uptime requirements are set first, because NIST SP 800-82 Rev. 3 frames OT countermeasures around performance, reliability and safety. The output is a zone diagram, a firewall rule set for the monitoring flows and a list of accepted residual risks signed by the asset owner.
Build the production stack and identity path
The implementation team deploys two or more Grafana servers behind a load balancer, backed by a MySQL 8.0 or later or PostgreSQL 12 or later database, because SQLite does not suit production or high availability. Sign-in is connected to the plant's identity provider, and the team confirms whether the required SAML or SCIM features need Grafana Enterprise. The step closes when a failover test of a single node shows users can keep working and the database backup restores into a test instance.
Provision data sources and dashboards as code
Data sources, dashboards, folders and alert rules are written as provisioning files and kept in version control, so each plant receives the same definitions with site-specific variables. Changes go through review before they are merged, and the deployment pipeline is tested in a non-production instance first. The output is a repository where a clean install reproduces the pilot dashboards exactly, which gives the plant a record of what was running when a question comes up later.
Pilot on one line with shift display testing
The team connects one production line and builds the operator and supervisor views with the shift leads. Kiosk or shared displays are tested without per-person user accounts, using the access model the security team approved, and each display is checked for stale data, unreadable layouts on the plant hardware and alerts that reach the right people. The pilot is complete when operators sign off that the views answer their shift questions and the security team confirms no write path to control systems exists.
Verify under plant load and failover
Before wider rollout, the team tests dashboard query load during peak production, confirms data source timeouts and gaps are visible on screen, and repeats the node and database failover tests with the pilot live. Alert duplication is checked against the high availability guidance, since alerting needs extra configuration to avoid duplicate notifications. The step produces a written test record with pass or fail results and the actions taken on each failure.
Extend to other sites with a documented update cycle
The pattern is copied to other sites from the same code base, with each site's zones, sources and identity settings recorded in its own configuration. A patch and update procedure is written for the plant, based on Grafana's published release cadence: patch releases at least monthly, minor releases every other month, and major releases once a year, each with its support window. The procedure includes a test instance, a rollback path and a sign-off from the asset owner, and the rollout is complete when every site runs the approved version on a schedule the plant has accepted.

What manufacturers ask before hiring a Grafana partner

What drives the cost of a Grafana deployment for manufacturing?

The main drivers are the number of plants and sites, the number and type of data sources, the number of network zones the stack must reach, how users sign in, and how much validation and documentation the plant needs. Each site adds connectivity work, data source configuration and testing against real historian or SQL schemas. Identity integration adds effort when it has to match plant and corporate directories. Validation and documentation add effort when a quality or audit team needs evidence of how the system was installed, changed and tested. Ask any partner for a written quote that lists these items separately, with the assumptions behind each one, so you can see which parts scale with sites and which are fixed.

Which Grafana costs are one-time and which recur?

Design, installation, data source integration, dashboard build, identity setup and initial validation are usually one-time costs under a fixed-scope engagement. Recurring work includes applying patch releases, planning minor and major upgrades, maintaining dashboards as plant layouts and tags change, and reviewing access and plugins. Grafana's upgrade guidance describes major releases once a year, minor releases every other month and patch releases at least monthly, and each minor release is supported for 9 months. Your recurring cost depends on how often you want to take those releases and whether your own team or a retainer carries them. Ask the quote to state the recurring work separately and to say how changes to dashboards are requested and billed.

Can plant engineers run Grafana themselves after rollout?

Plant engineers can usually maintain dashboards and alert views, but the platform itself needs an owner with server administration, database, backup and upgrade skills. Routine dashboard edits suit plant staff when they have clear access rights and a naming standard. Patching, database upgrades, certificate renewal, plugin review and restore testing need an IT or platform team. A practical handover covers the provisioning files kept in version control, a runbook for each recurring task and training for the people who will edit dashboards. Confirm with any partner which tasks transfer at handover and which stay with them under a retainer.

What does the work need from OT and IT teams?

The work needs OT engineers to confirm which historians, PLC-adjacent databases and IoT platforms can be read, through which accounts, and at what query load. IT needs to approve the network paths, firewall rules, DNS, certificates and identity integration, and to decide where the database and backups run. Safety and uptime owners must agree on change windows, because NIST SP 800-82 Rev. 3 recommends security countermeasures while keeping performance, reliability and safety requirements in view. Plan time for these reviews before design starts, since they often set the scope more than the dashboards do.

How long does a Grafana rollout for a plant take?

Rollout length depends on scope: how many sites are included, how many data sources need connecting, whether the stack runs in an isolated or offline network, and how much testing and documentation the change process requires. A single-site pilot with one or two data sources is a much smaller task than a multi-site rollout with identity integration and formal validation. Grafana's own installation guidance sizes small deployments under 25 concurrent users at 2 cores and 2 to 4 GB of RAM, which helps with infrastructure planning but does not set the schedule. Ask for a timeline in the written scope, with milestones for network approval, pilot acceptance and each site wave.

Does DeployOpen issue audit reports or certifications for our plants?

No. DeployOpen plans, builds and documents the Grafana system and prepares the controls and evidence that an assessment will look at, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. For manufacturing, the relevant frameworks often include ISA/IEC 62443 and the NIS2 and Cyber Resilience Act obligations that apply in the EU. Ask your auditor which evidence they expect for the monitoring stack, such as access records, change history and backup tests, and make sure the scope of work covers producing it.

Is Grafana Enterprise required for SSO in a plant deployment?

Not always. According to Grafana's authentication documentation, all editions support LDAP, generic OAuth, Entra ID, Okta, GitHub, GitLab and Google OAuth, auth proxy and JWT. SAML, team sync, active sync and SCIM provisioning are available only in Grafana Enterprise and Grafana Cloud. If your plant identity provider speaks one of the supported protocols, the open-source edition may be enough for sign-in. If you need SAML or automated group provisioning, the licensing decision belongs in the scope. Confirm your identity requirements before the quote is finalized, because they change both the cost and the design.

What should a written Grafana quote for manufacturing include?

A useful quote lists the sites and networks in scope, the data sources and their access method, the identity integration, the dashboards and alerts to build, the validation and documentation deliverables, and the acceptance criteria for each. It should state what the client provides, such as network approvals, test data and named reviewers, and what happens if those inputs arrive late. It should also separate one-time work from recurring support and say how changes after go-live are requested. DeployOpen works from a written scope before work starts, so ask for these sections in the scope document rather than in a verbal estimate.

Which standards a plant Grafana stack supports as evidence

Plant audits and regulations ask for proof that operational systems are monitored, change is controlled and incidents are reported. A self-hosted Grafana stack can supply monitoring and capacity evidence for several of these frameworks, but the other controls must come from the plant's own processes, tools and independent auditors.

ISA/IEC 62443 asset owner program

The ISA/IEC 62443 series organizes requirements into general, policies and procedures, system and component groups. For Grafana, the asset owner side matters most: dashboards and alerts on control networks feed the monitoring evidence for zone and conduit controls and security levels defined under ISA-62443-3-3. Check which zones Grafana reaches, how data sources cross each conduit, and who owns the security program that the monitoring supports.

NIST SP 800-82 Rev. 3 monitoring

NIST SP 800-82 Rev. 3, published in September 2023, covers industrial control systems, building automation and physical access control, and recommends countermeasures that keep performance, reliability and safety intact. Grafana dashboards over historian and PLC-adjacent data can show availability and process trends that support this guidance. Confirm which OT assets are instrumented, how long time series are retained and whether alerts reach the people who respond to OT events.

NIS2 incident reporting and fines

NIS2 Annex II lists manufacturing in NACE Rev. 2 divisions 26 to 30 as a critical sector. 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. Grafana alerting can shorten detection time, but the reporting workflow, timestamps and retained evidence must be designed into your incident process.

CRA obligations for products

The Cyber Resilience Act applies to products with digital elements from 11 December 2027, but manufacturers' Article 14 reporting of actively exploited vulnerabilities and severe incidents has applied since 11 September 2026. Plants that build or ship connected equipment should not treat Grafana as the product compliance control. Its value here is monitoring the fleet and vendor components they operate, while the product's own vulnerability handling and reporting process sits elsewhere.

21 CFR Part 11 for electronic records

Life-science plants that keep electronic records under 21 CFR Part 11 must control access, audit trails and electronic signatures for those records. A Grafana dashboard that shows process parameters is not automatically a compliant record. Confirm whether dashboard data is a GxP record, how access and changes are logged, and whether the Enterprise edition's audit and access features are needed to meet your validation plan.

Remaining controls and auditors

Grafana supplies monitoring, alerting and capacity evidence. Access reviews, change approval, backup testing, network segmentation and incident response records come from the plant's identity, ticketing and operations processes. Independent auditors and certification bodies assess the result; DeployOpen prepares systems, controls and evidence for those assessments but does not issue audit reports or certifications. Agree early which evidence Grafana produces and which the plant must supply.

How to run shift displays without user accounts safely

A shared shift display trades individual accountability for simplicity. A kiosk-style login lets a screen on the plant floor show dashboards without anyone typing a password, but every viewer then shares one identity, so Grafana's audit trail can only show that the display account looked at something, not who was standing in front of it. Decide early which displays can tolerate that, usually wall-mounted views of line status or OEE that carry no sensitive recipes, batch records or personnel data, and keep named access for anything that lets a user edit dashboards, change data sources or see restricted production detail. Confirm with your Grafana edition how team and folder permissions are assigned to the display identity, since the authentication and access model differs between open source and Enterprise, and check whether your plant's audit or quality procedures accept shared accounts for read-only views.

Limit the display account to the smallest set of dashboards and grant it viewer rights only. Put the display dashboards in a dedicated folder, give the display identity read access to that folder alone, and make sure it cannot reach the editing, data source or administration areas. Keep the underlying data source credentials out of the dashboard JSON and provisioned files so that a display user never sees them. Review the folder membership after every dashboard change, because a dashboard moved into a shared folder can inherit wider access than its authors intended. Use a separate display instance or a reverse proxy rule that only serves the display paths when the plant network is segmented from the corporate network.

Hide the version and metrics endpoints, and rotate the display credential on a schedule your plant can run. The Grafana security hardening guidance recommends hiding the version from unauthenticated users and requiring authentication for the metrics endpoint, so confirm both settings on each display host and test them from the display VLAN. Store the display password or token in your secrets manager, not on the kiosk, and plan rotation around shift changes and planned maintenance windows so a rotation does not blank a line display during production. Record who owns each display account, when it was last rotated and what it can see, because those records are the evidence an auditor or plant security team will ask for.

How DeployOpen scopes and delivers Grafana for manufacturing

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including plant networks and segmented environments. For Grafana for manufacturing, we start from the data sources, network zones and access model of your plant, then build and hand over a fixed scope agreed in writing before work begins.

How we scope

Inventory historian, SQL, IoT and log data sources, and which plant zones each one lives in.
Agree which network paths Grafana may reach, and whether the instance runs connected, segmented or offline.
Define shift display access without user accounts and which dashboards need named, authenticated users.

How we build

Install Grafana with a MySQL or PostgreSQL database, since SQLite is not suited to production or high availability.
Provision data sources, dashboards and alerting resources as code so plant changes are reviewed and repeatable.
Harden the instance, restrict plugins and verify each data source query against the agreed network boundary.

How we hand over

Deliver a written runbook covering installation, provisioning files, backups, upgrades and recovery steps.
Document the access model, plugin list, data source inventory and evidence for the controls your plant is audited against.
Walk operations and plant IT staff through dashboards, alert routing and the upgrade process before handover.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the build.
Plan patch and minor upgrades against the published release support windows, with change checks on the plant side.
Confirm with your team which support hours, response paths and OT change approvals apply before the scope is signed.

Grafana for manufacturing