@lamalibre/create-lamaste 4.2.0 → 4.3.1

package/vendor/docs/01-concepts/security-model.md

@@ -63,8 +63,18 @@ The admin panel requires a client certificate at the TLS layer. Without the cert
 
 **Agent-side TLS verification:** The agent verifies both servers it talks to. The panel uses a self-signed TLS server certificate that is separate from the mTLS CA used to sign client certificates, so `lamaste-agent setup` pins the panel's public key on first contact (trust on first use) and every later panel call rejects any other key; `lamaste-agent panel reset-pin` re-captures it after a deliberate rotation. The tunnel relay, `tunnel.<domain>`, has a publicly trusted Let's Encrypt certificate that the agent's Chisel client verifies normally (see 5a below).
 
+**Admin clients verify the panel too.** Whatever an admin client sends — the registry token, plugin settings, a TOTP code, a new user's password, storage keys, the 2FA session cookie — only ever reaches a server that proved it is the panel, and none of them falls back to skipping verification:
+
+- **`lamaste-server`** (root, on the relay) reaches the panel through nginx's IP vhost on loopback port 9292. That port is not privileged: whenever nginx does not hold it — panel 2FA switches the IP vhost off, nginx is stopped — any local user could listen there. So the CLI refuses before connecting when panel 2FA is on or the IP vhost is not enabled, and every request verifies the listener against the vhost's own certificate, read from disk as root (`/etc/lamalibre/lamaste/pki/self-signed.pem`; curl `--cacert` with the address the certificate names, connected to `127.0.0.1`; no `.curlrc`, no proxy). It offers TLS 1.2 forward-secret suites only, so an impostor — even one presenting the public certificate — fails the handshake before the CLI presents the admin client certificate, let alone a request. With panel 2FA on, the panel-backed commands (tunnels, sites, plugins, registry credential, push install, audit, chisel) are unavailable: use the panel in the browser, or turn 2FA off.
+- **The desktop app** verifies a panel reached at its domain (`https://panel.<domain>`) by its publicly trusted certificate. A panel reached at its IP address presents the self-signed certificate, so the app pins its public key per server, the same pin agents keep: read from the server over SSH when the app provisioned or recovered it, reported by the installer (or read from the certificate file) for a local install, otherwise taken from the first connection (trust on first use). The pin is stored with the server (`panelServerPubkeySha256` in `servers.json`) and shown on its card on the Servers page; only an explicit **Re-pin** there replaces it, after the app has shown the key the panel presents now. Every call — admin calls, health checks, the panel update, the hardware-bound upgrade — carries the pin (`--pinnedpubkey`); a different key aborts the connection before anything is sent. Agent calls use the pin the agent captured at enrollment.
+- **`create-lamaste-admin`** (the hardware-bound upgrade) installs the CA the panel answers with as trusted in the login keychain, so it verifies the panel the same way: the desktop passes the server's pin; run by hand against an IP address, it shows the key the panel presents before the operator confirms.
+
+`sudo lamaste-server panel-pin` prints the pin of the panel's IP certificate on the relay — compare it with what an agent (`lamaste-agent panel reset-pin`) or the desktop app shows to know they pinned the panel and not something in between.
+
 **P12 password security:** The agent never passes the P12 password as a command-line argument. Curl calls use a temporary config file (created with mode `0600`, deleted after use), and openssl calls use the `LAMALIBRE_LAMASTE_P12_PASS` environment variable. This prevents the password from being visible in process listings (`ps aux`).
 
+**Request bodies and session cookies:** A request body that carries a credential — the enrollment token, the registry token, a TOTP code, a user's password, storage keys — is never a curl argument either. `lamaste-agent setup` (enrollment), `lamaste-server` and the desktop app hand curl the body on stdin (`--data-binary @-`). `lamaste-server` runs as root, so its config file for the P12 password is created exclusively (`O_EXCL`, `0600`) in a private `mkdtemp` directory (`0700`) that is removed on every path. The desktop app keeps the panel's 2FA session cookie in its private `0600` config file next to the certificate password, and sends its calls to the local agent daemon with the Bearer token and the body in one curl config on stdin (`-K -`).
+
 **Hardware-bound certificates:** Agents can enroll using a one-time token and a locally generated CSR, binding the private key to the macOS Keychain so it is non-extractable. The public `POST /api/enroll` endpoint uses the token as its sole authentication gate — no mTLS is required for enrollment itself, since the agent does not yet have a certificate. After enrollment, the agent authenticates with the Keychain-backed identity just like any other mTLS client. Admins can optionally upgrade their own authentication to hardware-bound mode (set `adminAuthMode` to `"hardware-bound"` in `panel.json`), which disables P12 download and certificate rotation through the panel UI. If the admin Keychain identity is lost, recovery is possible by running `lamaste-reset-admin` on the server, which reverts to standard P12 authentication.
 
 Lamaste supports three types of certificates with different access levels:
@@ -131,6 +141,48 @@ mTLS is stronger than a login page because:
 - There is no login endpoint to discover or attack
 - The rejection happens before any application code runs
 
