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
73 lines
2.6 KiB
Markdown
73 lines
2.6 KiB
Markdown
# Pick your starting point
|
|
|
|
People arrive at Fluksio from two directions, and the honest answer to "how do
|
|
I set this up?" is different for each — not just in the commands, but in how
|
|
much of an afternoon it is reasonable to spend.
|
|
|
|
Pick the one that sounds like you. Everything past this section is the same for
|
|
both.
|
|
|
|
<div class="fluksio-lanes" markdown>
|
|
|
|
<div class="fluksio-lane fluksio-lane--science" markdown>
|
|
|
|
### Data science
|
|
|
|
*"I have a training script. I want to stop losing track of what I ran."*
|
|
|
|
One `pip install`, one command, and you are writing Python again. No Docker, no
|
|
database, no ports to open. Flows are files, runs are rows, and the metrics are
|
|
just the numbers your loop already produces.
|
|
|
|
[Set up for experiments →](data-science.md)
|
|
|
|
</div>
|
|
|
|
<div class="fluksio-lane fluksio-lane--facility" markdown>
|
|
|
|
### Facility automation
|
|
|
|
*"I have a homelab and a pile of sensors. I want them to do something."*
|
|
|
|
A stack you bring up once and leave running: the engine, a broker, a
|
|
time-series database, dashboards, alerting. Most of the work happens in the
|
|
browser, and it is worth doing properly because you will live in it.
|
|
|
|
[Set up a homelab instance →](facility-automation.md)
|
|
|
|
</div>
|
|
|
|
</div>
|
|
|
|
## Not sure?
|
|
|
|
Some rough tells:
|
|
|
|
| | Data science | Facility automation |
|
|
|---|---|---|
|
|
| **The flow** | starts, finishes, has a result | never ends |
|
|
| **You mostly** | write Python | wire nodes in the browser |
|
|
| **Time to first result** | a few minutes | an afternoon |
|
|
| **Runs on** | your laptop, or a login node | a box in a cupboard |
|
|
| **Data lives in** | SQLite beside the flows | InfluxDB, usually |
|
|
| **The thing you look at** | run history and loss curves | a dashboard, maybe on a wall |
|
|
|
|
If both describe you — a lab with instruments to drive *and* models to
|
|
fit — start with the data-science path. It is the smaller instance, and it
|
|
grows into the other one without being reinstalled: the same engine, the same
|
|
flows, just more of them running all the time.
|
|
|
|
## What is the same either way
|
|
|
|
Whichever door you came in:
|
|
|
|
- **Flows are files in a git repository.** Every save is a commit. You can read
|
|
the history with ordinary git, and you can copy a flow between instances
|
|
by copying a directory.
|
|
- **Editing is separate from running.** You edit a draft; the engine keeps
|
|
running what was published until you publish.
|
|
- **Nodes are typed.** A port declares what it carries, and a mismatch is
|
|
caught at edit time rather than at three in the morning.
|
|
- **Everything the browser does is an API call.** The dashboard is a client of
|
|
the same REST API you can script against.
|