Runtime Fabric
Understand the runtime infrastructure that powers workflow execution.
The Runtime Fabric is the execution layer that actually runs your workflows and agents. While the Designer Studio is where you build automations and the Management Console is where you govern them, the Runtime Fabric is where they execute — turning a published workflow into real work: calling APIs, running agents, invoking tools, and moving data.
The engine behind every run
A scalable pool of workers that executes your published workflows and agents
Where the Fabric Sits
The Runtime Fabric is one of the three core planes of the platform. Design and management happen in the control plane; execution happens in the fabric.
Designer Studio
Build workflows and agents visually.
Runtime Fabric
Executes published workflows across a worker pool.
Management Console
Govern access, environments, and observability.
Execution Model
Every run follows the same path through the fabric, whether it was started by a webhook, a schedule, or a manual test.
Trigger
A trigger fires — an incoming webhook, an app event, a schedule, or a manual run — and creates an execution request for a published workflow.
Dispatch
The fabric routes the request to a runtime instance bound to the workflow's environment, where an available worker picks it up.
Execute
The worker walks the workflow graph node by node — resolving expressions, calling connectors and MCP tools, and running agents — passing data from one node to the next.
Record
Execution state, per-node output, and traces are recorded so the run is visible in Traceability and the run history.
Runtime Instances
A runtime instance is a running deployment of the fabric, bound to a specific environment (for example Staging or Production). This is the same "Runtime Instance" you can filter by in My APIs and across the platform.
Binding execution to an environment keeps runs isolated and predictable:
Isolation
Each instance runs one environment's workflows, so a Staging run can never touch Production credentials or data.
Locality
An instance can sit close to the systems it talks to, reducing latency to internal databases, APIs, and queues.
Independent scale
Size each environment separately — a light Staging instance, a horizontally scaled Production one.
Workers & Resource Allocation
Inside each instance, work is carried out by a pool of worker processes. Each worker executes one run at a time; the pool size sets how many runs execute concurrently. Add workers to raise throughput.
| Setting | What it controls | Typical value |
|---|---|---|
| Worker count | Concurrent runs per instance (FLOWGENX_WORKER_COUNT) | 4 (default) |
| CPU per worker | Compute headroom for a run | 1 core requested, up to 2 |
| Memory per worker | Working memory for a run | 2 GB requested, up to 4 GB |
| Baseline node | Minimum host for a worker | 4+ CPU cores, 8 GB+ RAM |
Sizing rule of thumb: agent- and LLM-heavy workflows are memory-bound; high-volume connector or batch workflows are throughput-bound. Scale worker count for volume, and raise per-worker memory for large agent runs.
Scalability & High Availability
The fabric scales horizontally — throughput grows as you add workers and instances rather than by making a single node bigger.
Work distribution
Multiple runtime agents form a cluster and share the execution queue, spreading runs evenly across available workers.
Failover
If an agent goes down, the others keep serving the queue, so a single node failure does not stop execution.
Elastic capacity
Run more replicas during peak load and scale back down afterwards — on Kubernetes this can be automated with standard autoscaling.
Shared state
Clustered agents coordinate through shared state so runs, retries, and failover behave consistently across the pool.
Observability
Each runtime instance exposes Prometheus metrics so you can watch execution health from your own monitoring stack:
flowgenx_workflow_executions_total # runs started, by workflow
flowgenx_workflow_duration_seconds # end-to-end run latency
flowgenx_worker_active_count # workers currently busy
flowgenx_connection_errors_total # failed outbound connectionsFor run-level detail — the exact path a run took and where time went — use Traceability. Metrics tell you how the fabric is doing; traces tell you what a specific run did.
Where the Fabric Runs
Today the Runtime Fabric runs in FlowGenX's managed cloud. Running it inside your own infrastructure — on-premises, in a private cloud, or in your own cloud account — while still designing and managing from the control plane is on the roadmap. See Hybrid Deployment for what's planned and how to register interest.
Next Steps
Hybrid Deployment
Run the FlowGenX runtime in your own environment while managing everything from the cloud control plane — on the roadmap.
API Access Control & Gateway Management
The FlowGenX Agent Gateway provides comprehensive access control management for your APIs. This guide will help you set up groups, manage consumers, and control who can access your services through a powerful permission-based system.