stroblmeandClaude Fable 5 eb2d098d7c Remote workers: a GPU box dials in and runs the nodes bound to it
The engine runs where the automations are and the GPU is somewhere else,
usually behind a different network — so the worker connects out and the engine
answers over the socket it was given. Nothing has to expose Redis, and the
same connection works through the tunnel the hosted access will use.

What travels is the protocol the local pool already speaks, so a node cannot
tell which kind of worker it is on. A node declares device: gpu and
device_policy, the label is resolved per call (a worker attaching later needs
no rebuild), and a run whose labels nothing carries waits in the queue saying
what it waits for rather than failing — submit from the couch, the GPU box
picks it up when it is switched on.

Two things had to move with it. Compiling now happens on the machine that will
run the node: a node importing torch is correct on the GPU box and a missing
module on the engine, so checking it here failed nodes that were fine. And the
artifact endpoint accepts a worker's own credential, because storing a
checkpoint is exactly what that credential is for — and only that.

Verified against the real split: the training ran on this host (its checkpoint
names the machine and a numpy the engine does not have), streamed 40 metric
points back mid-run, and the evaluate node read the checkpoint on the engine.
Cancel kills the remote training; pulling the worker fails the run in six
seconds instead of waiting out its ten-minute timeout.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AD8SfVhzXBG2nAfFcVh3iD
2026-08-18 17:52:42 +02:00
2026-08-18 13:17:07 +02:00
2026-02-03 21:43:09 +01:00
2026-02-03 21:43:09 +01:00
2026-02-03 21:43:09 +01:00
2026-02-03 21:43:09 +01:00
2026-02-03 21:43:09 +01:00
2026-08-18 13:17:07 +02:00
2026-08-18 14:22:47 +02:00
2026-02-03 21:43:09 +01:00
up
2026-08-15 14:48:16 +02:00
2026-08-18 14:22:47 +02:00
2026-08-16 00:22:41 +02:00

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 + Postgres
  app/flow/     the flow engine (nodes, pipeline, state backends, controller)
frontend/       React 19 + TanStack Router + Tailwind 4 + shadcn/ui
docker/         compose.yml → compose.dev.yml → compose.local.yml (+ compose.traefik.yml)
scripts/        generate-client.sh, test.sh

Getting started

Normally driven from the workspace root (make init once, then make dev). Standalone:

make install       # uv sync + bun install
make dev-utils     # db, adminer, proxy, mailcatcher, prestart only
make dev-backend   # FastAPI on :8000, hot reload
make dev-frontend  # Vite on :5173
make test           # pytest + Playwright
make lint           # ruff + mypy + biome
make generate-client  # regenerate the frontend SDK from the OpenAPI schema

make help lists every target.

Documentation

  • ROADMAP.md — strategy and feature record
  • NOTEPAD.md — deferred work and findings
  • DESIGN.md — points at the workspace root's DESIGN-GUIDELINES.md
  • docs/architecture/ in the sibling docs repo — the requirement sources
S
Description
No description provided
Readme AGPL-3.0
7.1 MiB
Languages
Python 54%
TypeScript 42.6%
CSS 1.9%
HTML 0.5%
JavaScript 0.5%
Other 0.3%