Vom visuellen Workflow zur laufenden Engine: ForestHubs Deployment-Modell
Hinweis: Dieser Beitrag wurde unter dem Messaging-Stand vom Mai 2026 neu verfasst. Die ForestHub-Engine generiert keinen Code mehr pro Gerät. Stattdessen ist der Graph das Artefakt und die Engine interpretiert ihn zur Laufzeit.
Wenn Sie einen Workflow auf ein Linux-Edge-Gerät ausliefern, liefern Sie ein versioniertes `workflow.json`-Artefakt aus — keinen Quellcode, kein Pro-Gerät-Binary. Die Engine ist ein Go-Binary in einem distroless Docker-Image (~10–15 MB, linux/amd64 + linux/arm64), das das Artefakt lädt und den Graphen ausführt. Ein Image, jedes Linux-Edge-Gerät.
Drei Deployment-Wege
Aus dem Builder können Sie via API-Push deployen (`POST /deploy` auf den registrierten Engine-Endpoint), via Direct-IP im LAN (die Engine ist unter `ENGINE_PUBLIC_URL` erreichbar) oder via Bootstrap-Bundle Download: ein Tarball mit `docker-compose.yml`, `manifest.json` und einem README. Das Bundle ist der Offline- / Air-Gapped-Weg — auf das Zielgerät kopieren, `docker compose up` ausführen, der Workflow läuft.
Warum Interpretation, nicht Generierung
Pro-Gerät-Codegen erzwingt eine Build-Matrix: jedes Target braucht einen Cross-Compiler, jede Workflow-Änderung einen Recompile, jeder Bugfix ein Re-Flash. Interpretation lässt diese Matrix zusammenbrechen. Die Engine ist auf jedem Gerät dasselbe Binary. Der Workflow ist derselbe Graph, egal wo er läuft. Eine Migration von einem Raspberry Pi zu einem Jetson ist ein Redeploy, kein Rewrite.
Was im Bundle liegt
Das Bundle enthält einen gepinnten Engine-Image-Digest, das `workflow.json`-Artefakt, das Device-Manifest (deklarierte Pin-Capabilities, erlaubte Protokolle) und ein README mit dem exakten `docker compose up`-Befehl. Alles, was zur Ausführung nötig ist, liegt im Tarball — kein Netzwerkzugriff zum Start nötig.
Pro-Gerät-Deployhistorie
Die Device Registry trackt jeden Deploy pro Gerät mit Zeitstempel und gepinnten Engine-Versionen. Ein Rollback ist ein Klick: alte Version auswählen, deployen. Die Engine lädt den Workflow heiß nach, ohne den Container neu zu starten — die meisten Graph-Änderungen brauchen keinen Container-Bounce.
Mehr Details zur Engine? Siehe /platform/engine.
Der Graph ist das Programm. Das LLM ein Knoten — und die Engine ist die Runtime, die beide interpretiert.