@lamalibre/create-lamaste 4.2.0 → 4.3.1

package/src/tasks/gatekeeper.js

@@ -130,7 +130,12 @@ export function gatekeeperTasks(ctx, task) {
         // immediately. Successful auth (200) is cached for 10s — matching
         // the Cache-Control max-age Gatekeeper sets on the response. Omitting
         // `proxy_ignore_headers Cache-Control` means nginx will honor the
-        // upstream max-age as a further shortening signal.
+        // upstream max-age as a further shortening signal. The key names the
+        // vhost by `$server_name`, never `$http_host`: an absolute-form request
+        // line selects one vhost while the client's Host header names another,
+        // and a decision cached for that other tunnel would be replayed here.
+        // The hostname comes first and `|` separates it: a hostname cannot
+        // contain `|`, so no other session and hostname make the same key.
         const cacheConfig = `# Lamaste Gatekeeper auth response cache zone
 # Scope: http{}. Included from nginx.conf.
 proxy_cache_path /var/cache/nginx/authz levels=1:2
@@ -139,9 +144,9 @@ proxy_cache_path /var/cache/nginx/authz levels=1:2
     inactive=5m;
 `;
         const cacheLocConfig = `# Lamaste Gatekeeper auth_request cache policy
-# Scope: location{} using auth_request /authz/check.
+# Scope: the location{} a tunnel vhost's auth_request targets.
 proxy_cache lamaste_authz;
-proxy_cache_key "$cookie_authelia_session$http_host";
+proxy_cache_key "$server_name|$cookie_authelia_session";
 proxy_cache_valid 200 10s;
 proxy_cache_valid 403 0;
 proxy_cache_use_stale off;

package/src/tasks/node.js

@@ -1,13 +1,19 @@
 import { execa } from 'execa';
-import { unlink } from 'node:fs/promises';
-
-const REQUIRED_MAJOR = 22;
+import {
+  MIN_NODE_VERSION,
+  NODE_BIN,
+  NODE_MAJOR,
+  installNodeFromNodeSource,
+  installedNodeVersion,
+  nodeTooNewError,
+  nodeVersionSupported,
+  nodeVersionTooNew,
+} from '../lib/node-version.js';
 
 /**
- * Node.js 22 LTS installation subtasks.
- *
- * 22.5+ is the minimum because lamaste-serverd uses the built-in
- * `node:sqlite` module (which requires 22.5+).
+ * Node.js installation subtasks: {@link NODE_BIN} must be at least
+ * {@link MIN_NODE_VERSION} and below `MAX_NODE_MAJOR_EXCLUSIVE` (see
+ * lib/node-version.js for why). An older Node.js is upgraded from NodeSource.
  *
  * @param {object} ctx  Shared installer context.
  * @param {object} task Parent Listr2 task reference.
@@ -18,67 +24,27 @@ export function nodeTasks(ctx, task) {
     {
       title: 'Checking existing Node.js installation',
       task: async (_ctx, subtask) => {
-        try {
-          const { stdout } = await execa('node', ['--version']);
-          const version = stdout.trim();
-          const major = parseInt(version.replace(/^v/, ''), 10);
-
-          if (major >= REQUIRED_MAJOR) {
-            ctx.nodeAlreadyInstalled = true;
-            subtask.output = `Node.js ${version} found, skipping install`;
-          } else {
-            subtask.output = `Node.js ${version} found (below v${REQUIRED_MAJOR}), will upgrade`;
-          }
-        } catch {
-          subtask.output = `Node.js not found, installing v${REQUIRED_MAJOR} LTS`;
-        }
-      },
-      rendererOptions: { persistentOutput: true },
-    },
-    {
-      title: 'Installing NodeSource repository',
-      skip: () => ctx.nodeAlreadyInstalled && `Node.js ${REQUIRED_MAJOR}+ already installed`,
-      task: async (_ctx, subtask) => {
-        const setupScript = '/tmp/nodesource_setup.sh';
-
-        subtask.output = 'Downloading NodeSource setup script...';
-        try {
-          await execa('curl', [
-            '-fsSL',
-            `https://deb.nodesource.com/setup_${REQUIRED_MAJOR}.x`,
-            '-o',
-            setupScript,
-          ]);
-        } catch (error) {
-          throw new Error(
-            `Failed to download NodeSource setup script. Check your internet connection.\n${error.stderr || error.message}`,
-          );
-        }
-
-        subtask.output = 'Running NodeSource setup...';
-        try {
-          await execa('bash', [setupScript]);
-        } catch (error) {
-          throw new Error(`NodeSource setup script failed.\n${error.stderr || error.message}`);
+        const version = await installedNodeVersion();
+        if (version === null) {
+          subtask.output = `Node.js not found at ${NODE_BIN}, installing ${NODE_MAJOR}.x`;
+        } else if (nodeVersionSupported(version)) {
+          ctx.nodeAlreadyInstalled = true;
+          subtask.output = `Node.js ${version} found, skipping install`;
+        } else if (nodeVersionTooNew(version)) {
+          throw nodeTooNewError(version);
+        } else {
+          subtask.output = `Node.js ${version} found (below ${MIN_NODE_VERSION}), will upgrade`;
         }
-
-        await unlink(setupScript).catch(() => {});
-        subtask.output = 'NodeSource repository added';
       },
       rendererOptions: { persistentOutput: true },
     },
     {
-      title: `Installing Node.js ${REQUIRED_MAJOR} LTS`,
-      skip: () => ctx.nodeAlreadyInstalled && `Node.js ${REQUIRED_MAJOR}+ already installed`,
+      title: `Installing Node.js ${NODE_MAJOR} LTS`,
+      skip: () => ctx.nodeAlreadyInstalled && `Node.js ${MIN_NODE_VERSION}+ already installed`,
       task: async (_ctx, subtask) => {
-        subtask.output = 'Running apt-get install nodejs...';
-        try {
-          await execa('apt-get', ['install', '-y', 'nodejs']);
-        } catch (error) {
-          throw new Error(
-            `Failed to install Node.js. Try running 'apt-get update' manually and retrying.\n${error.stderr || error.message}`,
-          );
-        }
+        await installNodeFromNodeSource((line) => {
+          subtask.output = line;
+        });
         subtask.output = 'Node.js installed';
       },
       rendererOptions: { persistentOutput: true },
@@ -86,23 +52,16 @@ export function nodeTasks(ctx, task) {
     {
       title: 'Verifying Node.js installation',
       task: async (_ctx, subtask) => {
-        const { stdout: nodeVersion } = await execa('node', ['--version']);
+        const nodeVersion = await installedNodeVersion();
         const { stdout: npmVersion } = await execa('npm', ['--version']);
-
-        const trimmedNode = nodeVersion.trim();
-        const trimmedNpm = npmVersion.trim();
-        const major = parseInt(trimmedNode.replace(/^v/, ''), 10);
-
-        if (major < REQUIRED_MAJOR) {
+        if (nodeVersion === null || !nodeVersionSupported(nodeVersion)) {
           throw new Error(
-            `Expected Node.js v${REQUIRED_MAJOR}+, got ${trimmedNode}. Installation may have failed.`,
+            `Expected Node.js ${MIN_NODE_VERSION}+ at ${NODE_BIN}, got ${nodeVersion ?? 'none'}. Installation may have failed.`,
           );
         }
-
-        ctx.nodeVersion = trimmedNode;
-        ctx.npmVersion = trimmedNpm;
-
-        subtask.output = `Node.js ${trimmedNode}, npm ${trimmedNpm}`;
+        ctx.nodeVersion = nodeVersion;
+        ctx.npmVersion = npmVersion.trim();
+        subtask.output = `Node.js ${nodeVersion}, npm ${ctx.npmVersion}`;
       },
       rendererOptions: { persistentOutput: true },
     },

package/src/tasks/redeploy.js

@@ -12,6 +12,15 @@ import { generateCertHelpPage } from '../lib/cert-help-page.js';
 import { ensureRootOwnedInstallDir, removeTree, writeFileNoFollow } from '../lib/ownership.js';
 import { provisionRelayServices } from '../lib/relay-services.js';
 import { installSudoersFile, installSudoersWrappers } from '../lib/wrappers.js';
+import {
+  MIN_NODE_VERSION,
+  NODE_BIN,
+  installNodeFromNodeSource,
+  installedNodeVersion,
+  nodeTooNewError,
+  nodeVersionSupported,
+  nodeVersionTooNew,
+} from '../lib/node-version.js';
 import { deployGatekeeperPackage } from './gatekeeper.js';
 
 const GATEKEEPER_SERVICE = 'lamalibre-lamaste-gatekeeper';
@@ -115,6 +124,33 @@ export function redeployTasks(ctx, task) {
       },
       rendererOptions: { persistentOutput: true },
     },
+    {
+      title: 'Checking Node.js',
+      task: async (_ctx, subtask) => {
+        // NodeSource's 22.x line moves on its own; the relay needs at least
+        // MIN_NODE_VERSION (the hook runner's sandbox uses the stable
+        // permission model). A full install checks this too; a redeploy is
+        // where an existing relay gets the upgrade.
+        const version = await installedNodeVersion();
+        if (version !== null && nodeVersionSupported(version)) {
+          subtask.output = `Node.js ${version}`;
+          return;
+        }
+        if (version !== null && nodeVersionTooNew(version)) throw nodeTooNewError(version);
+        await execa('apt-get', ['update']);
+        await installNodeFromNodeSource((line) => {
+          subtask.output = line;
+        });
+        const upgraded = await installedNodeVersion();
+        if (upgraded === null || !nodeVersionSupported(upgraded)) {
+          throw new Error(
+            `Expected Node.js ${MIN_NODE_VERSION}+ at ${NODE_BIN} after the upgrade, got ${upgraded ?? 'none'}`,
+          );
+        }
+        subtask.output = `Node.js upgraded to ${upgraded}`;
+      },
+      rendererOptions: { persistentOutput: true },
+    },
     {
       title: 'Updating serverd',
       task: async (_ctx, subtask) => {

package/vendor/docs/00-introduction/how-it-works.md

@@ -55,14 +55,14 @@ SSH into a fresh Ubuntu droplet and run one command:
 
 ```bash
 apt install -y npm
-npx @lamalibre/create-lamaste@4.2.0
+npx @lamalibre/create-lamaste@4.3.1
 ```
 
 This installs everything the relay needs: nginx, Node.js, firewall rules, certificates, and the management panel. At the end, it prints a client certificate file and password. You download the certificate, import it into your browser, and disconnect SSH. You never SSH in again.
 
 **Option B: Desktop app (cloud provisioning)**
 
-Install the desktop app (`npx @lamalibre/create-lamaste-desktop@4.2.0`) and use the Servers tab to create a DigitalOcean droplet. The app handles everything — droplet creation, Lamaste installation, certificate download, and connection — without you ever touching SSH. Cloud API tokens are stored in your OS credential store (macOS Keychain or Linux libsecret), never in plaintext. See the [Cloud Provisioning guide](../02-guides/cloud-provisioning.md) for a step-by-step walkthrough.
+Install the desktop app (`npx @lamalibre/create-lamaste-desktop@4.3.1`) and use the Servers tab to create a DigitalOcean droplet. The app handles everything — droplet creation, Lamaste installation, certificate download, and connection — without you ever touching SSH. Cloud API tokens are stored in your OS credential store (macOS Keychain or Linux libsecret), never in plaintext. See the [Cloud Provisioning guide](../02-guides/cloud-provisioning.md) for a step-by-step walkthrough.
 
 **Phase 2: Onboarding (10 minutes, browser)**
 

package/vendor/docs/00-introduction/quickstart.md

@@ -59,7 +59,7 @@ Once connected:
 
 ```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 showing what it will do:
@@ -253,7 +253,7 @@ Every tunnel is carried by one **agent** — the machine that runs the app. Enro
 Install the Lamaste Desktop app, which provides a GUI with automatic service discovery and one-click tunnel creation:
 
 ```bash
-npx @lamalibre/create-lamaste-desktop@4.2.0
+npx @lamalibre/create-lamaste-desktop@4.3.1
 ```
 
 The app auto-detects local services (Ollama, ComfyUI, PostgreSQL, Docker containers, etc.) and lets you expose them with one click. See the [Desktop App Setup](../02-guides/desktop-app-setup.md) guide for details.
@@ -263,7 +263,7 @@ The app auto-detects local services (Ollama, ComfyUI, PostgreSQL, Docker contain
 In the panel, go to **Certificates → Enrollment Token** and create a token for a label such as `laptop`. Then, on the machine that runs your app, install the agent globally and run setup:
 
 ```bash
-npm install -g @lamalibre/lamaste-agent@4.2.0
+npm install -g @lamalibre/lamaste-agent@4.3.1
 LAMALIBRE_LAMASTE_ENROLLMENT_TOKEN=<token> \
   lamaste-agent setup --label laptop --panel-url https://203.0.113.42:9292
 ```
@@ -345,7 +345,7 @@ Your Mac                          DigitalOcean Droplet            Internet
 The installer accepts optional flags:
 
 ```bash
-npx @lamalibre/create-lamaste@4.2.0 [flags]
+npx @lamalibre/create-lamaste@4.3.1 [flags]
 ```
 
 | Flag            | Effect                                          |
@@ -435,7 +435,7 @@ In development mode (`NODE_ENV=development` or `NODE_ENV` unset), the panel serv
 # 2. SSH in and install
 ssh root@203.0.113.42
 apt install -y npm
-npx @lamalibre/create-lamaste@4.2.0
+npx @lamalibre/create-lamaste@4.3.1
 
 # 3. Download cert (from your local machine)
 scp root@203.0.113.42:/etc/lamalibre/lamaste/pki/client.p12 .

package/vendor/docs/00-introduction/what-is-lamaste.md

@@ -36,7 +36,7 @@ Lamaste solves the problem of exposing local services to the internet securely.
 **Option A: Manual setup (SSH)**
 
 1. Create a fresh Ubuntu 24.04 droplet on DigitalOcean
-2. SSH in once and run `npx @lamalibre/create-lamaste@4.2.0`
+2. SSH in once and run `npx @lamalibre/create-lamaste@4.3.1`
 3. Download the client certificate it prints
 4. Import the certificate into your browser
 5. Open `https://<droplet-ip>:9292` — you are in the admin panel
@@ -46,7 +46,7 @@ Lamaste solves the problem of exposing local services to the internet securely.
 
 **Option B: Desktop app cloud provisioning**
 
-1. Install the desktop app (`npx @lamalibre/create-lamaste-desktop@4.2.0`)
+1. Install the desktop app (`npx @lamalibre/create-lamaste-desktop@4.3.1`)
 2. Go to the Servers tab and click "Create a new server"
 3. Enter your DigitalOcean API token — the app validates scopes and stores it securely in your OS credential store
 4. Pick a region (the app measures latency to each) and a domain name
@@ -93,14 +93,14 @@ All backend services bind `127.0.0.1` only — nginx is the sole public-facing s
 
 State is stored in JSON files (`/etc/lamalibre/lamaste/panel.json`, `tunnels.json`) with atomic writes (write to temp → fsync → rename). No database is needed at this scale.
 
-The installer (`npx @lamalibre/create-lamaste@4.2.0`) is completely non-interactive — it detects the environment, provisions everything, and prints a summary. All configuration happens through the browser-based onboarding wizard after installation.
+The installer (`npx @lamalibre/create-lamaste@4.3.1`) is completely non-interactive — it detects the environment, provisions everything, and prints a summary. All configuration happens through the browser-based onboarding wizard after installation.
 
 ## Quick Reference
 
 | Item                 | Value                           |
 | -------------------- | ------------------------------- |
 | **Minimum VPS**      | 512MB RAM, Ubuntu 24.04         |
-| **Install command**  | `npx @lamalibre/create-lamaste@4.2.0` |
+| **Install command**  | `npx @lamalibre/create-lamaste@4.3.1` |
 | **Admin panel**      | `https://<ip>:9292` (mTLS)      |
 | **Auth for admin**   | Client certificate (zero-login) |
 | **Auth for apps**    | TOTP 2FA via Authelia           |
@@ -108,5 +108,5 @@ The installer (`npx @lamalibre/create-lamaste@4.2.0`) is completely non-interact
 | **TLS certificates** | Let's Encrypt (auto-renewing)   |
 | **State storage**    | JSON files (no database)        |
 | **RAM usage**        | ~245MB total (all services)     |
-| **npm package**      | `@lamalibre/create-lamaste@4.2.0`     |
+| **npm package**      | `@lamalibre/create-lamaste@4.3.1`     |
 | **License**          | Polyform Noncommercial 1.0.0    |

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

@@ -289,10 +289,11 @@ location /authelia {
     proxy_pass http://127.0.0.1:9091/api/verify?rd=https://auth.example.com/;
     proxy_pass_request_body off;
     proxy_set_header Content-Length "";
-    proxy_set_header X-Original-URL $scheme://$http_host$request_uri;
+    # This vhost's own hostname, never $http_host (see below)
+    proxy_set_header X-Original-URL https://app.example.com$request_uri;
     proxy_set_header X-Forwarded-Method $request_method;
     proxy_set_header X-Forwarded-Proto $scheme;
-    proxy_set_header X-Forwarded-Host $http_host;
+    proxy_set_header X-Forwarded-Host app.example.com;
     proxy_set_header X-Forwarded-Uri $request_uri;
     proxy_set_header X-Forwarded-For $remote_addr;
 }
@@ -314,9 +315,11 @@ location / {
 }
 
 # Unauthenticated users are redirected to Authelia
-error_page 401 =302 https://auth.example.com/?rd=$scheme://$http_host$request_uri;
+error_page 401 =302 https://auth.example.com/?rd=https://app.example.com$request_uri;
 ```
 
+Authelia decides by the URL it is asked about, so the vhost writes its own hostname into it. `$http_host` — the client's `Host` header — would let a client send the request line of this vhost (`GET https://app.example.com/ HTTP/1.1`, which nginx uses to select the vhost) with the `Host` of a hostname its rules allow, and be let in here. Lamaste's generated vhosts do this; see [nginx Configuration](../03-architecture/nginx-configuration.md#authorization-subrequests-name-their-own-hostname).
+
 The flow works like this:
 
 ```

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

@@ -95,25 +95,37 @@ Gatekeeper watches its state files (`groups.json`, `access-grants.json`) for cha
 
 ### Architecture
 
-Gatekeeper runs as an independent Fastify service on `127.0.0.1:9294`. nginx uses `auth_request` to delegate authorization decisions to it, similar to how Authelia handles authentication via the same pattern.
+Gatekeeper runs as an independent Fastify service on `127.0.0.1:9294`. The vhost of every `authenticated` and `restricted` tunnel delegates each request to it with an nginx `auth_request` to `/authz/tunnel/<fqdn>` — the vhost names its tunnel in the path; Gatekeeper validates the Authelia session itself and decides.
 
 The request flow for a restricted tunnel:
 
 ```
 1. Visitor requests staging.example.com
-2. nginx sends auth_request to Authelia (127.0.0.1:9091)
-3. Authelia validates session cookie:
-   a. No valid session -> 401 -> nginx redirects to auth.example.com
-   b. Valid session -> 200 with Remote-User/Remote-Groups headers
-4. nginx sends auth_request to Gatekeeper (127.0.0.1:9294)
-   - Forwards Remote-User, Remote-Groups, and Host headers
-5. Gatekeeper checks for a matching grant:
-   a. Grant exists (user or group match) -> 200
+2. nginx sends auth_request to Gatekeeper
+   (127.0.0.1:9294/authz/tunnel/staging.example.com) with
+   - X-Original-URL https://staging.example.com<request URI> and
+     Host staging.example.com — the vhost's own hostname, from its configuration
+   - X-Original-Method and the visitor's Cookie header
+3. Gatekeeper takes the tunnel named in the path (X-Original-URL and Host
+   must agree) and validates the Authelia session cookie with Authelia for
+   that URL:
+   a. No valid session -> 401 -> nginx redirects to
+      auth.example.com/?rd=https://staging.example.com<request URI>
+   b. Valid session -> the user (cached, see Session caching)
+4. Gatekeeper checks for a matching grant:
+   a. Grant exists (user or group match) -> 200 with Remote-User, Remote-Groups,
+      Remote-Name and Remote-Email
    b. No grant -> 403 with access request HTML page
-6. If both return 200: nginx proxies to the tunnel backend
+5. On 200 nginx proxies to the tunnel backend with those identity headers
 ```
 
-For public tunnels, nginx skips both auth_request directives. For authenticated tunnels, nginx uses only the Authelia auth_request and skips Gatekeeper.
+Public tunnel vhosts have no `auth_request`. For authenticated tunnels Gatekeeper answers 200 for any valid session without looking for a grant.
+
+### Which tunnel is authorized
+
+Gatekeeper authorizes the tunnel the vhost names, never one the client names. nginx selects the vhost from the request line when a request is in absolute form (`GET https://staging.example.com/ HTTP/1.1`) and from `Host` otherwise, so a client can send the request line of one tunnel with the `Host` header of another. Vhosts written before 4.3 called `/authz/check` with `X-Original-URL` and `Host` built from the client's `Host` header (`$http_host`): an Authelia user allowed on any tunnel — and every user is allowed on an `authenticated` one — reached any `restricted` tunnel, app or plugin, by naming the allowed tunnel in `Host`, without a grant, and Authelia evaluated that other URL as well.
+
+Generated vhosts now name their tunnel in the subrequest's path, `/authz/tunnel/<fqdn>`, as the agent-panel vhost names its agent, and write the same hostname into `X-Original-URL`, `Host` and the login redirect. Gatekeeper authorizes the tunnel in the path and refuses a check whose `X-Original-URL` or `Host` names another hostname, or has no `Host` (401), before asking Authelia. It refuses `/authz/check` outright (403): a vhost written before 4.3 that the panel has not rewritten closes its tunnel instead of opening it. The panel rewrites tunnel vhosts when it starts. Authelia-protected static sites, which ask Authelia directly, had the same flaw towards Authelia's per-site rules and are rewritten the same way; the auth portal's subrequest is rewritten too, as hardening. See [nginx Configuration](../03-architecture/nginx-configuration.md#authorization-subrequests-name-their-own-hostname).
 
 ### Grant model
 
@@ -170,7 +182,7 @@ State files use the same atomic write pattern as the rest of Lamaste (temp file
 When Gatekeeper denies a request (no matching grant), it returns a 403 response with an HTML page instead of a bare status code. The page is generated from templates in `packages/lamaste-gatekeeper/src/lib/templates.ts` and includes:
 
 - The username (from `Remote-User` header)
-- The resource they attempted to access (from `Host` header)
+- The resource they attempted to access (the tunnel's hostname, from `X-Original-URL` — written by the vhost)
 - A human-readable timestamp
 - Pre-filled message templates for email (mailto link), Slack, Teams, WhatsApp, and a generic plain-text format
 
@@ -212,11 +224,11 @@ The HTML is self-contained (inline CSS, no external dependencies) so it renders
 
 ### Access modes
 
-| Mode          | Authelia | Gatekeeper | Who can access              |
-| ------------- | -------- | ---------- | --------------------------- |
-| Public        | No       | No         | Anyone on the internet      |
-| Authenticated | Yes      | No         | Any logged-in Authelia user |
-| Restricted    | Yes      | Yes        | Users with a matching grant |
+| Mode          | Authelia | Gatekeeper           | Who can access              |
+| ------------- | -------- | -------------------- | --------------------------- |
+| Public        | No       | No                   | Anyone on the internet      |
+| Authenticated | Yes      | Yes (session only)   | Any logged-in Authelia user |
+| Restricted    | Yes      | Yes (session, grant) | Users with a matching grant |
 
 ### Cache TTLs
 

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

@@ -29,7 +29,7 @@ For the IP-based admin panel (`https://<ip>:9292`), there is no domain to verify
 
 ### When certificates are issued
 
-- **Self-signed + mTLS certs** — created during `npx @lamalibre/create-lamaste@4.2.0` installation
+- **Self-signed + mTLS certs** — created during `npx @lamalibre/create-lamaste@4.3.1` installation
 - **Core Let's Encrypt certs** — issued during onboarding for `panel`, `auth`, and `tunnel` subdomains
 - **App Let's Encrypt certs** — issued when you create a new tunnel or a managed static site
 - **Custom-domain site certs** — issued when a custom-domain site's DNS is verified: one certificate lineage, named after the site's domain, covering the domain and every redirect alias (re-issued when aliases change)
@@ -82,7 +82,7 @@ The most critical scenario is the mTLS CA expiring, but it has a 10-year validit
 
 ### Let's Encrypt implementation
 
-Lamaste uses certbot with the nginx plugin for certificate issuance. The implementation lives in `@lamalibre/lamaste@4.2.0/server` (`packages/core/lib/src/server/certbot.ts`), wrapped by `packages/server/daemon/src/lib/certbot.js`.
+Lamaste uses certbot with the nginx plugin for certificate issuance. The implementation lives in `@lamalibre/lamaste@4.3.1/server` (`packages/core/lib/src/server/certbot.ts`), wrapped by `packages/server/daemon/src/lib/certbot.js`.
 
 The panel runs as the unprivileged `lamaste` user and never runs `certbot` or `openssl` on Let's Encrypt files directly. It calls two root-owned wrapper scripts through sudo:
 
@@ -193,7 +193,7 @@ This three-step check prevents unnecessary certificate issuance and respects rat
 
 #### Custom-domain site certificate issuance
 
-A custom-domain static site may have redirect aliases (e.g. `www.myblog.net`). `issueSiteCert(fqdn, aliases, email)` in `@lamalibre/lamaste@4.2.0/server` keeps them on **one** lineage named after the primary domain:
+A custom-domain static site may have redirect aliases (e.g. `www.myblog.net`). `issueSiteCert(fqdn, aliases, email)` in `@lamalibre/lamaste@4.3.1/server` keeps them on **one** lineage named after the primary domain:
 
 ```bash
 sudo /usr/local/sbin/lamaste-certbot issue admin@example.com myblog.net myblog.net www.myblog.net

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

@@ -25,7 +25,7 @@ You encounter mTLS during two moments:
 
 ### Importing the certificate
 
-After running `npx @lamalibre/create-lamaste@4.2.0`, the installer prints something like:
+After running `npx @lamalibre/create-lamaste@4.3.1`, the installer prints something like:
 
 ```
 ╔══════════════════════════════════════════════════════════════╗
@@ -101,7 +101,7 @@ When connecting a machine to Lamaste using `lamaste-agent`, you should **not** u
 2. Click "Generate" and enter a label (e.g., `macbook-pro`)
 3. Save the displayed password — it cannot be retrieved later
 4. Download the `.p12` file
-5. Share the `.p12` file and password with the agent machine through a secure channel, then install the agent there (`npm install -g @lamalibre/lamaste-agent@4.2.0`) and run `lamaste-agent setup` (an enrollment token avoids moving the key at all — see [Agent Setup](../02-guides/agent-setup.md))
+5. Share the `.p12` file and password with the agent machine through a secure channel, then install the agent there (`npm install -g @lamalibre/lamaste-agent@4.3.1`) and run `lamaste-agent setup` (an enrollment token avoids moving the key at all — see [Agent Setup](../02-guides/agent-setup.md))
 
 Agent certificates have capability-based access. By default, a new agent can only read tunnel configuration. Admins can grant additional capabilities per-agent from the panel UI:
 

package/vendor/docs/01-concepts/nginx-reverse-proxy.md

@@ -253,9 +253,14 @@ server {
     location /internal/lamaste/authz {
         internal;
 
-        proxy_pass http://127.0.0.1:9294/authz/check;
+        # The tunnel is named in the path, and the same hostname in the headers —
+        # never $http_host, the client's Host header, which an absolute-form
+        # request line can set to another tunnel
+        proxy_pass http://127.0.0.1:9294/authz/tunnel/myapp.example.com;
         proxy_pass_request_body off;
-        # ... X-Original-URL, X-Original-Method, Cookie headers ...
+        proxy_set_header X-Original-URL https://myapp.example.com$request_uri;
+        proxy_set_header Host myapp.example.com;
+        # ... X-Original-Method, Cookie headers ...
     }
 
     location / {
@@ -289,7 +294,7 @@ server {
         proxy_send_timeout 86400s;
 
         # Not logged in -> Authelia portal
-        error_page 401 =302 https://auth.example.com/?rd=$scheme://$http_host$request_uri;
+        error_page 401 =302 https://auth.example.com/?rd=https://myapp.example.com$request_uri;
         # Restricted only: no grant -> Gatekeeper's access-request page
         error_page 403 = /internal/lamaste/authz;
     }