From Visual Workflow to Running Engine: ForestHub's Deployment Model
Note: This post has been rewritten under the May 2026 messaging. ForestHub's engine no longer generates per-device source code. Instead, the graph is the artifact and the engine interprets it at runtime.
When you ship a workflow to a Linux edge device, you're shipping a versioned `workflow.json` artifact — not source code, not a per-device binary. The engine is a Go binary in a distroless Docker image (~10–15 MB, linux/amd64 + linux/arm64) that loads the artifact and runs the graph. One image, any Linux edge device.
Three Deployment Paths
From the builder, you can deploy via API push (`POST /deploy` on the registered engine endpoint), via Direct-IP within your LAN (the engine exposes itself at `ENGINE_PUBLIC_URL`), or by downloading a bootstrap bundle: a tarball containing `docker-compose.yml`, `manifest.json`, and a README. The bundle is the offline / air-gapped path — copy it to the target, run `docker compose up`, and the workflow is live.
Why Interpretation, Not Generation
Per-device codegen forces a build matrix: every target needs a cross-compiler, every workflow change needs a recompile, every bug-fix needs a re-flash. Interpretation collapses that matrix. The engine is the same binary on every device. The workflow is the same graph regardless of where it runs. Migrating from a Raspberry Pi to a Jetson is a redeploy, not a rewrite.
What Lives in the Bundle
The bundle includes a pinned engine image digest, the `workflow.json` artifact, the device manifest (declared pin capabilities, allowed protocols), and a README with the exact `docker compose up` invocation. Everything needed to run is in the tarball — no network access required to start the engine.
Per-Device Deploy History
The Device Registry tracks every deploy per device, with timestamps and engine-version pins. Rolling back is a one-click operation: select a previous version, deploy. The engine hot-reloads the workflow without restarting the container — most graph changes don't require a container bounce.
Want to see the engine subpage with the full deployment story? See /platform/engine.
The graph is the program. The LLM is a node — and the engine is the runtime that interprets both.