+#### 5c. The agent daemon (`lamaste-agentd`) and relay assertions
+
+The agent daemon listens on `127.0.0.1:<port>` (9393 by default) of the agent machine. It is reached by the agent's owner directly and by the relay through two kinds of tunnel, and admits:
+
+| Caller                                                   | Proof                                                                    | Access                                                                      |
+| -------------------------------------------------------- | ------------------------------------------------------------------------ | --------------------------------------------------------------------------- |
+| The agent's owning OS user (desktop app, scripts)        | `Authorization: Bearer <token>` from `~/.lamalibre/lamaste/agentd.token` | Full                                                                        |
+| The admin certificate, on `agent-<label>.<domain>`       | A relay assertion signed by the panel                                    | Full                                                                        |
+| The agent's own certificate, on `agent-<label>.<domain>` | A relay assertion signed by the panel                                    | The capabilities the panel lists for it; owner-only routes refused          |
+| An Authelia user, on a plugin tunnel (`type: 'plugin'`)  | A relay assertion signed by Gatekeeper                                   | That plugin's routes, never `/api/*`; the plugin sees the asserted identity |
+
+**Threat model.** Binding to loopback is not an authentication boundary. Two kinds of process can open a connection to the daemon without going through nginx: any OS user on the agent machine (`127.0.0.1:<port>`), and any process on the relay (the tunnel's port on the relay's loopback, which Chisel carries to the agent). Up to 4.2 the daemon took its caller from request headers that nginx sets — `X-SSL-Client-Verify: SUCCESS` with `X-SSL-Client-DN: CN=admin` meant full control, plugin install included (code execution as the agent's user), and `Remote-User` meant any Authelia identity on plugin routes — so either kind of process could claim to be anyone. Its check of whether a request needs a caller also tested the raw URL, while the router decodes percent-escapes: `/%61pi/...` reached `/api/...` routes and `/%68erd/...` a plugin's routes with no credential at all.
+
+**Relay assertions.** From 4.3 the relay vouches for each request it sends with `X-Lamalibre-Relay-Assertion` — an Ed25519 signature over the agent the request is for (`aud`), the tunnel port, the caller, the method, the target (the exact `$request_uri` for a certificate caller; the plugin route for an Authelia user, whose request nginx rewrites), the issue time, a nonce and the key id. The daemon verifies it against the relay's public key and refuses it for another agent or port, for another method or target, older than 60 seconds (5 seconds of clock skew), or seen before. The signing key, `/etc/lamalibre/lamaste/relay-signing-key.json` (0600, `lamaste`), is created by the panel at startup:
+
+- **Agent-panel vhost:** nginx asks the panel about every request (`auth_request` to `GET /api/agent-panel/authz/<label>`, with the client certificate's verification result, the method and `$request_uri`). The panel's mTLS middleware refuses a revoked certificate — before, the agent panel could not check revocation at all — and the panel admits the admin certificate and the agent's own, then signs.
+- **Plugin tunnels:** Gatekeeper, which already validates the Authelia session for them, signs for the user it found; the answer is never cached (an assertion is single use).
+
+Agents hold only the public key. The daemon fetches it, with the label the relay knows the agent by (the audience of its assertions, which a local `--label` need not equal), from `GET /api/agents/me/relay-keys` over its pinned mTLS channel, keeps both in memory and fetches again when an assertion names an unknown key — at most once per 30 seconds. Nothing stored on an agent machine lets anyone mint an assertion, for that agent or another.
+
+The owner's token is as good as the owner: the desktop app hands it to curl on stdin, never in a process's arguments, which other local users can read.
+
+Headers that only claim a caller — `X-SSL-Client-*`, `Remote-*` and the assertion itself — are removed from every request before a route or plugin sees it; `Remote-*` are set again only from a verified user assertion, so a plugin reading identity headers (`@lamalibre/lamaste-identity@4.3.1`) reads the relay's word. Whether a request needs a caller follows the route the daemon matched, not the URL: every route does except the health check, the plugin bundles and the SPA's static files, and so does a path no route matches under an installed plugin's name (a plugin may answer it with its own not-found handler). The claim headers are removed from `rawHeaders` too.
+
+**What remains.** The relay's loopback is still the relay's trust boundary: the panel itself trusts the `X-SSL-Client-*` headers nginx sends to `127.0.0.1:3100`, so a process on the relay that can forge those can obtain an assertion as well — what it could do to agents before 4.3. With panel 2FA on it reaches further into agents than into the panel: forged (or stolen) admin-certificate headers no longer pass the panel's own management routes, but the agent-panel authorization is exempt from 2FA (the browser on `agent-<label>.<domain>` carries no 2FA cookie), so they still mint admin assertions — full control of every agent with a panel tunnel. Agent panels are guarded by the client certificate alone, as before; authenticating nginx to the panel is the relay-wide fix. An assertion binds the agent, the port, the method and the target, not the request body: a process on the agent machine that holds the daemon's port while the daemon is down receives the relay's requests, and could replay one with another body if the daemon comes back within the assertion's 65 seconds.
+
+#### 5d. The app host on agents
+
+An agent half Lamaste installs runs on its agent as a service of its own, so something on the agent has to act as root: create an account and a unit, write under `/opt`, `/var/lib` and `/etc`, install system packages. That is `lamaste-apphost`, enabled once per machine by the agent's operator (`sudo lamaste-agent apphost enable`). See [App Host](../04-api-reference/app-host.md) for the helper, its files and the unit.
+
+**What the sudoers rule grants.** The agent's user may run one root-owned program, `/usr/local/sbin/lamaste-apphost`, with any arguments, a reset environment and Node.js's code-loading variables deleted. The program validates every argument, derives every path from the route and the agent label, takes content on stdin, reads nothing the agent's user can write, and does five things: install a version, write a plugin config, switch the current version, remove, report status. It never runs plugin code: the agent half runs as its own account (`lamaste-app-<route>`) under a hardened unit — no capabilities, `NoNewPrivileges`, the file system read-only but its data directory, its code root-owned 0644. `enable` installs the program only from a root-owned `lamaste-agent` install, so root never runs or copies code another user could have changed.
+
+**Why jobs are relay-signed.** Without a signature, the agent's user — or whoever takes its account — could have the helper install any package it can produce with any system packages, activate any kept version, or purge data, as root. Approval of what an agent half brings happens on the relay, so the relay signs every `app-install`, `app-activate` and `app-remove` with its Ed25519 relay key when it creates the job, over the agent's label, the route, the job id, the kind, the payload (the exact package, version, tarball integrity, service and system packages; the version and package to activate; the purge flag and package) and a deadline of at most an hour. The helper verifies it with the key pinned for that agent, compares the payload with what it is asked, and runs each job id once. The agent's sync carries the signature from `agent-config` to the helper; it can neither make nor change one.
+
+**The pin is trust on first use.** `enable` and `pin` fetch the relay's key as the agent's user, over that agent's pinned mTLS channel, and root checks the label and the key's shape: a label of that user's agents — from the user's agent registry, which root reads itself as a file that user owns, and never a label root's own agents use when the user is another, since a pin is per label for the whole machine — and an Ed25519 key whose id is derived from it. An agent account that is already compromised at that moment could hand root its own key for its own labels. Compare the pinned id with the relay's once: on the relay the panel logs it at start-up (`Relay assertion signing key ready`, `kid`) and `GET /api/agents/me/relay-keys` with the admin certificate returns it; on the agent `sudo lamaste-agent apphost status` lists each label's pin. The panel shows the first 12 hex digits each agent reports pinned and does not let an agent whose pin is not the relay's key host an agent half. A pin is a root-owned file in root-owned directories; the helper refuses one anyone else could have written or linked. After the relay's key is replaced, the helper refuses its jobs until `sudo lamaste-agent apphost pin` runs.
+
+**Owner records.** A route belongs to the agent label and the agent package that first installed it — a root-owned record outside the agent half's data. Another label, or another package, is refused that route and the data kept with it until the owner purges it; the account an agent half runs as names its route, and an account that does not is never reused, given files or deleted. A relay can therefore neither take over another relay's agent half on a shared machine nor hand one package's data to another.
+
+**Several agents on one machine.** Agents of different relays may share a machine and its helper. The rule names one OS user, so they run as that user (or root) — `enable` for another user is refused unless `--force`, since the first user's agents could no longer manage their agent halves; each label has its own pin, and a relay's signature names its own label for the agent, so a job signed for one agent is not run as another's.
+
+**What a compromised agent account can still do:** read and rewrite the plugin configs it already holds (`config` is not signed) — breaking the admin API of that agent half; run `status`; run a signed job it received when it likes before the job expires, or not at all; report results that are not true (the relay's view of what runs on the agent is the agent's report); stop its tunnel and its sync. **What it cannot:** run anything as root beyond those fixed operations; install, switch or remove anything the relay did not sign, or anything other than exactly what it signed; replay a job; pin a key (root only); read or write an agent half's data directory (0700, another account); act on a route another label or package owns. **A compromised relay** can do on its agents what its signature allows: install any `@lamalibre/` package from its registry at any version, with system packages from the agent's configured apt sources, running as a service account — never plugin code as root — and remove or purge the agent halves it owns.
+
 #### 6. TOTP 2FA for app access
 
 Visitors to your tunneled apps authenticate through Authelia with a password and a TOTP code from their phone. See [Authentication](authentication.md) for full details.
@@ -144,7 +196,7 @@ Key details:
 - **Session cookie:** `lamaste_2fa_session`, HMAC-SHA256 signed, with 12-hour absolute expiry and 2-hour inactivity timeout. Cookie flags: `HttpOnly`, `Secure`, `SameSite=Strict`
 - **Rate limiting:** 5 failed attempts within 2 minutes trigger a 5-minute ban
 - **TOTP standard:** RFC 6238, SHA-1, 30-second period, +/-1 step clock drift, replay protection
-- **IP vhost disabled:** When panel 2FA is enabled, the IP-based vhost (`https://<IP>:9292`) is disabled and access is domain-only. This is necessary because session cookies require a domain scope.
+- **IP vhost disabled:** When panel 2FA is enabled, the IP-based vhost (`https://<IP>:9292`) is disabled and access is domain-only. This is necessary because session cookies require a domain scope. `lamaste-server`'s panel commands, which use that vhost on loopback and hold no 2FA session, refuse to run while 2FA is on (see "Admin clients verify the panel too" above)
 - **Recovery:** `sudo lamaste-reset-admin` clears 2FA settings and re-enables the IP vhost
 
 See [Authentication](authentication.md) for setup details.
@@ -420,6 +472,10 @@ Sensitive files use restrictive permissions:
 | `~/.lamalibre/lamaste/agents/<label>/chisel.json`, `chisel.env`     | `600` | Agent's Chisel credential (agent machine)         |
 | `~/Library/LaunchAgents/com.lamalibre.lamaste.chisel-<label>.plist` | `600` | Carries `AUTH` in its environment (macOS agent)   |
 | `/etc/lamalibre/lamaste/pki/`                                       | `700` | PKI directory itself                              |
+| `/etc/sudoers.d/lamaste-apphost`                                    | `440` | The app host rule (agent machine)                 |
+| `/etc/lamalibre/apps/<route>/plugin-config.json`                    | `600` | An agent half's port and secret; its account      |
+| `/var/lib/lamalibre/apps/<route>/`                                  | `700` | An agent half's data; its account                 |
+| `/var/lib/lamalibre/apps/.jobs/`, `.trash/`                         | `700` | Signed jobs that ran; purged data (root)          |
 
 Mode `600` means only the file owner can read or write. Mode `640` adds read access for the file's group, `660` also write access. Mode `700` means only the directory owner can list, read, or modify contents. See [Configuration Files](../06-reference/config-files.md#file-permissions-table) for the owner of every directory.
 
@@ -441,15 +497,21 @@ There is no rule for `mv`, `cp`, `rm`, `chmod`, `chown`, `mkdir`, `cat`, `find`,
 - **Binaries, units, accounts.** Chisel and Authelia (pinned, digest-verified releases), their systemd units and the service accounts are installed by `create-lamaste`, which runs as root. The panel never writes a unit or a binary; onboarding only checks they exist.
 - **Code.** `/opt/lamalibre/lamaste` (panel, gatekeeper, `lamaste-server` CLI, UI, docs) is root-owned and read-only for `lamaste`, so a compromised panel cannot rewrite code that root later runs through `sudo lamaste-server`.
 
+#### Plugin code on the relay: the hook runner
+
+Server plugins run inside the panel (the `@lamalibre/` scope is their trust boundary). Agent-hosted plugins never do: the panel does not import them. Their **relay hooks** — code an administrator approves by digest — run in `lamalibre-lamaste-hooks@<route>.service`: a systemd dynamic user, a read-only file system without Lamaste's state, Authelia, certificates, nginx or SSH configuration, its own network namespace with Unix sockets only, no capabilities, Node's permission model allowing reads of the runner and the approved module only, an empty environment, and its output discarded. The panel calls it over a socket only the `lamaste` group can open; a hook can affect nothing but its answer and the rate-limited effects Lamaste performs for it. See [Lifecycle Hooks](../04-api-reference/lifecycle-hooks.md#the-hook-runner).
+
 #### `lamaste-priv`
 
 `/usr/local/sbin/lamaste-priv` is a root-owned (`0755`), zero-dependency Node.js program installed by `create-lamaste`. Content (vhost text, TOTP secrets) arrives on stdin, never on the command line, so it is not written to the sudo log. It reads nothing the `lamaste` user can write.
 
-| Operation                                                                           | Does                                                                                                                           |
-| ----------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ |
-| `nginx-site write\|backup\|restore\|discard-backup\|enable\|disable\|remove <name>` | Manage `sites-available/<name>` (and its `.bak`) and its `sites-enabled` link. `write` validates the vhost on stdin first.     |
-| `authelia-totp <username>`                                                          | Store the TOTP secret from stdin with Authelia's CLI, run as `lamaste-authelia` (the database is that account's file)          |
-| `self-update <version>`                                                             | Start `npx @lamalibre/create-lamaste@<version> --yes` in a transient systemd unit two seconds later (`MAJOR.MINOR.PATCH` only) |
+| Operation                                                                           | Does                                                                                                                                                            |
+| ----------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `nginx-site write\|backup\|restore\|discard-backup\|enable\|disable\|remove <name>` | Manage `sites-available/<name>` (and its `.bak`) and its `sites-enabled` link. `write` validates the vhost on stdin first.                                      |
+| `authelia-totp <username>`                                                          | Store the TOTP secret from stdin with Authelia's CLI, run as `lamaste-authelia` (the database is that account's file)                                           |
+| `self-update <version>`                                                             | Start `npx @lamalibre/create-lamaste@<version> --yes` in a transient systemd unit two seconds later (`MAJOR.MINOR.PATCH` only)                                  |
+| `hooks install <route> <sha256\|none>`                                              | Write a plugin's approved relay hook module (stdin, checked against the digest) root-owned to `/opt/lamalibre/lamaste/hooks/<route>/`, enable its runner socket |
+| `hooks activate\|restart\|remove <route> [sha256]`                                  | Point the runner back at the kept previous module; stop a stuck runner; disable it and delete its modules                                                       |
 
 Site names are limited to the panel's own vhosts: `lamalibre-lamaste-panel-domain`, `-auth`, `-tunnel`, `-app-<subdomain>`, `-agent-panel-<label>` and `-site-<uuid>`. `lamalibre-lamaste-panel-ip` (written by `create-lamaste`) may only be enabled or disabled.
 
@@ -509,40 +571,53 @@ Configuration files that are read live by services (like Authelia's `users.yml`)
 
 ### Source files
 
-| File                                                       | Purpose                                                |
-| ---------------------------------------------------------- | ------------------------------------------------------ |
-| `packages/create-lamaste/src/tasks/harden.js`              | Swap, UFW, fail2ban, SSH hardening                     |
-| `packages/create-lamaste/src/tasks/mtls.js`                | PKI generation, file permissions                       |
-| `packages/create-lamaste/src/tasks/nginx.js`               | mTLS snippet, self-signed cert                         |
-| `packages/lamaste-serverd/src/lib/authelia.js`             | bcrypt hashing, atomic writes                          |
-| `packages/lamaste-serverd/src/lib/mtls.js`                 | Certificate rotation with rollback                     |
-| `packages/lamaste-serverd/src/lib/nginx.js`                | Vhost write-with-rollback pattern                      |
-| `packages/lamaste-serverd/src/middleware/mtls.js`          | Request-level mTLS check                               |
-| `packages/lamaste-serverd/src/lib/totp.js`                 | Panel 2FA TOTP verification and replay protection      |
-| `packages/lamaste-serverd/src/lib/session.js`              | HMAC-SHA256 session cookie signing                     |
-| `packages/lamaste-serverd/src/middleware/twofa-session.js` | 2FA session enforcement (after mTLS, before roleGuard) |
+| File                                                                | Purpose                                                |
+| ------------------------------------------------------------------- | ------------------------------------------------------ |
+| `packages/create-lamaste/src/tasks/harden.js`                       | Swap, UFW, fail2ban, SSH hardening                     |
+| `packages/create-lamaste/src/tasks/mtls.js`                         | PKI generation, file permissions                       |
+| `packages/create-lamaste/src/tasks/nginx.js`                        | mTLS snippet, self-signed cert                         |
+| `packages/lamaste-serverd/src/lib/authelia.js`                      | bcrypt hashing, atomic writes                          |
+| `packages/lamaste-serverd/src/lib/mtls.js`                          | Certificate rotation with rollback                     |
+| `packages/lamaste-serverd/src/lib/nginx.js`                         | Vhost write-with-rollback pattern                      |
+| `packages/lamaste-serverd/src/middleware/mtls.js`                   | Request-level mTLS check                               |
+| `packages/lamaste-serverd/src/lib/totp.js`                          | Panel 2FA TOTP verification and replay protection      |
+| `packages/lamaste-serverd/src/lib/session.js`                       | HMAC-SHA256 session cookie signing                     |
+| `packages/lamaste-serverd/src/middleware/twofa-session.js`          | 2FA session enforcement (after mTLS, before roleGuard) |
+| `packages/core/lib/src/relay-assertion.ts`                          | Relay assertions: signing key file, sign, verify       |
+| `packages/core/lib/src/server/agent-panel-authz.ts`                 | Who may use an agent panel through the relay           |
+| `packages/server/daemon/src/routes/management/agent-panel-authz.js` | The agent-panel vhost's `auth_request` target          |
+| `packages/sdks/gatekeeper/src/server/routes/authz.ts`               | Assertions for Authelia users on plugin tunnels        |
+| `packages/agent/daemon/src/lib/auth.js`                             | lamaste-agentd's authentication hook                   |
+| `packages/core/lib/src/app-job-signature.ts`                        | Relay-signed app jobs: envelope, sign, verify          |
+| `packages/agent/cli/scripts/lamaste-apphost`                        | The app host helper (root, Node.js built-ins only)     |
+| `packages/agent/cli/src/lib/apphost-setup.js`                       | Root-owned install check, sudoers rule, relay key pins |
+| `packages/server/daemon/src/lib/agent-jobs.js`                      | Agent jobs; app jobs signed when created               |
 
 ## Quick Reference
 
 ### Security layers
 
-| Layer                | Technology                           | Blocks                                |
-| -------------------- | ------------------------------------ | ------------------------------------- |
-| Firewall             | UFW                                  | Connections to non-allowed ports      |
-| Intrusion prevention | fail2ban                             | Repeated failed login attempts        |
-| SSH hardening        | sshd_config                          | Password-based SSH access             |
-| TLS encryption       | Let's Encrypt / self-signed          | Traffic interception and tampering    |
-| Admin auth           | mTLS client certificates             | Unauthorized admin access             |
-| Admin 2FA (optional) | Built-in TOTP                        | Stolen certificate abuse              |
-| Agent-to-agent auth  | Tickets (time-limited, single-use)   | Unauthorized cross-agent access       |
-| Tunnel ownership     | Chisel authfile per-agent grants     | One agent hijacking another's host    |
-| Reserved ports       | Tunnel port validation               | Publishing internal services          |
-| Privileged commands  | No-wildcard sudoers, `lamaste-priv`  | Root code execution via extra flags   |
-| Relay authenticity   | Agent verifies `tunnel.<domain>` TLS | Relay impersonation, credential theft |
-| App auth             | Authelia TOTP 2FA                    | Unauthorized app access               |
-| Service isolation    | `127.0.0.1` binding                  | Direct access to internal services    |
-| File permissions     | `chmod 600`                          | Unauthorized secret access            |
-| Atomic writes        | `mv` pattern                         | Partial file reads by services        |
+| Layer                | Technology                              | Blocks                                |
+| -------------------- | --------------------------------------- | ------------------------------------- |
+| Firewall             | UFW                                     | Connections to non-allowed ports      |
+| Intrusion prevention | fail2ban                                | Repeated failed login attempts        |
+| SSH hardening        | sshd_config                             | Password-based SSH access             |
+| TLS encryption       | Let's Encrypt / self-signed             | Traffic interception and tampering    |
+| Admin auth           | mTLS client certificates                | Unauthorized admin access             |
+| Admin 2FA (optional) | Built-in TOTP                           | Stolen certificate abuse              |
+| Agent-to-agent auth  | Tickets (time-limited, single-use)      | Unauthorized cross-agent access       |
+| Tunnel ownership     | Chisel authfile per-agent grants        | One agent hijacking another's host    |
+| Reserved ports       | Tunnel port validation                  | Publishing internal services          |
+| Privileged commands  | No-wildcard sudoers, `lamaste-priv`     | Root code execution via extra flags   |
+| Relay authenticity   | Agent verifies `tunnel.<domain>` TLS    | Relay impersonation, credential theft |
+| Panel authenticity   | Pinned panel key, CA for its domain     | Panel impersonation, credential theft |
+| Agent daemon auth    | Relay assertions (Ed25519), owner token | Callers forged on an agent's loopback |
+| Agent root helper    | Relay-signed app jobs, pinned key       | Root actions the relay did not sign   |
+| Agent half sandbox   | Own account, hardened systemd unit      | Plugin code as root                   |
+| App auth             | Authelia TOTP 2FA                       | Unauthorized app access               |
+| Service isolation    | `127.0.0.1` binding                     | Direct access to internal services    |
+| File permissions     | `chmod 600`                             | Unauthorized secret access            |
+| Atomic writes        | `mv` pattern                            | Partial file reads by services        |
 
 ### Firewall rules
 

package/vendor/docs/01-concepts/tickets.md

@@ -264,9 +264,9 @@ The integration flow:
 }
 ```
 
-### Client SDK (`@lamalibre/lamaste-tickets@4.2.0`)
+### Client SDK (`@lamalibre/lamaste-tickets@4.3.1`)
 
-The `@lamalibre/lamaste-tickets@4.2.0` package is a TypeScript SDK that provides the client-side ticket lifecycle for plugins and agents. It uses `undici` for HTTP with mTLS dispatcher support and has no other runtime dependencies.
+The `@lamalibre/lamaste-tickets@4.3.1` package is a TypeScript SDK that provides the client-side ticket lifecycle for plugins and agents. It uses `undici` for HTTP with mTLS dispatcher support and has no other runtime dependencies.
 
 The SDK exports three main classes:
 

package/vendor/docs/01-concepts/tunneling.md

@@ -144,7 +144,7 @@ On the API side the same rule holds: `GET /api/tunnels/agent-config` returns onl
 
 ### Client configuration
 
-The Chisel client runs as a user-level service managed by `lamaste-agent` (and `lamaste-agentd`): a LaunchAgent plist on macOS, a systemd **user** unit on Linux. Both are generated by one implementation in `@lamalibre/lamaste@4.2.0/agent`. The client command looks like:
+The Chisel client runs as a user-level service managed by `lamaste-agent` (and `lamaste-agentd`): a LaunchAgent plist on macOS, a systemd **user** unit on Linux. Both are generated by one implementation in `@lamalibre/lamaste@4.3.1/agent`. The client command looks like:
 
 ```bash
 chisel client \
@@ -208,7 +208,7 @@ location / {
 
 ### Concurrency and locking
 
-Every tunnel workflow — create, delete, toggle, assign, reconfigure, the combined `PATCH`, releasing a revoked agent's tunnels, and startup reconciliation — runs under one tunnel lock (`withTunnelLock` in `@lamalibre/lamaste@4.2.0/server`'s `tunnels.ts`), with its validation inside the lock. Two concurrent requests therefore cannot both pass a uniqueness check for the same subdomain or port. Authfile renders are additionally serialized with a keyed promise-chain mutex in `chisel-users.ts`, so enrollments and credential rotations never interleave authfile writes with tunnel changes.
+Every tunnel workflow — create, delete, toggle, assign, reconfigure, the combined `PATCH`, releasing a revoked agent's tunnels, and startup reconciliation — runs under one tunnel lock (`withTunnelLock` in `@lamalibre/lamaste@4.3.1/server`'s `tunnels.ts`), with its validation inside the lock. Two concurrent requests therefore cannot both pass a uniqueness check for the same subdomain or port. Authfile renders are additionally serialized with a keyed promise-chain mutex in `chisel-users.ts`, so enrollments and credential rotations never interleave authfile writes with tunnel changes.
 
 ### Startup reconciliation
 
