Everything you need for a local evaluation

Overview

Forge is a single-plant, Docker-first manufacturing execution system. It is not a hosted SaaS sandbox, and an evaluation install must not be connected to a production OT network. The application source is private; evaluators run prebuilt forge release binaries rather than a source checkout.

System requirements

These are planning inputs, not a measured performance guarantee. Windows on ARM and Intel macOS are not currently release targets.

Evaluation quickstart

1. Download and verify a release

   Get the asset for your host and its published .sha256 checksum from the release page, then verify before running: shasum -a 256 forge-<os>-<arch> (Linux/macOS) or Get-FileHash .\forge-windows-amd64.exe -Algorithm SHA256 (Windows). Do not substitute a checksum from another release.

2. Run the setup wizard

   Make the binary executable and run forge up. The first interactive run verifies Docker/Podman Compose, selects a runtime and available HTTP port, and creates a private configuration directory and credentials. For automation, pass flags directly: forge up --non-interactive --runtime docker-compose --http-port 8080.

3. Sign in

   Open http://localhost (or the selected port) and sign in as admin with the printed password. Save it in a password manager rather than a ticket or screenshot.

4. Understand the evaluation window

   A fresh evaluation runs for two hours from first activation, persists locally, and works offline once images are pulled. An administrator can reset it from Admin → System → Forge license. A reset is auditable; it is not a production license and does not retain real plant data across resets.

5. Walk through the seeded scenario

   Inspect a work order and its routing, follow lot and material-consumption genealogy, review live tags and an OEE/downtime view, and open an uploaded Rockwell L5X program for routine/rung search, cross-reference, and version diff. If an LLM provider is configured, try Agent separately; it stays off until a provider is enabled.

The walkthrough does not cover unit serialization, quality holds, warehouse execution, high availability, multi-plant SaaS, or FBD/SFC authoring. PLC logic analysis is read-only: Forge is not a PLC programming or download tool.

Services

The core stack is five Docker Compose services. Only the frontend HTTP/HTTPS ports are exposed by default; development simulator ports are opt-in via the dev Compose profile.

API surface

• Health: GET /api/health (no auth; includes database size)
• Auth: session login/refresh, with OIDC/LDAP when configured
• Production: work orders, routing definitions/versions, operation execution, lots, genealogy, reservations, and consumptions
• Reporting: OEE single-window/series/pareto, work-order and operation OEE, scheduled shift production reports
• Live data over WebSocket: tag values, alarm lifecycle, and Agent chat/tool streaming
• Admin: retention, stats, audit, backups, auth settings, notifications, external DB/ERP write-back, AI providers

Backup, restore, and upgrade

Backups are self-contained archives covering the database, PLC uploads, and historian buffer, created and restored from Admin → System → Backup & restore or the bundled CLI scripts. An upgrade runs backup, pull, rebuild, migrate, and health check in sequence.

Restore replaces the live database and on-disk PLC/buffer volumes, and OT connectors pause briefly during the process. JWT_SECRET and .env are kept outside backups and are not exported.

Reset and diagnostics

Stop the stack without losing state, then inspect logs and status:

forge down
forge logs
forge ps

Do not remove Docker volumes or the CLI configuration directory unless you intend to start a new evaluation, doing so destroys work orders, historian data, configuration, and uploaded PLC files. When requesting support, capture redacted logs, forge ps, Docker version output, and GET /api/health. Never attach .env, credentials, backups, plant data, or API keys.

Security

Forge is currently supported as a single-plant, on-premises Docker Compose deployment. Pilot and production installs must set FORGE_ENV=pilot or production, replace all default credentials, and enable TLS; the gateway refuses to start otherwise. Development defaults and simulator services are not safe for plant networks.

• Use a managed secret store for database, JWT, TLS, directory, notification, and external database credentials
• Restrict CORS origins to the actual plant UI origins
• Review operator versus administrator permissions before connecting live OT
• Schedule backups and perform a restore drill
• Confirm whether Agent requests can leave the plant when a cloud LLM provider is enabled

To report a suspected vulnerability, use the private contact in your evaluation or pilot agreement and request a security escalation. Include the affected version, deployment mode, reproduction steps, and impact; never include credentials, plant data, or backup archives. This is a baseline pilot policy, not a certification or security guarantee.

Support policy

The paid-pilot agreement is the source of truth for commercial support commitments. This is the operating vocabulary Forge uses day to day.

When contacting support, include the Forge version, health response, affected route or workflow, timestamps, recent changes, and relevant logs. Never send passwords, JWTs, TLS private keys, raw backups, or unredacted external database credentials.