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
58 lines
2.7 KiB
Markdown
58 lines
2.7 KiB
Markdown
# 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: gpu` runs 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](getting-started/index.md) 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](https://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](concepts/flows.md) |
|
|
| Drive Fluksio from the browser | [The interface](interface/index.md) |
|
|
| Drive it from Python, a shell or CI | [Code and the CLI](code/cli.md) |
|
|
| Look up a node type or a payload type | [Reference](reference/node-types.md) |
|
|
|
|
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](interface/portal.md) yourself.
|