stroblmeandClaude Opus 5
d01a8dad37
Follows the portal: the noun is "instance" everywhere the app says it — UI strings, CLI output, error details, docs and comments. The wire keys (`instance_id`, `instance_token`) and the hub route this calls move with it. An existing cloud.json is adopted rather than refused: without the key alias the dataclass fails to parse, which the caller swallows and reads as "never enrolled" instead of "reconnect". `instance_key` on a node type becomes `target_key`. It means the outside thing a node points at, which is a different sense of the word, and keeping both would put two meanings of "instance" in one codebase. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015YrQnKV3bnQd4K342y8tKj
2.7 KiB
Fluksio
Fluksio is a node-based automation engine. You describe what should happen as a graph of small pieces of logic, and it keeps that graph running — reacting to what arrives, or executing once from parameters to a result.
Two very different jobs turn out to be the same shape, which is why the same engine does both:
- A house, a lab or a plant produces values forever. A sensor publishes, a rule fires, a relay closes, a dashboard on the wall shows what happened. The flow never ends.
- An experiment produces a value once. Parameters go in, stages execute, and at some point it is done and has left behind metrics, artifacts and a record you can compare against last month's.
The first is a live flow, the second is a run. Both are the same nodes, the same type checking, the same editor and the same API.
What you actually get
- A flow engine that owns your graph, checks the types on every edge, and keeps running when a node fails rather than taking the rest down with it.
- A canvas that lays flows out for you and an editor for the Python inside each node — with the running values drawn on the wires while you work.
- Dashboards built next to the logic that feeds them, including ones you can hang on a wall tablet that has no keyboard.
- Runs: parameters, metrics, artifacts, sweeps, and a queryable history — without a second server and without paying a project bootstrap per execution.
- Distributed workers: a node marked
device: gpuruns on the machine that has one, which dials out to the engine rather than needing to be reachable. - An HTTP API that came first — everything the browser does, you can do from a script — plus an MCP endpoint for agents.
Start here
The setup is genuinely different depending on what you are here for, so Getting started splits in two: one path installs a Python package and gets out of your way, the other stands up a server you will be running for years. Everything after that is shared.
If you would rather look before installing, the hosted demo at fluksio.com runs a real instance with a small-house panel and a training pipeline on it.
Where things are
| If you want to… | Read |
|---|---|
| Understand what a flow, a node and a message are | Concepts |
| Drive Fluksio from the browser | The interface |
| Drive it from Python, a shell or CI | Code and the CLI |
| Look up a node type or a payload type | Reference |
Fluksio is self-hosted by default. An instance runs offline, keeps its data on its own disk, and never contacts anything unless you connect it to a portal yourself.