stroblmeandClaude Opus 5
11e032386b
A zensical site under docs/, served by a new `docs` compose service behind Traefik, built with --strict in CI. Same pattern the sibling n3xd workspace uses. Getting started splits the way the landing page does — one path is `pip install fluksio` and a training script, the other is a Docker stack and an afternoon in the browser — because the two audiences will not spend the same amount of time. Everything after that is shared: the concepts, the web interface (app and portal), the CLI and the API, and a reference for node types, payload types and configuration. The three flow guides move here from the docs submodule rather than being copied, so there is one version of them. Styling mirrors DESIGN-GUIDELINES.md: the app's token palette remapped onto Material's variables in both schemes, Inter, the 16px panel radius, and the one terracotta accent spent on the facility lane of the audience split. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01M7Xv3cJEW5c8AXxn2hoojV
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 installation runs offline, keeps its data on its own disk, and never contacts anything unless you connect it to a portal yourself.