Docs / docs (push) Successful in 33s
Playwright Tests / test-playwright (1, 2) (push) Failing after 1m26s
Playwright Tests / test-playwright (2, 2) (push) Failing after 15s
pre-commit / pre-commit (push) Failing after 1m43s
Test Backend / test-backend (push) Failing after 2m46s
Compose Smoke Test / test-compose (push) Failing after 12s
Playwright Tests / merge-reports (push) Canceled after 0s
A python node's ports and settings arrive as keyword arguments, so a declared name its `process` does not take was a TypeError on every call — and a node that loads fine and fails every time it runs is the quiet kind of broken: the hosted demo did it 720 times an hour for two days and the health badge read ok throughout. `_build_node` now reads a written body with `ast` and refuses the mismatch at load, so the node is an error on the canvas and an issue on publish. Skipped for `**kwargs`, a decorated or absent `process`, and the template a new node opens with. The SDK's generated shim always takes `**settings`, so synced flows are untouched. `/observability/summary` names a node that has failed in the last fifteen minutes and reads degraded while it does, which is what would have made the badge amber. `nodes.failing` carries the count. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SkgNtaR6JspnHBFFP6crZj
54 lines
2.4 KiB
Markdown
54 lines
2.4 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.
|
|
|
|
It runs two kinds of graph:
|
|
|
|
- A **live flow** produces values forever. A sensor publishes, a rule fires, a
|
|
relay closes, a dashboard on the wall shows what happened. It never ends.
|
|
- A **run** produces a value once. Parameters go in, stages execute, and it
|
|
finishes, leaving metrics, artifacts and a record to compare against.
|
|
|
|
Both use the same nodes, the same type checking, the same editor and the same
|
|
API.
|
|
|
|
## What you get
|
|
|
|
- A **flow engine** that owns your graph, checks the types on every edge, and
|
|
keeps running when a node fails.
|
|
- 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, with
|
|
no second server and no 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** covering everything the browser does, plus an MCP endpoint for
|
|
agents.
|
|
|
|
## Start here
|
|
|
|
[Getting started](getting-started/index.md) has two paths: one installs a Python
|
|
package, the other stands up a server. Everything after that is shared.
|
|
|
|
To look before installing, the hosted demo at
|
|
[fluksio.com](https://fluksio.com) runs a real instance: a small-house panel, a
|
|
media screen, and a lab where a training pipeline runs and its runs are
|
|
compared, four screens on one panel.
|
|
|
|
## 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.
|