# 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**. The list is resolved
  with `uv pip compile` and synced with `uv pip sync`, so each package brings
  its dependencies and 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 and rules belong to superusers,
whose Alerts page holds them. Any other account sees only the button that
subscribes its own browser to a **webpush** channel.

### 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 |
| `run_finished` | a batch run ends in error |

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).