The catalogue#

Thirty-eight entries: 36 container apps and two built-in feature modules. The tables below are generated from agent/catalog.json, not retyped, and every column is a field of the catalogue schema. The categories are in the order the catalogue declares them; within a category, entries sort case-insensitively by name.

Everything here is what the catalogue says, not what the agent tests. An entry is a recipe for a container the router runs: an image, a set of volumes, some environment, and a few things the web UI can honestly do with the result — link to it, probe whether it answers, and offer the configuration change that wires it into the router.

Check the version you are running:

curl -sk "$R/api/apps/catalog" -H "Authorization: Bearer $T" | python3 -m json.tool | head -20

How to read the tables#

Each category has two tables. The first says what an entry is; the second says what installing it does.

The entries#

DNS & filtering#

VPN & remote access#

Monitoring#

Security#

Network services#

Management#

The two built-in entries#

wireguard and suricata are kind: "builtin". They are not containers: they gate a native page in the web UI, and "installing" one stages nothing at all. The agent says so rather than pretending:

This is a built-in feature, not a container — installing it enables its page instantly
and stages nothing.

Each declares a config_path. If configuration exists under that path, the page stays visible whether or not the feature is enabled — a page must never be hidden while the configuration it edits is live on the router.

What is deliberately absent#

Installing one#

Three things have to be true before the router will commit a container: the image must be on the router, every volume source must exist, and the configuration must be valid. That is why installing is four calls rather than one.

# 1. What would be staged, and is the image here yet?
curl -sk -X POST "$R/api/apps/plan" -H "Authorization: Bearer $T" \
  -H 'Content-Type: application/json' \
  -d '{"app_id":"adguard","name":"adguard","address":"10.99.0.10"}'

# 2. Pull the image onto the router.
curl -sk -X POST "$R/api/apps/pull" -H "Authorization: Bearer $T" \
  -H 'Content-Type: application/json' -d '{"app_id":"adguard"}'

# 3. Create the volume sources.
curl -sk -X POST "$R/api/apps/prepare" -H "Authorization: Bearer $T" \
  -H 'Content-Type: application/json' \
  -d '{"app_id":"adguard","name":"adguard"}'

# 4. Stage the operations from step 1, then commit them in the Commit Bar.

Lifecycle is configuration too#

There is no control socket. Stopping an app stages set container name <n> disable; starting it deletes that node; restarting is a two-commit bounce, and if the second commit fails the app is left down and the API says so in those words.

See also#

• Catalogue schema — every field, in detail.
• Hint placeholders
• check-images.py — checking and pinning these images.
• Endpoint index — the ten /api/apps/* routes.
• Ports and listeners
• Apps are configuration
• Install an app

Checked against#

agent/catalog.json, agent/catalog.go (loadCatalog, planInstall, probeApp), agent/apps.go (handleAppPlan, handleAppPull, handleAppPrepare, handleAppRestart, handleAppFeature, collectInstalled), agent/catalog_test.go, scripts/check-images.py, docs/apps.md, PLAN.md §8.