Files
app/docs/index.md
T
stroblmeandClaude Opus 5 bdad6d7fc2
Docs / docs (push) Successful in 37s
Playwright Tests / test-playwright (1, 2) (push) Failing after 1m35s
Playwright Tests / test-playwright (2, 2) (push) Failing after 17s
pre-commit / pre-commit (push) Failing after 2m8s
Test Backend / test-backend (push) Failing after 2m48s
Compose Smoke Test / test-compose (push) Failing after 13s
Playwright Tests / merge-reports (push) Failing after 2m25s
Make the docs state things rather than argue them
The site read as a design journal: rationale paragraphs, hedges
("deliberately", "on purpose", "genuinely"), meta-commentary about the docs
themselves, and one em-dash every ten lines carrying an aside.

Roughly twenty rationale blocks are gone or reduced to what a reader needs
in order to use the thing. Em-dashes go from 507 to 135, and what is left is
structural rather than prose: list and definition separators, table cells,
and four inside code blocks that quote what the CLI actually prints.

Also: api.example.com becomes api.fluksio.com (the emails stay, since
bootstrap.py really defaults to admin@example.com and RFC 2606 reserves it);
the mqtt table gains the two settings it had drifted behind on and inject's
wording matches the engine; llms.txt lists the two connector pages that were
in the nav but not in it; and the two device/device_policy notes now agree.

Builds clean under `zensical build --strict`.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015YrQnKV3bnQd4K342y8tKj
2026-08-31 10:49:58 +02:00

53 lines
2.3 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 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.