@@ -223,7 +223,7 @@ It **fails closed**: if the authfile cannot be established, Chisel is stopped **
 
 ### Installation
 
-On the server, Chisel is installed by `npx @lamalibre/create-lamaste@4.2.0` — as root, together with its hardened systemd unit (`User=nobody`, `Group=lamaste-chisel`, `NoNewPrivileges`, `ProtectSystem=strict`, empty `CapabilityBoundingSet`) — and kept at the pinned release by every redeploy. The panel never installs a binary or writes the unit; onboarding only checks the binary exists, creates the server key and authfile, and starts the service. Both the server installer and the agents download the pinned release (`CHISEL_RELEASE` in `@lamalibre/lamaste@4.2.0`'s `constants.ts`) from its fixed URL, with no GitHub API lookup and no "latest":
+On the server, Chisel is installed by `npx @lamalibre/create-lamaste@4.3.1` — as root, together with its hardened systemd unit (`User=nobody`, `Group=lamaste-chisel`, `NoNewPrivileges`, `ProtectSystem=strict`, empty `CapabilityBoundingSet`) — and kept at the pinned release by every redeploy. The panel never installs a binary or writes the unit; onboarding only checks the binary exists, creates the server key and authfile, and starts the service. Both the server installer and the agents download the pinned release (`CHISEL_RELEASE` in `@lamalibre/lamaste@4.3.1`'s `constants.ts`) from its fixed URL, with no GitHub API lookup and no "latest":
 
 ```
 https://github.com/jpillora/chisel/releases/download/v1.12.0/chisel_1.12.0_<os>_<arch>.gz
@@ -320,7 +320,7 @@ sudo systemctl restart chisel
 
 ```bash
 # Install globally, then set up the agent (interactive)
-npm install -g @lamalibre/lamaste-agent@4.2.0
+npm install -g @lamalibre/lamaste-agent@4.3.1
 lamaste-agent setup --label <label>
 
 # Apply tunnel changes now (the sync timer does it within 30 s anyway)

package/vendor/docs/02-guides/agent-setup.md

@@ -59,7 +59,7 @@ The token is single-use and expires after 10 minutes. `tunnels:read` is enough f
 Install the agent **globally** first:
 
 ```bash
-npm install -g @lamalibre/lamaste-agent@4.2.0
+npm install -g @lamalibre/lamaste-agent@4.3.1
 ```
 
 A global install is required, not a convenience. Setup installs a sync timer (see [How tunnel changes reach the agent](#how-tunnel-changes-reach-the-agent)) that runs the installed `lamaste-agent` every 30 seconds for as long as the agent exists. An `npx` copy lives in npm's cache, which npm may clear at any time — the timer would silently stop. `setup` and `update` therefore refuse to run from `npx`, and they check this **before** an enrollment token is spent. For an installation npm does not manage, set `LAMALIBRE_LAMASTE_AGENT_CLI_PATH` to the absolute path of the `lamaste-agent` script the timer should run.
@@ -117,7 +117,7 @@ The relay only lets an agent open the ports of the enabled tunnels it carries, a
 4. The service definition lists exactly the tunnels the relay grants this agent.
 5. The client runs when there is something to carry, and is stopped when the agent carries no tunnel or the operator stopped it.
 
-When everything already matches, a run costs one panel request and changes nothing. The timer runs it:
+When everything already matches, a run costs one panel request and changes nothing. After converging, a run also reports the agent's host facts when they changed and runs the jobs the relay listed for the plugins this agent hosts — lifecycle hook calls, and installing, switching or removing an agent half ([App Host](../04-api-reference/app-host.md)); an install may take up to 10 minutes, so systemd allows a run 20 (`TimeoutStartSec=20min`). The timer runs it:
 
 | Platform | Units                                                                                        | Schedule                                                      |
 | -------- | -------------------------------------------------------------------------------------------- | ------------------------------------------------------------- |
@@ -148,7 +148,7 @@ Each agent authenticates to the relay with its own chisel credential, stored in
 Upgrade agents **before** the server. Agents from before this version reject the new shape of the relay's Chisel arguments; a current agent works against an older server, keeping its credential until the server offers rotation.
 
 ```bash
-npm install -g @lamalibre/lamaste-agent@4.2.0
+npm install -g @lamalibre/lamaste-agent@4.3.1
 lamaste-agent update
 ```
 
@@ -167,21 +167,39 @@ lamaste-agent switch <label>         # change the default agent
 lamaste-agent uninstall --label <l>  # stop and remove one agent, including its sync timer
 ```
 
+## Hosting app plugins (Linux)
+
+To let the panel install the agent halves of app plugins on this machine — their accounts, units and directories — enable the app host helper once, from a root-owned install:
+
+```bash
+sudo npm install -g @lamalibre/lamaste-agent@4.3.1
+sudo lamaste-agent apphost enable              # the agent runs as the user who ran sudo
+lamaste-agent apphost status                   # helper, pinned relay keys, installed agent halves
+sudo lamaste-agent apphost pin                 # after the relay rotated its signing key
+```
+
+The agent reports it on its next sync, and the panel can then host plugins whose agent half Lamaste installs here, while this agent's push-install window is open. `lamaste-agent uninstall` refuses while agent halves are installed for the agents it would remove. See [App Host](../04-api-reference/app-host.md).
+
 ## Troubleshooting
 
-| Symptom                                                     | Cause and fix                                                                                                                                                                                                                   |
-| ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `setup` says the agent must be installed globally           | It was run through `npx`. Run `npm install -g @lamalibre/lamaste-agent@4.2.0`, then `lamaste-agent setup ...` again. The enrollment token was not spent.                                                                              |
-| Log shows a TLS / x509 error                                | `tunnel.<domain>` does not present a valid certificate for its name. Check the relay's certificate (`Certificates` page) and that the agent's clock is correct.                                                                 |
-| Log shows authentication failed                             | The credential was rotated on the panel. The next sync picks it up; `lamaste-agent chisel refresh-credential` applies it now.                                                                                                   |
-| Log shows `access denied` for a remote                      | The relay no longer grants this agent that port: the tunnel was disabled, deleted, or moved to another agent. The next sync drops it. If it persists, check `lamaste-agent status` — the sync timer may not be running.         |
-| `status` shows `Sync: not installed`                        | The agent was set up before the timer existed. Install globally, then run `lamaste-agent update`.                                                                                                                               |
-| `status` shows `Sync: last ran ... not running its program` | The timer's last run is over 2 minutes old: the timer was unloaded, or the program it runs is gone (Node.js or the agent was moved or uninstalled). Run `lamaste-agent update` from the global install to rewrite it.           |
-| `status` shows `Sync: failing since ...`                    | The error is the last sync's. `The panel reports domain X, but this agent is enrolled with Y` means the panel moved to another domain: re-enroll the agent. Otherwise check the panel is reachable. Details in `logs/sync.log`. |
-| Tunnels do not start although the agent carries some        | The tunnels were stopped from the agent panel or desktop app, and the timer respects that. Start them there.                                                                                                                    |
-| Tunnel works until reboot                                   | Lingering is off. See step 3.                                                                                                                                                                                                   |
-| New tunnel returns 502                                      | The agent has not synced yet (up to ~30 s), or nothing listens on `127.0.0.1:<port>` on the agent. Run `lamaste-agent update` to apply at once.                                                                                 |
-| Upload fails with 413                                       | The request is larger than the tunnel's body limit. Raise **Largest request body** on the tunnel (`maxBodySizeMb`).                                                                                                             |
+| Symptom                                                     | Cause and fix                                                                                                                                                                                                                       |
+| ----------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `setup` says the agent must be installed globally           | It was run through `npx`. Run `npm install -g @lamalibre/lamaste-agent@4.3.1`, then `lamaste-agent setup ...` again. The enrollment token was not spent.                                                                                  |
+| Log shows a TLS / x509 error                                | `tunnel.<domain>` does not present a valid certificate for its name. Check the relay's certificate (`Certificates` page) and that the agent's clock is correct.                                                                     |
+| Log shows authentication failed                             | The credential was rotated on the panel. The next sync picks it up; `lamaste-agent chisel refresh-credential` applies it now.                                                                                                       |
+| Log shows `access denied` for a remote                      | The relay no longer grants this agent that port: the tunnel was disabled, deleted, or moved to another agent. The next sync drops it. If it persists, check `lamaste-agent status` — the sync timer may not be running.             |
+| `status` shows `Sync: not installed`                        | The agent was set up before the timer existed. Install globally, then run `lamaste-agent update`.                                                                                                                                   |
+| `status` shows `Sync: last ran ... not running its program` | The timer's last run is over 2 minutes old: the timer was unloaded, or the program it runs is gone (Node.js or the agent was moved or uninstalled). Run `lamaste-agent update` from the global install to rewrite it.               |
+| `status` shows `Sync: failing since ...`                    | The error is the last sync's. `The panel reports domain X, but this agent is enrolled with Y` means the panel moved to another domain: re-enroll the agent. Otherwise check the panel is reachable. Details in `logs/sync.log`.     |
+| Tunnels do not start although the agent carries some        | The tunnels were stopped from the agent panel or desktop app, and the timer respects that. Start them there.                                                                                                                        |
+| Tunnel works until reboot                                   | Lingering is off. See step 3.                                                                                                                                                                                                       |
+| New tunnel returns 502                                      | The agent has not synced yet (up to ~30 s), or nothing listens on `127.0.0.1:<port>` on the agent. Run `lamaste-agent update` to apply at once.                                                                                     |
+| Upload fails with 413                                       | The request is larger than the tunnel's body limit. Raise **Largest request body** on the tunnel (`maxBodySizeMb`).                                                                                                                 |
+| `uninstall` refuses: agent halves are installed             | Agent halves run here for this agent. Unhost or uninstall those plugins on the panel (the next sync removes them), or `sudo lamaste-agent apphost disable --force` (data is kept).                                                  |
+| `apphost enable` says the install is not root-owned         | Root installs the helper only from code no other user can change: `sudo npm install -g @lamalibre/lamaste-agent@4.3.1`, then `sudo lamaste-agent apphost enable` from that install.                                                       |
+| `apphost enable` says the helper serves another user        | App hosting serves one OS user per machine. Unhost or uninstall the plugins that user's agents host (`sudo lamaste-agent apphost status` lists their agent halves), then `sudo lamaste-agent apphost enable --user <name> --force`. |
+| `apphost pin` says a label is not an agent of the user      | Root pins only labels the agent user's registry lists. Pin as the user the agent runs as (`--user <name>`; `--user root` for an agent running as root).                                                                             |
+| Hosting refused: the helper trusts another relay key        | The relay's signing key was replaced, or the agent enrolled again. Run `sudo lamaste-agent apphost pin`; compare the key id with the relay's ([App Host](../04-api-reference/app-host.md#pinning-the-relay-key)).                   |
 
 ## For Developers
 

package/vendor/docs/02-guides/certificate-management.md

@@ -196,7 +196,7 @@ The admin certificate (`CN=admin`) has unrestricted access to all panel endpoint
 
 ### Distribute to the Agent Machine
 
-Send the `.p12` file and password to the agent machine (macOS or Linux) securely, and install the agent there with `npm install -g @lamalibre/lamaste-agent@4.2.0` and run `lamaste-agent setup --label <label>` — or import it into the Desktop App. An enrollment token is preferable where possible, because the private key is then generated on the agent and never travels. See [Agent Setup](agent-setup.md) for details.
+Send the `.p12` file and password to the agent machine (macOS or Linux) securely, and install the agent there with `npm install -g @lamalibre/lamaste-agent@4.3.1` and run `lamaste-agent setup --label <label>` — or import it into the Desktop App. An enrollment token is preferable where possible, because the private key is then generated on the agent and never travels. See [Agent Setup](agent-setup.md) for details.
 
 ### Update Capabilities
 
@@ -293,7 +293,7 @@ Revocation is immediate — the certificate serial is added to a revocation list
 
 ### mTLS Rotation Internals
 
-Admin certificate rotation lives only in `lamaste-server reset-admin` (`packages/server/cli/src/commands/reset-admin.js`), run as root on the server. The panel's `rotateClientCert()` in `lib/mtls.js` is a stub that returns `503` with that instruction; `@lamalibre/lamaste@4.2.0/server` no longer exports a rotation function. The PKI directory belongs to `lamaste`, so `reset-admin` runs every file operation inside it (`openssl genrsa`/`req`/`x509 -req`/`pkcs12`, `cp`, `chmod`) as `lamaste`, and writes `panel.json` and `revoked.json` as fresh files renamed into place — root never writes through a path the panel could have replaced with a symlink.
+Admin certificate rotation lives only in `lamaste-server reset-admin` (`packages/server/cli/src/commands/reset-admin.js`), run as root on the server. The panel's `rotateClientCert()` in `lib/mtls.js` is a stub that returns `503` with that instruction; `@lamalibre/lamaste@4.3.1/server` no longer exports a rotation function. The PKI directory belongs to `lamaste`, so `reset-admin` runs every file operation inside it (`openssl genrsa`/`req`/`x509 -req`/`pkcs12`, `cp`, `chmod`) as `lamaste`, and writes `panel.json` and `revoked.json` as fresh files renamed into place — root never writes through a path the panel could have replaced with a symlink.
 
 The PKCS12 bundle uses legacy encryption settings (`-keypbe PBE-SHA1-3DES -certpbe PBE-SHA1-3DES -macalg sha1`) because newer OpenSSL defaults produce files that macOS Keychain Access cannot import.
 

package/vendor/docs/02-guides/cloud-provisioning.md

@@ -14,7 +14,7 @@ Before you start, make sure you have:
 
 | Requirement               | Details                                                                                                                                                           |
 | ------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| **Desktop app installed** | `npx @lamalibre/create-lamaste-desktop@4.2.0` ([setup guide](desktop-app-setup.md))                                                                                     |
+| **Desktop app installed** | `npx @lamalibre/create-lamaste-desktop@4.3.1` ([setup guide](desktop-app-setup.md))                                                                                     |
 | **DigitalOcean account**  | A free account at [cloud.digitalocean.com](https://cloud.digitalocean.com). **If you have other infrastructure on DO, create a dedicated team first** (see below) |
 | **Payment method**        | A credit card or PayPal on file in DigitalOcean (required to create droplets)                                                                                     |
 | **Domain name**           | Optional for initial setup — you can add a domain later through the panel                                                                                         |
@@ -221,8 +221,8 @@ The wizard shows up to 12 steps with live progress indicators. Each step shows a
 | **Waiting for boot**            | Polls DigitalOcean until the droplet has a public IP and is ready (up to 5 minutes)                         |
 | **Setting up DNS records**      | Creates A and wildcard A records in DigitalOcean DNS (only if a domain was selected in the Domain step)     |
 | **Connecting via SSH**          | Establishes an SSH connection using the temporary key                                                       |
-| **Installing Lamaste**          | Runs `npx @lamalibre/create-lamaste@4.2.0` on the droplet (up to 10 minutes)                                      |
-| **Retrieving credentials**      | Downloads the admin certificate (`.p12` file) from the droplet                                              |
+| **Installing Lamaste**          | Runs `npx @lamalibre/create-lamaste@4.3.1` on the droplet (up to 10 minutes)                                      |
+| **Retrieving credentials**      | Downloads the admin certificate (`.p12` file) and reads the panel's TLS key pin from the droplet            |
 | **Enrolling admin certificate** | Imports the certificate into your OS credential store                                                       |
 | **Saving configuration**        | Writes the server entry to `~/.lamalibre/lamaste/servers.json`                                              |
 | **Cleaning up**                 | Deletes the temporary SSH key from DigitalOcean and your machine                                            |
@@ -315,7 +315,7 @@ If you already have a Lamaste server set up (via the manual SSH method), you can
 
 The app checks that the panel is reachable before adding it. The server is added with `active: false` — click **Set Active** on its card to start using it.
 
-> **Note:** Adding an existing server registers it in the app but does not configure authentication. You will still need to set up your agent certificate separately using `lamaste-agent setup` (after `npm install -g @lamalibre/lamaste-agent@4.2.0`) or by importing a certificate manually.
+> **Note:** Adding an existing server registers it in the app but does not configure authentication. You will still need to set up your agent certificate separately using `lamaste-agent setup` (after `npm install -g @lamalibre/lamaste-agent@4.3.1`) or by importing a certificate manually.
 
 ---
 

package/vendor/docs/02-guides/desktop-app-setup.md

@@ -26,7 +26,7 @@ The Lamaste Desktop app is a native application (built with Tauri) that wraps th
 Run the installer:
 
 ```bash
-npx @lamalibre/create-lamaste-desktop@4.2.0
+npx @lamalibre/create-lamaste-desktop@4.3.1
 ```
 
 The installer:
@@ -56,11 +56,11 @@ After the app launches, it shows a setup screen with two options:
 Install the agent globally and run its setup command:
 
 ```bash
-npm install -g @lamalibre/lamaste-agent@4.2.0
+npm install -g @lamalibre/lamaste-agent@4.3.1
 lamaste-agent setup --label my-server
 ```
 
-The agent must be a global install — setup installs a sync timer that runs it every 30 seconds to pick up tunnel changes, and refuses to run from `npx`. (When the app sets up an agent itself, it installs `@lamalibre/lamaste-agent@4.2.0` globally for you.) The `--label` flag names this agent connection (used for multi-agent support). This command connects to your VPS panel using the agent certificate and configures the local Chisel client. During setup, the client certificate and key are extracted from the P12 bundle for mTLS client authentication. Once setup completes, the app detects the configuration and switches to the main interface.
+The agent must be a global install — setup installs a sync timer that runs it every 30 seconds to pick up tunnel changes, and refuses to run from `npx`. (When the app sets up an agent itself, it installs `@lamalibre/lamaste-agent@4.3.1` globally for you.) The `--label` flag names this agent connection (used for multi-agent support). This command connects to your VPS panel using the agent certificate and configures the local Chisel client. During setup, the client certificate and key are extracted from the P12 bundle for mTLS client authentication. Once setup completes, the app detects the configuration and switches to the main interface.
 
 **Option B: Create a new server**
 
@@ -72,7 +72,7 @@ The desktop app has two modes, toggled via a pill switch in the sidebar header.
 
 ### Agent Mode (default)
 
-Agent mode provides local agent management. The agent-mode pages (Dashboard, Tunnels, Services, Plugins, Logs, Settings) are imported from the shared `@lamalibre/lamaste-agent-ui@4.2.0` package. The landing page is the **Agents** list, showing all configured agents with their connection status. Click an agent to drill into its management pages:
+Agent mode provides local agent management. The agent-mode pages (Dashboard, Tunnels, Services, Plugins, Logs, Settings) are imported from the shared `@lamalibre/lamaste-agent-ui@4.3.1` package. The landing page is the **Agents** list, showing all configured agents with their connection status. Click an agent to drill into its management pages:
 
 - **Agents** (landing) — list of all configured agents with start/stop controls and status
 - **Dashboard** — per-agent connection status, Chisel version, start/stop/restart controls
@@ -84,7 +84,7 @@ Agent mode provides local agent management. The agent-mode pages (Dashboard, Tun
 
 ### Server Mode
 
-Server mode provides the full admin panel — the same management pages available in the browser-based panel UI. These pages are imported from the shared `@lamalibre/lamaste-server-ui@4.2.0` package:
+Server mode provides the full admin panel — the same management pages available in the browser-based panel UI. These pages are imported from the shared `@lamalibre/lamaste-server-ui@4.3.1` package:
 
 - **Dashboard** — system stats (CPU, RAM, disk, uptime) + service health
 - **Tunnels** — tunnel CRUD, carrying agent, access mode, body limit
@@ -149,6 +149,7 @@ The multi-server management page:
 - **Add existing server** — connect to a server you already set up manually by providing the panel URL and certificate
 - **Server switching** — switch the active server; the app reloads configuration and reconnects
 - **Server removal** — remove a server from the registry (cloud-provisioned servers can also be destroyed)
+- **Panel TLS key** — a panel reached at its IP address (`https://<ip>:9292`) has a self-signed certificate, so the app pins its public key: read from the server over SSH when the app provisioned it, otherwise on the first connection. The card shows the pin (`sha256//…`) and where it came from; compare it with `sudo lamaste-server panel-pin` on the server. Every call to the panel must present that key — a different one is refused before anything is sent. After reinstalling a server or replacing its certificate, **Re-pin** shows the key the panel presents now next to the pinned one and replaces it only when you accept. A panel reached at its domain is verified by its Let's Encrypt certificate instead
 
 **Cloud provider tokens** are stored in your OS credential store (macOS Keychain or Linux libsecret) — never in plaintext files or process arguments. P12 passwords for each server are also stored in the credential store.
 
@@ -169,7 +170,7 @@ Stopping an agent's tunnels from the app is remembered: the agent's sync timer k
 Run the installer again to get the latest version:
 
 ```bash
-npx @lamalibre/create-lamaste-desktop@4.2.0
+npx @lamalibre/create-lamaste-desktop@4.3.1
 ```
 
 If a new release is available, it downloads and installs the update. The previous version is replaced.
@@ -202,9 +203,9 @@ Deleting `~/.lamalibre/lamaste/` by hand instead would leave the agents' service
 
 | Action               | Command / Location                                                                   |
 | -------------------- | ------------------------------------------------------------------------------------ |
-| **Install**          | `npx @lamalibre/create-lamaste-desktop@4.2.0`                                              |
-| **Update**           | `npx @lamalibre/create-lamaste-desktop@4.2.0`                                              |
-| **Agent setup**      | `npm install -g @lamalibre/lamaste-agent@4.2.0`, then `lamaste-agent setup --label <name>` |
+| **Install**          | `npx @lamalibre/create-lamaste-desktop@4.3.1`                                              |
+| **Update**           | `npx @lamalibre/create-lamaste-desktop@4.3.1`                                              |
+| **Agent setup**      | `npm install -g @lamalibre/lamaste-agent@4.3.1`, then `lamaste-agent setup --label <name>` |
 | **App location**     | `/Applications/Lamaste.app` (macOS)                                                  |
 | **Agent registry**   | `~/.lamalibre/lamaste/agents.json`                                                   |
 | **Per-agent data**   | `~/.lamalibre/lamaste/agents/<label>/`                                               |
@@ -215,7 +216,7 @@ Deleting `~/.lamalibre/lamaste/` by hand instead would leave the agents' service
 | **Chisel logs**      | `~/.lamalibre/lamaste/agents/<label>/logs/chisel.log`                                |
 | **Cloud tokens**     | OS credential store (`com.lamalibre.cloud`)                                          |
 | **P12 passwords**    | OS credential store (`com.lamalibre.lamaste.server`)                                 |
-| **npm package**      | `@lamalibre/create-lamaste-desktop@4.2.0`                                                  |
+| **npm package**      | `@lamalibre/create-lamaste-desktop@4.3.1`                                                  |
 
 ### Related Documentation
 

package/vendor/docs/02-guides/installation.md

@@ -62,7 +62,7 @@ Execute the Lamaste installer:
 
 ```bash
 apt install -y npm
-npx @lamalibre/create-lamaste@4.2.0
+npx @lamalibre/create-lamaste@4.3.1
 ```
 
 The installer displays a confirmation banner before making any changes:
@@ -90,7 +90,7 @@ The installer displays a confirmation banner before making any changes:
   Press Enter to continue or Ctrl+C to abort...
 ```
 
-Press **Enter** to proceed. To skip the confirmation prompt, use `npx @lamalibre/create-lamaste@4.2.0 --yes`.
+Press **Enter** to proceed. To skip the confirmation prompt, use `npx @lamalibre/create-lamaste@4.3.1 --yes`.
 
 ### 4. What the Installer Does
 
@@ -380,7 +380,7 @@ The service includes security hardening: `ProtectHome=true`, `PrivateTmp=true`,
 
 | Item                     | Value                                                        |
 | ------------------------ | ------------------------------------------------------------ |
-| **Install command**      | `npx @lamalibre/create-lamaste@4.2.0`                              |
+| **Install command**      | `npx @lamalibre/create-lamaste@4.3.1`                              |
 | **Minimum VPS**          | Ubuntu 24.04, 512 MB RAM                                     |
 | **Required ports**       | 22 (SSH), 80 (HTTP/Let's Encrypt), 443 (HTTPS), 9292 (panel) |
 | **Certificate location** | `/etc/lamalibre/lamaste/pki/client.p12`                      |

package/vendor/docs/02-guides/onboarding.md

@@ -113,7 +113,7 @@ Chisel is the tunneling engine. The installer already put the pinned Chisel rele
 
 Authelia provides two-factor authentication for your tunneled apps. The installer already put the pinned Authelia release, its systemd unit and its `lamaste-authelia` service account in place; the provisioner checks the binary is there, writes the configuration file (using your domain), creates the initial admin user with a random password, and starts the service. Authelia listens on `127.0.0.1:9091`.
 
-Onboarding downloads nothing. If either task fails with "… is not installed. Run `npx @lamalibre/create-lamaste@4.2.0` on the server to repair the installation.", re-run the installer on the server (it is idempotent) and start provisioning again.
+Onboarding downloads nothing. If either task fails with "… is not installed. Run `npx @lamalibre/create-lamaste@4.3.1` on the server to repair the installation.", re-run the installer on the server (it is idempotent) and start provisioning again.
 
 Authelia uses **bcrypt** for password hashing (not argon2id) because argon2id uses approximately 93 MB per hash, which causes out-of-memory kills on a 512 MB droplet.
 
@@ -213,7 +213,7 @@ Each provisioning task calls library functions in `packages/lamaste-serverd/src/
 
 The DNS check resolves these hostnames using Node's `dns.resolve4()`:
 
-1. `panel.example.com`, `auth.example.com`, `tunnel.example.com` — must resolve to the server IP (required; `CORE_SUBDOMAINS` in `@lamalibre/lamaste@4.2.0`)
+1. `panel.example.com`, `auth.example.com`, `tunnel.example.com` — must resolve to the server IP (required; `CORE_SUBDOMAINS` in `@lamalibre/lamaste@4.3.1`)
 2. `test-lamaste-check.example.com` — tests wildcard resolution (optional)
 3. `example.com` — reported, not required
 

package/vendor/docs/02-guides/standalone-plugin-with-tickets.md

@@ -27,7 +27,7 @@ Using the desktop app's cloud provisioning wizard:
 
 - Enter your DigitalOcean API token
 - Select a region and droplet size
-- The wizard calls `@lamalibre/lamaste-cloud@4.2.0` to create the droplet
+- The wizard calls `@lamalibre/lamaste-cloud@4.3.1` to create the droplet
 - Progress streams back as NDJSON events in the desktop UI
 - Complete onboarding in the browser panel
 
@@ -96,7 +96,7 @@ The Sync server now runs as a local service on the Mac. It operates independentl
 
 ### 5. Register Sync Scopes and Instance on Lamaste
 
-The Sync server detects that the Mac has a Lamaste agent certificate. Using that cert (mTLS), it registers a ticket scope and instance with the Lamaste panel. This is handled automatically by `TicketInstanceManager` from `@lamalibre/lamaste-tickets@4.2.0` — the admin does not need to do anything.
+The Sync server detects that the Mac has a Lamaste agent certificate. Using that cert (mTLS), it registers a ticket scope and instance with the Lamaste panel. This is handled automatically by `TicketInstanceManager` from `@lamalibre/lamaste-tickets@4.3.1` — the admin does not need to do anything.
 
 ```mermaid
 sequenceDiagram

package/vendor/docs/03-architecture/installer-flow.md

@@ -1,6 +1,6 @@
 # Installer Flow
 
-## What `npx @lamalibre/create-lamaste@4.2.0` Does
+## What `npx @lamalibre/create-lamaste@4.3.1` Does
 
 The installer is a **zero-prompt, fire-and-forget** command. It assumes:
 
@@ -13,7 +13,7 @@ It requires **no user input**. All configuration happens later through the brows
 ## Execution Flow
 
 ```
-$ npx @lamalibre/create-lamaste@4.2.0
+$ npx @lamalibre/create-lamaste@4.3.1
 
   Lamaste Installer v1.0.0