The Inflowenger Ecosystem
One runtime. Many surfaces. Each repository is a dimension of it.
Inflowenger is not one program you install. It is a runtime, a seam for wiring your own backend into it, a protocol for extending it, a catalog of things that extend it, and two products that prove the whole thing holds up. Each of those lives in its own repository — which is honest engineering and, from outside, looks like sprawl.
This page is the map. It says what each piece is, which layer it belongs to, and — most usefully — which one to open first depending on what you actually want to do.
Three layers, one question each
Almost every confusion about this ecosystem comes from asking one layer to answer another layer's question. Sorting the repositories is much easier once the layers are named.
What does this process mean in a business? A security policy, a contract obligation, an audit trail.
Can a person or an AI build, run, inspect and change it? The node palette, the LLM and Jev nodes, the assistant that builds flows with you.
Can this process exist at all? Can it loop, wait a week, call a child flow, survive a crash, and report what it did?
Most of what makes FloMorphic unusual isn't in FloMorphic. It is a glass-box harness for long-running, stateful and evolving software processes, running on a durable process runtime that reserves nothing for it.
Pick by what you want to do
Nobody needs all of this. Find the row that matches your intent and ignore the rest of the page until it becomes relevant.
Two docker compose stacks take you from zero to a running ecosystem plus the developer panel. There is a one-liner.
Context, nodes, edges, flows — the six primitives the engine can actually execute, and nothing else.
The knowledge base. Written to be checkable rather than persuasive, with the compiler-hook story at its centre.
The Go SDK for wiring your own backend in. You own the data; the engine walks the graph. The compiler hook is where your vocabulary lives.
The mental model, a build-from-zero guide, the SDK matrix, and how to get listed.
Importable FloMorphic exports, each teaching one reusable pattern — eval loops, RAG, re-embedding a whole collection, a fleet audit.
A plugin node that is an agent, installed on the box where the work has to happen. Workspace-jailed, shell opt-in.
Security governance where all business logic lives in FloMorphic workflows and the product itself is only the view.
Plugin handles into every system, a governed records-to-cases register over them, and whatever the organization needs authored as flows — an ISMS, a compliance programme, regulatory reporting — instead of shipped as releases.
Legate — a plugin that is an agent
The built-in LLM and MCP nodes run inside the platform and reach outward. Legate moves that shape somewhere else: it is installed on one machine — a build server, a jump host, a box inside a segment the platform cannot reach — and a workflow hands it an instruction rather than a script.
It ships that machine's capabilities as its own in-process MCP server and consumes them as a client, so local files and a vendor's hosted MCP tools look the same to the model. Workspace-jailed; the shell is opt-in. One node call is one unit of work, not one model turn.
Every repository, and what it is for
Grouped by the job it does rather than by which organisation it sits under. Everything listed here is public.
The runtime and its seam
How a process lives. The engine and control plane are closed but contracted; the seam you build against is open.
Zero to a running ecosystem plus the developer panel, in two docker compose stacks. Start here.
Inflowenger →The Go backend SDK. Own the flow definitions and the execution context, expose domain logic as callable steps, and compile any authoring format into the primitive node map.
Inflowenger →The developer panel — the surface for watching what the runtime is doing while you build against it.
Inflowenger →The API behind the developer panel.
Inflowenger →The plugin layer
The one node type that never compiles away. A plugin is a live external process speaking inflowv1 over NATS — and it is how the runtime reaches anything real.
The index of plugin nodes, and the knowledge base for building your own: the mental model, build-from-zero, the SDK matrix, how to publish.
Inflowenger →The reference inflowv1 implementation. A small Go program becomes a canvas node with its own form, actions and live progress.
Inflowenger →The Python port, mirroring the Go SDK file-for-file on the same wire format — so a Python plugin is interchangeable with a Go one.
Inflowenger →The Node.js / TypeScript port of the same protocol.
Inflowenger →The C++23 port, for a node that has to sit close to something: a device, a driver, a codec, a solver, or an existing C/C++ library that is the whole reason the node exists.
Inflowenger →The front-end npm packages. @inflowenger/plugin-form-builder renders a plugin’s form from its JSON Schema + UI Schema — the x-inflow-ui and x-inflow-notif keys — and @inflowenger/flow-trace parses a run’s event stream for the canvas.
Inflowenger →The nodes that ship in the box: LLM, MCP, HTTP, Jev. Worth reading as the reference for how a first-class node is written.
FloMorphic →Plugins in the wild
Each owns its own repository — the catalog indexes them, it does not host them. New ones arrive regularly; the catalog is always the current list.
Plugin as agent: an agent that lives on one machine, ships its host as an in-process MCP server, and is handed an instruction rather than a script.
Open page →Claude as an agent on the plugin’s own host — one durable Claude Code session per call site, working in a real tree, with a port for the questions it cannot answer alone.
Inflowenger →The same shape for OpenAI Codex — one durable thread per call site, fenced by the operating system’s own sandbox, with a port for the approvals it cannot settle alone.
Inflowenger →Postgres as a node.
FloMorphic →MongoDB as a node.
FloMorphic →MySQL as a node.
Inflowenger →Microsoft SQL Server as a node: read, write, upsert records and create tables — the reach into the estate most organisations actually run.
Inflowenger →ClickHouse as a node — the analytical end of the store family.
Inflowenger →SQL over files, as a node. CSV, Parquet, JSON and Excel queried in place — on disk or in S3/MinIO — with nothing to load first.
Inflowenger →Qdrant vector store as a node. Embedding happens inside the node via its provider profile, which is what makes RAG two nodes and an edge.
Inflowenger →Vector, full-text and hybrid search on the embedded zvec engine — a vector store that is a library rather than a service, so retrieval costs a node and not a deployment.
Inflowenger →SSH and telnet sessions to network devices — the reach into gear that has no API.
Inflowenger →The nuclei scanning engine as a node — written for Venapce’s own collection cycle, and wire-identical on any inflowv1 host.
Venapce →A real browser as a node: navigation, extraction and everything that only exists behind a logged-in page.
Venapce →GitHub, authenticated through OpenConnector so the flow never holds the token.
FloMorphic →Gmail over OpenConnector auth.
FloMorphic →Google Docs, Sheets, Calendar and Drive as nodes.
FloMorphic →Document and image OCR as a node.
FloMorphic →The products
Proof the claim survives contact with something real — once at the harness layer, then twice over in a product a layer above it.
Contract-driven AI on a runtime built from explicit primitives. Experts define the process, the valid states, the allowed transitions and the approvals; AI contributes judgment inside them.
Open page →Install FloMorphic and make the system you already run AI-native without a rewrite. Also carries the changelog.
FloMorphic →FloMorphic's own backend — itself an inflow-fusion consumer, with nothing reserved for it in the runtime.
FloMorphic →The canvas and the web application: the node palette, the drawers, the AI assistant that builds flows with you.
FloMorphic →Security governance where every piece of business logic lives in a FloMorphic workflow and the product is only the view — a posture builder and BI surface.
Open page →Install Venapce — the panel, the API and the collection plugins as one stack. The public front door.
Venapce →The Venapce backend — another inflow-fusion consumer. It keeps the pipeline in Postgres and fronts Superset for the dashboard builder, so the browser never talks to Superset itself.
Venapce →The Vue 3 panel: fleet, posture, the issue pipeline, and a BI surface that renders Superset’s data natively through ECharts rather than embedding it in an iframe.
Venapce →Expert-authored operation packages — versioned FloMorphic workflows with a manifest, operator params and a readiness check per requirement, installed and run against your own estate.
Venapce →The osquery fleet manager Venapce reads its endpoint sense from, forked to carry the bits the collection cycle needs.
Venapce →One-command osctrl install, for running that fleet server on your own host instead of on the hosted trial space.
Venapce →The intelligence and orchestration fabric for data governance: a records-to-cases register, a flow per process, and the execution record of every run as the evidence — on-prem, inside the building.
Open page →The installer and the single-container appliance image. The public front door for SurfStat.
SurfStatLab →Knowledge
The parts written to be read rather than run.
The knowledge base for the runtime, the fusion SDK, the inflowv1 protocol and the products. Includes an ecosystem map appendix for exactly this kind of sprawl.
Inflowenger →Importable flow exports, each teaching one reusable pattern. Credentials are never in an export, so a flow is safe to commit and share.
FloMorphic →The concepts, the node reference, the architecture, and the interactive form-builder lab.
Open page →The essays. Flow Engineering as an architecture rather than a prompting trick, and the arguments behind each design decision.
Open page →What isn't open yet, and why it doesn't block you
Two components are not open source for now — and that may well change: Infra, the headless control plane that owns identity, credentials and the embedded NATS bus and keeps a registry of live engines; and Fractal, the headless engine that takes a compiled node map and walks it durably — across crashes, through loops, pausing for days.
What is documented and stable is their contracts: the REST endpoints, the NATS subjects, the guarantees. That is what you build against, and it is what the book covers. Everything you must write to run on this platform is open — the fusion SDK, every plugin SDK, the protocol, the catalog, the built-in plugins, the products' own surfaces.
Identity, credentials, embedded NATS, engine registry, space isolation.
Durable execution of a compiled node map. Loops, waits, resumes, event stream.
Your backend via inflow-fusion, your plugins via inflowv1, your flows, your product.
Still not sure what this is?
Read the runtime's own argument for itself, in order: what the model is, how anything becomes a flow, how it gets extended, and whether the claim survives contact with two real products.