stroblmeandClaude Opus 5
e5be1880fd
"What it can import is what the Modules screen installed" was true and read as a wall: every example is a self-contained file, and a function that imports half a repository looks unsupported. It is not — the manifest is handed to `uv pip sync` verbatim, so `-e /home/you/repo` installs the project you already have and a node becomes a three-line wrapper over it. The code stays in your own repository, under your own version control, importing its own siblings. Two caveats that are easy to lose an afternoon to, so both are written down: an editable install reaches the venv without a reinstall but not into a worker that already imported it — the engine's workers are long-lived, and Apply is what retires them, while an attached worker starts a process per call and is always fresh. And the path is resolved on whichever machine runs the node, while the manifest is committed to the flow repository, so a laptop path means nothing in a container. Verified rather than assumed: `uv pip sync` takes `-e`, the shim body loads through the real `load_function`, an edit is live in a fresh process and stale in a reused one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Fluksio App
Fluksio has the goal to build a revolutionary system to tackle any sort of automation challenge.
The core of Fluksio: a node-based, test-driven automation software built to scale. This
repo holds the FastAPI backend, the flow engine, and the dashboard SPA. It is served on
app.${DOMAIN} (SPA) and api.${DOMAIN} (API); the marketing site lives in the sibling
index repo.
Layout
backend/ FastAPI + SQLModel + Alembic + SQLite — the `fluksio` distribution
fluksio/flow/ the flow engine (nodes, pipeline, state backends, controller)
fluksio/cli.py `fluksio serve` / `enroll` / `worker`
worker/ the `fluksio-worker` distribution: the agent and the node runner
frontend/ React 19 + TanStack Router + Tailwind 4 + shadcn/ui
docs/ the public documentation site (zensical), served on docs.${DOMAIN}
docker/ compose.yml → compose.dev.yml → compose.local.yml (+ compose.traefik.yml)
scripts/ generate-client.sh, test.sh
Install without Docker
pip install fluksio
fluksio serve # ~/.fluksio, SQLite, prints an admin password once
fluksio enroll <code> --portal https://hub.fluksio.com # watch it from the portal
Nothing else has to be running. --data-dir puts the installation somewhere else —
worth it on a cluster, where $HOME is often a network filesystem SQLite cannot use.
git is not required but is worth having: flows are files either way, and it is what
turns each save into a commit.
The dashboard is served by the portal, so a machine with no inbound route is reached
without opening a port: it dials out.
A machine that should only run nodes for an engine elsewhere installs less:
pip install fluksio-worker
fluksio-worker --url wss://api.example.com/api/v1/workers/attach --token "$TOKEN" --labels gpu
Getting started
Normally driven from the workspace root (make init once, then make dev). Standalone:
make install # uv sync + bun install
make dev-utils # proxy and mailcatcher only
make dev-backend # FastAPI on :8000, hot reload
make dev-frontend # Vite on :5173
make test # pytest + Playwright (the e2e half needs the stack up)
make lint # ruff + mypy + biome
make generate-client # regenerate the frontend SDK from the OpenAPI schema
make help lists every target.
Documentation
The public site lives in docs/ and is built with zensical:
make docs-serve # live preview on :8000
make docs # static build into ./site
It is served at docs.${DOMAIN} by the docs service in docker/compose.yml,
and .gitea/workflows/docs.yml builds it with --strict on every push. Style
follows the root DESIGN-GUIDELINES.md; the tokens are mirrored in
docs/stylesheets/extra.css.
Repo-only material:
ROADMAP.md— strategy and feature recordNOTEPAD.md— deferred work and findingsDESIGN.md— points at the workspace root'sDESIGN-GUIDELINES.mddocs/architecture/in the siblingdocsrepo — the requirement sources