One compose file per project: the agent maintains a single docker-compose.yml per project…

v0.0.1-alpha

First public version of the Pierrr Agent — the daemon you install on your server to drive it remotely from the Pierrr hub. Here is everything it can do.

#### Deployment

One compose file per project: the agent maintains a single docker-compose.yml per project under <AppsDir>/<orgSlug>/<projectSlug>/. The deploy-app command renders the project's stack and (re)starts only the targeted app's services (<appSlug> + its <appSlug>-nginx) — sibling apps in the same project are never restarted. stop, restart and delete-app likewise target that app's services in the compose file.
Image build + push: build-image builds the image from the repository and pushes it to the registry, with authentication supplied by the hub.
Granular stages: during build-image and deploy-app, the agent emits stage events (build → push → load → start, each running / succeeded / failed) for step-by-step tracking on the hub side.
Live logs: the output of the build and of docker compose up is streamed to the hub in real time (same stream as the attempt), instead of staying silent until the end.
Child-nginx config: written to <projectDir>/nginx/<appSlug>.conf (where the compose file mounts it); environment variables are inlined directly in the compose file (no separate .env).

#### Robustness / self-healing

Container name conflict: if a container already holds the target container_name (orphan, leftover from an old run), the agent removes it (docker rm -f) then replays the compose up instead of failing.
Nginx config auto-created as a directory: if Docker had created <projectDir>/nginx/<appSlug>.conf as a folder (bind source missing during an earlier run), the agent deletes it and writes a file — fixing the "not a directory" mount error.
Missing external networks: the agent creates the required external: true networks (e.g. reverse-proxy-<org>) before the compose up instead of failing.

#### Real-time health

Host metrics pushed every 5s without intervention: CPU, memory, disk — used and total.
Per-container metrics: CPU and memory of each container (via docker stats).
Streaming can be switched on and off remotely from the hub (set-health-streaming command); the state is persisted on the hub side and resynchronised on every connection.

#### Lifecycle & security

Identity: the agent derives its sha256(token) fingerprint; the hub only authorises enrolled fingerprints.
Remote update, GPG-verified: update command triggered by the client from the hub — the downloaded binary is verified (GPG signature) before the swap. The systemd unit grants ReadWritePaths=/usr/local/bin to allow the self-update.
Revoked agent: stays connected (the hub can still send it commands) but stops emitting (the hub cuts its streaming as soon as it connects) and is never marked online.
Giving up after repeated auth refusals: if the hub rejects the credentials 10 times in a row (HTTP 401/403 — unknown or revoked fingerprint), the agent goes offline instead of spamming the gateway. Transient network failures (hub unreachable) do not count: the agent keeps retrying, and a successful handshake resets the counter. To reactivate it: fix or re-enrol the token, then restart the agent.
Self-destruct: the self-destruct command (sent by the hub when the server is deleted) fully uninstalls the agent — binary, systemd unit, config, state and logs — through a detached process. Containers already deployed are left untouched.

#### Installation & operations

Installer: install.sh lays down the binary (/usr/local/bin/pierrr-agent), the systemd unit and the config, then enrols the agent with the hub.
On-disk layout: config in /etc/pierrr-agent/, state (apps, backups, last_ok_at) in /var/lib/pierrr-agent/, logs in /var/log/pierrr-agent/ (paths overridable by env).
Clean uninstall: pierrr-agent uninstall removes the unit, the folders (config/state/logs) and the binary — honouring the configured paths — without touching deployed containers.
Health probe: pierrr-agent healthz is green only if the agent has had a recent, successful WebSocket exchange with the hub (reflecting "connected", not merely "process up").

> Install / update: run install.sh on the server, or trigger the remote update from the hub ("Update" button) once the agent is enrolled.