Open-source SCADA/HMI for real machines.

Product path

A working SCADA/HMI foundation comes first. The reference demo and manufacturing features build on that foundation without expanding the v1.0 promise. Optional services connecting multiple sites are a later direction.

Local operation. A future view across locations.

Start with a gateway and browser on one PC, or a local server serving clients across the plant. The future direction is independent gateways at multiple locations, with optional central services for authorized remote dashboards, selected history, analytics, reporting, and business logic across sites. Central services could be self-hosted or managed in the cloud.

Local HMI operation, alarms, and operational logic must continue without internet; PLCs retain machine control. Cloud connectivity will be opt-in. Data forwarding, multi-site dashboards, and fleet management are not available today and are outside the initial beta and v1.0 scope. Read the future deployment direction →

Build visually. Bring your favorite coding agent.

Author your SCADA/HMI in the Designer, or use an external coding agent to help create screens, bindings, configuration, and Python scripts. The goal is one open project you can edit from either workflow, then preview and review in the browser Designer before publishing.

Your HMI application will have its own local project folder, ready for an optional Git repository. Use GitHub or another Git host to share branches, review changes as a team, and validate in CI. Coding agents and the visual Designer will work with the same documented source, validation tools, and preview. Pushing or merging source will not publish to a running gateway; deployment remains a separate authorized step.

No required AI provider or AI subscription to use the Designer. Portable project files, terminal tools, team repository workflows, and conflict-aware editing are planned; the supported team and agent workflows are not available yet. Read the authoring plan → See the team workflow →

Why another platform?

Industrial automation has been locked behind closed source tooling and expensive gateway licensing for decades. Tools like Inductive Automation Ignition and Rockwell FactoryTalk Optix are established choices. OpenWebHMI aims to offer small and mid-size plants an open-source, self-hosted alternative with open project authoring.

Engineers should be able to choose visual editing, terminal tools, or help from their own coding agent, while keeping control of what is published.

v1.0 scope

Engineering targets, not certified capacity. Workload, hardware, history recording rate and client subscriptions determine the supported deployment.

• Single gateway per deployment
• Target: ≤ 50,000 live tags per gateway; validation pending
• Target: 30 days of selected process history; recording-rate and storage limits apply
• Separate Edge profile for low-resource headless deployments; validation pending
• Target: ≤ 50 concurrent runtime clients with bounded subscriptions
• Five v1 driver targets: Rockwell EtherNet/IP, OPC UA, Modbus TCP/RTU, MQTT (incl. Sparkplug B), Beckhoff ADS
• Web-only runtime; Tauri desktop runtime is post-1.0
• Linux, macOS, Windows for gateway and designer

Stack at a glance

*Optix is closed source. C++/Qt is supported by Rockwell's native-runtime documentation and current ASEM/Rockwell engineering roles, while C#/.NET NetLogic is publicly documented. The exact internal boundary between its designer and runtime is not public.

Why this combination matters

• Rust owns the always-on plant-facing core: protocol drivers, tags, alarms, history, and client fan-out get memory safety and a predictable footprint without a managed runtime.
• TypeScript owns the human interface: the designer, browser runtime, and component library share web standards and a broad contributor ecosystem instead of maintaining unrelated UI stacks.
• CPython owns user automation and data work: scripts run in worker subprocesses with gateway-enforced timeouts. Available third-party packages depend on the deployment environment; process separation is not a complete security sandbox.
• Open licensing makes operator control architectural: plants can audit, self-host, air-gap, modify, and retain the system under the AGPL core and MPL protocol terms without a per-server license.

The advantage is not that Java or C# are incapable. It is that each OpenWebHMI language has one clear job, and the complete platform remains inspectable and operator-owned.

Full reasoning: docs/stack-rationale.md ↗

v1.x feature highlights

• Audit-log 21 CFR Part 11 framing: tamper-evident SHA-256 hash chain, verify CLI, and an engineering coverage map with every clause marked partial or out-of-scope. Read the mapping ↗
• Project themes and Material-inspired demo widgets: light/dark CSS-variable themes plus an opt-in demo pack covering representative controls without changing widget prop contracts. Theme editor ↗ Widget packs ↗
• Historian capacity and retention planning: SQLite-backed storage with sizing formulas, online backup/restore, and explicit opt-in pruning primitives. Historian guide ↗
• Raspberry Pi 4/5 edge deployment guide: native Pi build path, systemd unit, reverse-proxy guidance, and honest hardware-smoke boundaries for operator validation. Pi deployment ↗
• Widget export/import between projects: human-readable .owhmi-widget files, schema-version checks, tag-binding warnings, and regenerated component ids on import. Widget transfer ↗

Where we are

Earlier phase milestones established the source foundation. The current hardening and architecture work still needs validation before a public beta.

1. Source foundation Gateway and browser runtime, form-based Designer, history, alarms, authentication, scripting, and a simulator-backed Rockwell vertical slice.
2. Current work Security and command correctness, driver integration, reusable engine boundaries, browser delivery, safe project publishing, and durable history. Capacity, recovery, platform, and hardware evidence remain pending.
3. Beta planning horizon As of October 2026, allow at least another year before a public beta: October 2027 or later, subject to scope and validation. This is a planning horizon, not an announced release date. Private demos and feedback can happen earlier; production 1.0 has separate validation gates.
4. After v1.0 Optional manufacturing modules and edge + cloud services for multiple locations are separate future tracks with no committed delivery dates.

Detailed roadmap ↗

What we explicitly don't try to be

• A hard-real-time control platform.
• A safety-rated (IEC 61508 / SIL) system.
• A replacement for vendor-specific PLC engineering tooling.
• An MES platform — optional manufacturing modules are post-1.0 direction, not a 1.0 promise.
• Loads above the defined 50K-tag / 50-client Medium workload or multi-gateway deployments in v1.