Execution Model
When you press Run, BioNodulo turns your graph into a scheduled set of tasks and executes them in dependency order. This page explains what happens under the hood.
From graph to schedule
- Validation. The graph is checked for type errors, cycles, and missing required inputs. Invalid graphs never start a run.
- Topological sort. Nodes are ordered so that every node runs only after all of its upstream dependencies are complete.
- Scheduling. Independent nodes run in parallel up to the resource and concurrency limits of your tier.
- Execution. Each node runs in an isolated environment (a container in the cloud, a managed subprocess on the desktop).
- Caching. Completed node outputs are cached and content-addressed so they can be reused on re-runs and after interruptions.
Cloud runtime architecture
On the cloud platform, execution is split across two layers:
- UI pods — lightweight, per-user containers that host the editor and stream events. These are ephemeral and scale to zero when you’re idle.
- Execution pods — heavyweight, memory-rich containers that actually run the tools. Sized per the resource tier you pick.
A workflow orchestrator coordinates long-running jobs with deterministic replay and automatic checkpointing, while a task queue dispatches individual node executions. This split is what lets BioNodulo run jobs lasting hours to days — far beyond the minutes-long jobs typical of GPU inference tools.
Progress streaming
While a run is active:
- Editor events flow over a WebSocket connection (bidirectional, low latency) to keep the canvas in sync.
- Run progress is streamed via lightweight server-sent events (SSE), which pass cleanly through corporate firewalls and have low server overhead.
You’ll see per-node state changes, live log tails, and a running credit cost.
Concurrency & limits
Each tier defines:
- Max RAM per execution pod.
- Max runtime per job (1 hour on Free up to 7 days on Enterprise).
- Concurrent jobs you can run at once.
See Resource Tiers for the full table.
Failure handling
- A failed node turns red and blocks its downstream dependents.
- Independent branches keep running.
- Already-completed nodes are cached, so after you fix the problem and re-run, only the failed node and its descendants re-execute.