Rename Installation to Instance
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
This commit is contained in:
@@ -1,7 +1,7 @@
|
||||
# Configuration
|
||||
|
||||
Every setting comes from the environment, or from an env file. Which file
|
||||
depends on how the installation was started:
|
||||
depends on how the instance was started:
|
||||
|
||||
| Started with | Reads |
|
||||
|---|---|
|
||||
@@ -36,7 +36,7 @@ what the container images do to pin everything onto `/data`.
|
||||
| `managed` | a venv the engine builds under `DATA_DIR` and owns, which the Modules screen installs into with `uv pip sync`. The container images set this: the venv in them holds the app and nothing of anybody else's. |
|
||||
| a path | that interpreter, or that venv, whatever it is. |
|
||||
|
||||
An installation that already has a managed venv keeps it on upgrade under
|
||||
An instance that already has a managed venv keeps it on upgrade under
|
||||
`auto`, because it may hold packages somebody installed on purpose.
|
||||
|
||||
!!! warning "The four files that must be on persistent storage"
|
||||
@@ -112,10 +112,10 @@ remember it is fixed at build time: changing it means rebuilding that image.
|
||||
`delay` with a cron expression fires on local time. Left at `UTC`, "off at
|
||||
02:00" means two in the morning UTC, which in most of the world is neither two
|
||||
o'clock nor the same hour in summer as in winter. Set it to where the
|
||||
installation is.
|
||||
instance is.
|
||||
|
||||
`production` closes `/docs`, `/redoc` and the OpenAPI document, because the
|
||||
schema enumerates every endpoint the installation serves — including the paths
|
||||
schema enumerates every endpoint the instance serves — including the paths
|
||||
webhook nodes mounted at runtime. It also turns a `changethis` secret from a
|
||||
warning into a refusal to start.
|
||||
|
||||
|
||||
@@ -5,7 +5,7 @@ editor generates from its parameter schema, so they all behave the same way.
|
||||
|
||||
Anything here could be written as a **Function** node — that is what the
|
||||
function node is for. These exist because the same handful of shapes account
|
||||
for most of a real installation, and a rule you fill in is easier to read on a
|
||||
for most of a real instance, and a rule you fill in is easier to read on a
|
||||
canvas, and to change, than five lines of code repeated eighty times.
|
||||
|
||||
`GET /flows/node-types` returns this list with each type's full parameter
|
||||
@@ -138,7 +138,7 @@ thing configured elsewhere.
|
||||
| `start_delay` | `1.0` | how long to wait before that first emission |
|
||||
|
||||
The scheduler: a `cron` expression here is what makes a flow run by the clock.
|
||||
It is also the most-placed node in a real installation — mostly as a button
|
||||
It is also the most-placed node in a real instance — mostly as a button
|
||||
someone presses.
|
||||
|
||||
### Delay & schedule
|
||||
|
||||
Reference in New Issue
Block a user