stroblme
b2aa932b6d
Docs / docs (push) Successful in 26s
Playwright Tests / test-playwright (1, 2) (push) Failing after 4m7s
Playwright Tests / test-playwright (2, 2) (push) Failing after 2m30s
pre-commit / pre-commit (push) Failing after 2m42s
Test Backend / test-backend (push) Failing after 3m3s
Compose Smoke Test / test-compose (push) Successful in 32s
Playwright Tests / merge-reports (push) Successful in 1m51s
107 lines
4.0 KiB
Markdown
107 lines
4.0 KiB
Markdown
# Secrets, modules and alerts
|
|
|
|
Store credentials, manage node dependencies and choose where failures go.
|
|
These screens help keep an instance humming.
|
|
|
|
## Secrets
|
|
|
|
Open **Secrets** as a superuser, then add a name and value. The list shows
|
|
names only; saved values are not displayed again.
|
|
|
|
Reference a secret from a node setting:
|
|
|
|
```json
|
|
{"$secret": "influx-token"}
|
|
```
|
|
|
|
Fluksio resolves it when building the node. Credential fields in the editor
|
|
offer a secret picker. Missing names produce an error on the affected node.
|
|
|
|
Secrets are encrypted with a key derived from `SECRET_KEY` and stored outside
|
|
the flow repository. Using references keeps credentials out of saved flows.
|
|
|
|
!!! warning "Keep your encryption key"
|
|
|
|
Changing `SECRET_KEY` makes existing secrets unreadable. Keep the old key
|
|
for re-encryption, or re-enter the secrets. Source installations include
|
|
`backend/scripts/rotate_secret_key.py` for rotating the secrets store.
|
|
|
|
## Modules
|
|
|
|
**Modules** shows the Python environment used by node code, its installed
|
|
packages and Python version. There are two setups:
|
|
|
|
- **Managed environment:** Docker uses a separate node environment. A
|
|
superuser edits **Requirements** and presses **Apply**. Packages are synced
|
|
with `uv pip sync`; deleting a requirement removes it. The manifest is
|
|
versioned with the flows, and successful installs refresh the workers.
|
|
- **Adopted environment:** a fresh pip installation inside your own virtual
|
|
environment can use that environment for nodes too. Modules is read-only.
|
|
Install dependencies there with pip or uv, then sync or restart Fluksio.
|
|
|
|
Set `NODE_VENV=managed` to request a separate environment. Installation
|
|
failures show the package manager's output on the page.
|
|
|
|
For an existing scientific environment on another machine, attach a worker
|
|
with `fluksio-worker --python /path/to/venv/bin/python`. See
|
|
[Remote workers](../code/workers.md).
|
|
|
|
## Alerts
|
|
|
|
Create a channel, choose events in a rule, and use **Test** to check delivery.
|
|
Enable alerts for the rules to send.
|
|
|
|
### Channels
|
|
|
|
| Kind | Destination |
|
|
|---|---|
|
|
| **ntfy** | server and topic; optional token |
|
|
| **SMTP** | recipient address, using the instance's mail settings |
|
|
| **Webhook** | URL that receives a POST |
|
|
| **Dashboard** | declared message read by a Notification widget |
|
|
| **webpush** | browsers subscribed from the Alerts page |
|
|
|
|
Channel settings may use `{"$secret": "name"}` references. Browser push also
|
|
needs notification permission and a secure browser context.
|
|
|
|
### Rules
|
|
|
|
A rule selects events and destination channels. Leaving all events unchecked
|
|
matches every supported alert event, including future additions.
|
|
|
|
| Event | Trigger |
|
|
|---|---|
|
|
| `node_error` | a node fails |
|
|
| `node_health` | a connection goes down |
|
|
| `flow_quarantined` | repeated crashes stop a flow's background work |
|
|
| `task_crashed` | a background task crashes |
|
|
| `engine_degraded` | engine health degrades |
|
|
| `cascade_dropped` | the engine drops work |
|
|
| `queue_unavailable` | the work queue becomes unreachable |
|
|
|
|
Repeated faults are deduplicated with a 15-minute default cooldown.
|
|
Flapping connections are suppressed, and the engine caps alert dispatches at
|
|
ten per hour. A quiet channel may be cooling down; **Test** helps distinguish
|
|
that from a broken configuration.
|
|
|
|
## Admin: users and clients
|
|
|
|
Superusers use **Admin** to add, edit and remove accounts, and manage OAuth
|
|
clients for [agents](../code/agents.md).
|
|
|
|
Accounts admitted from a portal are marked *Portal*. They sign in through the
|
|
portal, have no local password and are not superusers. To block local access,
|
|
edit the account and clear **Is active?**. See [Accounts and the portal](portal.md).
|
|
|
|
## Settings
|
|
|
|
Change your name, email, password and appearance under **Settings**.
|
|
|
|
**Remote access** manages enrollment and admitted users; see
|
|
[Accounts and the portal](portal.md).
|
|
|
|
A superuser can configure **Assistant**: choose a provider, store its key,
|
|
fetch models and select one. The encrypted key is shared for assistant access
|
|
on this instance. The chat appears after configuration; see
|
|
[The assistant](../code/agents.md#the-assistant).
|