@lamalibre/create-lamaste 4.0.0 → 4.1.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lamalibre/create-lamaste",
-  "version": "4.0.0",
+  "version": "4.1.0",
   "description": "One-command setup for secure reverse tunnels with a management dashboard",
   "type": "module",
   "license": "SEE LICENSE IN LICENSE.md",
@@ -43,7 +43,7 @@
     "mtls"
   ],
   "dependencies": {
-    "@lamalibre/lamaste": "^4.0.0",
+    "@lamalibre/lamaste": "^4.1.0",
     "chalk": "^5.3.0",
     "execa": "^9.0.0",
     "listr2": "^8.0.0"

package/scripts/lamaste-priv

@@ -46,6 +46,17 @@ const MAX_VHOST_BYTES = 256 * 1024;
 const AUTHELIA_BIN = '/usr/local/bin/authelia';
 const AUTHELIA_CONFIG = '/etc/authelia/configuration.yml';
 const AUTHELIA_USER = 'lamaste-authelia';
+/**
+ * Environment of every `authelia` CLI run. The configuration is a Go
+ * template (it reads the OIDC issuer key with `{{ secret "…" }}`), so the
+ * CLI needs the same filter the service unit sets, or it fails to parse
+ * the file once an OIDC provider is configured.
+ */
+const AUTHELIA_CLI_ENV = Object.freeze({
+  PATH: '/usr/bin:/bin',
+  HOME: '/nonexistent',
+  X_AUTHELIA_CONFIG_FILTERS: 'template',
+});
 
 const SYSTEMD_RUN = '/usr/bin/systemd-run';
 const NPX = '/usr/bin/npx';
@@ -604,7 +615,7 @@ function autheliaTotp(username) {
       uid,
       gid,
       cwd: '/',
-      env: { PATH: '/usr/bin:/bin', HOME: '/nonexistent' },
+      env: { ...AUTHELIA_CLI_ENV },
       encoding: 'utf8',
       timeout: 60_000,
     },
@@ -689,5 +700,13 @@ if (require.main === module) {
     process.exit(err instanceof UsageError ? 2 : 1);
   }
 } else {
-  module.exports = { validateVhost, tokenize, parse, assertSiteName, PANEL_SITE_RE, UsageError };
+  module.exports = {
+    validateVhost,
+    tokenize,
+    parse,
+    assertSiteName,
+    PANEL_SITE_RE,
+    UsageError,
+    AUTHELIA_CLI_ENV,
+  };
 }

package/src/lib/oidc-issuer-key.js

@@ -0,0 +1,124 @@
+import { execa } from 'execa';
+import crypto from 'node:crypto';
+import { lstat } from 'node:fs/promises';
+import { join } from 'node:path';
+import { AUTHELIA_CONFIG_DIR, AUTHELIA_OIDC_KEY_PATH } from './service-config.js';
+import { setFileOwnership } from './ownership.js';
+
+/**
+ * The RSA key Authelia signs OpenID Connect tokens with.
+ *
+ * Generated here — by create-lamaste, on a fresh install and on every
+ * redeploy that finds it missing — rather than by the panel, so the panel
+ * never holds the key that mints identities: the file is 0600 and owned by
+ * the Authelia account, which is the only process that reads it. Authelia's
+ * configuration references it with a `{{ secret "…" }}` template expression
+ * (its unit sets `X_AUTHELIA_CONFIG_FILTERS=template`).
+ *
+ * `/etc/authelia` belongs to the lamaste user (the panel writes Authelia's
+ * configuration there), so root never writes through that path: the key is
+ * generated in this process and handed to a child running as the Authelia
+ * account, which creates the file (`wx`, 0600) and renames it into place.
+ * A symlink the panel could plant at the key's name is replaced by the
+ * rename, never followed.
+ */
+
+const RSA_MODULUS_BITS = 4096;
+
+/**
+ * Child-side writer: content on stdin, destination as the last argument.
+ * Runs as the Authelia user with its own umask; the file is created with
+ * `wx` so an existing file is never truncated or followed.
+ */
+export const PRIVATE_FILE_WRITER = `
+const fs = require('node:fs');
+const dest = process.argv[process.argv.length - 1];
+const content = fs.readFileSync(0, 'utf8');
+if (!content.includes('PRIVATE KEY')) { process.stderr.write('not a private key\\n'); process.exit(3); }
+const tmp = dest + '.' + process.pid + '.tmp';
+const fd = fs.openSync(tmp, 'wx', 0o600);
+try {
+  fs.writeFileSync(fd, content);
+  fs.fsyncSync(fd);
+} finally {
+  fs.closeSync(fd);
+}
+fs.renameSync(tmp, dest);
+`;
+
+/** A fresh RSA-4096 private key as PKCS#8 PEM. */
+export function generateIssuerKeyPem() {
+  const { privateKey } = crypto.generateKeyPairSync('rsa', { modulusLength: RSA_MODULUS_BITS });
+  return privateKey.export({ type: 'pkcs8', format: 'pem' }).toString();
+}
+
+/**
+ * Write `pem` to `dest` as `uid:gid` 0600 through a child process running
+ * as that account. Root touches nothing under the destination's directory.
+ *
+ * @param {string} dest
+ * @param {string} pem
+ * @param {{ uid: number, gid: number }} ids
+ */
+export async function writePrivateKeyAs(dest, pem, { uid, gid }) {
+  await execa(process.execPath, ['-e', PRIVATE_FILE_WRITER, dest], {
+    uid,
+    gid,
+    input: pem,
+    cwd: '/',
+    env: { PATH: '/usr/bin:/bin' },
+    extendEnv: false,
+    timeout: 30_000,
+  });
+}
+
+/**
+ * Make sure the issuer key exists as `autheliaUid:autheliaGid` 0600.
+ *
+ * - Missing: generate and write it.
+ * - A regular file owned by the Authelia account: fix the mode through a
+ *   descriptor if it drifted; keep the key (tokens stay valid).
+ * - Anything else (another owner, a symlink): replace it — a key the panel
+ *   wrote is a key the panel knows.
+ *
+ * @param {{ autheliaUid: number, autheliaGid: number, dir?: string, report?: (line: string) => void }} options
+ * @returns {Promise<{ generated: boolean, path: string }>}
+ */
+export async function ensureOidcIssuerKey({
+  autheliaUid,
+  autheliaGid,
+  dir = AUTHELIA_CONFIG_DIR,
+  report = () => {},
+}) {
+  const keyPath =
+    dir === AUTHELIA_CONFIG_DIR ? AUTHELIA_OIDC_KEY_PATH : join(dir, 'oidc-issuer.pem');
+
+  let st = null;
+  try {
+    st = await lstat(keyPath);
+  } catch (err) {
+    if (err.code !== 'ENOENT') throw err;
+  }
+
+  if (st && st.isFile() && st.uid === autheliaUid) {
+    if (st.gid !== autheliaGid || (st.mode & 0o7777) !== 0o600) {
+      report('Fixing the ownership of the OIDC issuer key...');
+      await setFileOwnership(keyPath, { uid: autheliaUid, gid: autheliaGid, mode: 0o600 });
+    }
+    return { generated: false, path: keyPath };
+  }
+
+  report(
+    st
+      ? 'Replacing the OIDC issuer key (not owned by the Authelia account)...'
+      : 'Generating the OIDC issuer key (RSA 4096)...',
+  );
+  const pem = generateIssuerKeyPem();
+  await writePrivateKeyAs(keyPath, pem, { uid: autheliaUid, gid: autheliaGid });
+
+  const after = await lstat(keyPath);
+  if (!after.isFile() || after.uid !== autheliaUid || (after.mode & 0o7777) !== 0o600) {
+    throw new Error(`${keyPath} was not written as the Authelia account with mode 0600`);
+  }
+  return { generated: true, path: keyPath };
+}

package/src/lib/relay-services.js

@@ -2,6 +2,7 @@ import { readFile, writeFile } from 'node:fs/promises';
 import { join } from 'node:path';
 import { ensureAutheliaUser, ensureChiselGroup, lookupId } from './accounts.js';
 import { installPinnedAuthelia, installPinnedChisel } from './binaries.js';
+import { ensureOidcIssuerKey } from './oidc-issuer-key.js';
 import {
   chownTree,
   ensureDirectory,
@@ -79,6 +80,9 @@ export async function provisionRelayServices(ctx, report) {
   });
   await ensureDirectory(AUTHELIA_LOG_DIR, { uid: autheliaUid, gid: autheliaGid, mode: 0o750 });
   await chownTree(AUTHELIA_LOG_DIR, `${autheliaUid}:${autheliaGid}`);
+  // The OIDC issuer key: Authelia's alone, generated here so the panel —
+  // which writes the configuration that references it — never holds it.
+  await ensureOidcIssuerKey({ autheliaUid, autheliaGid, report });
   // chisel runs as nobody:lamaste-chisel; the panel creates the key (as
   // lamaste, group lamaste-chisel). Earlier versions made it nobody:nogroup 0400.
   await setFileOwnership(join(ctx.configDir, 'chisel-server.key'), {

package/src/lib/service-config.js

@@ -24,6 +24,12 @@ WorkingDirectory=${ctx.installDir}/serverd
 ExecStart=/usr/bin/node src/index.js
 Environment=NODE_ENV=production
 Environment=CONFIG_FILE=${ctx.configDir}/panel.json
+# The service account has no home directory (useradd --no-create-home) and
+# ProtectHome hides /home anyway. npm, which the panel runs to install
+# plugins, needs a writable cache and HOME: both live in the state directory,
+# the same convention as lamaste-server plugins (runAsLamaste).
+Environment=HOME=${ctx.configDir}
+Environment=npm_config_cache=${ctx.configDir}/.npm
 Restart=always
 RestartSec=5
 StandardOutput=journal
@@ -187,6 +193,15 @@ export const AUTHELIA_BIN = '/usr/local/bin/authelia';
 export const CHISEL_UNIT_PATH = '/etc/systemd/system/chisel.service';
 export const AUTHELIA_UNIT_PATH = '/etc/systemd/system/authelia.service';
 export const AUTHELIA_CONFIG_DIR = '/etc/authelia';
+/** RSA key Authelia signs OpenID Connect tokens with (0600, the Authelia account; see lib/oidc-issuer-key.js). */
+export const AUTHELIA_OIDC_KEY_PATH = `${AUTHELIA_CONFIG_DIR}/oidc-issuer.pem`;
+/**
+ * Authelia's configuration is rendered as a Go template: that is how it
+ * reads the OIDC issuer key (`{{ secret "…" }}`) without the panel, which
+ * writes the configuration, ever holding the key. Set on the unit and on
+ * every `authelia` CLI invocation (lamaste-priv authelia-totp).
+ */
+export const AUTHELIA_CONFIG_FILTERS_ENV = 'X_AUTHELIA_CONFIG_FILTERS=template';
 export const AUTHELIA_LOG_DIR = '/var/log/authelia';
 export const WEB_ROOT = '/var/www/lamaste';
 
@@ -257,6 +272,7 @@ User=${AUTHELIA_USER}
 Group=${AUTHELIA_USER}
 UMask=027
 Environment=AUTHELIA_SERVER_DISABLE_HEALTHCHECK=true
+Environment=${AUTHELIA_CONFIG_FILTERS_ENV}
 ExecStart=${AUTHELIA_BIN} --config ${AUTHELIA_CONFIG_DIR}/configuration.yml
 Restart=always
 RestartSec=5

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.0.0
+npx @lamalibre/create-lamaste@4.1.0
 ```
 
 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.0.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.1.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.
 
 **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.0.0
+npx @lamalibre/create-lamaste@4.1.0
 ```
 
 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.0.0
+npx @lamalibre/create-lamaste-desktop@4.1.0
 ```
 
 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.0.0
+npm install -g @lamalibre/lamaste-agent@4.1.0
 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.0.0 [flags]
+npx @lamalibre/create-lamaste@4.1.0 [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.0.0
+npx @lamalibre/create-lamaste@4.1.0
 
 # 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.0.0`
+2. SSH in once and run `npx @lamalibre/create-lamaste@4.1.0`
 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.0.0`)
+1. Install the desktop app (`npx @lamalibre/create-lamaste-desktop@4.1.0`)
 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.0.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.1.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.
 
 ## Quick Reference
 
 | Item                 | Value                           |
 | -------------------- | ------------------------------- |
 | **Minimum VPS**      | 512MB RAM, Ubuntu 24.04         |
-| **Install command**  | `npx @lamalibre/create-lamaste@4.0.0` |
+| **Install command**  | `npx @lamalibre/create-lamaste@4.1.0` |
 | **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.0.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.0.0`     |
+| **npm package**      | `@lamalibre/create-lamaste@4.1.0`     |
 | **License**          | Polyform Noncommercial 1.0.0    |

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

@@ -371,7 +371,51 @@ Authelia requires three secrets, all generated with `crypto.randomBytes`:
 | `sessionSecret`        | Encrypts session cookies | `/etc/authelia/configuration.yml` |
 | `storageEncryptionKey` | Encrypts SQLite database | `/etc/authelia/configuration.yml` |
 
-A copy is also stored in `/etc/authelia/.secrets.json` (mode `600`) for reference. The configuration file itself is mode `600` to prevent unauthorized reading of these secrets.
+A copy is also stored in `/etc/authelia/.secrets.json` (mode `600`) for reference. The configuration file itself is mode `600` to prevent unauthorized reading of these secrets. When an OpenID Connect provider is configured (below), `.secrets.json` also holds `oidcHmacSecret`.
+
+### OpenID Connect provider
+
+Authelia is also the relay's OpenID Connect provider, at `https://auth.<domain>` (`/.well-known/openid-configuration`, `/jwks.json`, `/api/oidc/token`, `/api/oidc/device-authorization`, `/api/oidc/userinfo` — all served by the auth vhost's plain proxy location, without forward auth). The clients come from two places: every enabled plugin's manifest (`oidcClients` — e.g. Feria's `feria-cli`, a public device-code client so `feria login` authenticates through the relay) and the panel itself (`lamaste-server`, a confidential client-credentials client, when the registry credential uses `auth.kind: oidc`). The panel rewrites `identity_providers.oidc` after every plugin lifecycle change and every registry-credential change, restarting Authelia only when the section actually changed, and removes the section when no client is left (Authelia refuses an `oidc` section without clients).
+
+```yaml
+identity_providers:
+  oidc:
+    hmac_secret: <random-64-byte-hex>
+    jwks:
+      - key_id: lamaste-oidc
+        algorithm: RS256
+        use: sig
+        key: { { secret "/etc/authelia/oidc-issuer.pem" | mindent 10 "|" | msquote } }
+    lifespans:
+      device_code: 10 minutes
+    claims_policies:
+      feria-cli:
+        access_token:
+          - groups
+          - preferred_username
+    clients:
+      - client_id: feria-cli
+        client_name: Feria CLI
+        public: true
+        authorization_policy: two_factor
+        consent_mode: explicit
+        scopes: [openid, profile, groups]
+        grant_types: ['urn:ietf:params:oauth:grant-type:device_code']
+        token_endpoint_auth_method: none
+        access_token_signed_response_alg: RS256
+        requested_audience_mode: explicit
+        claims_policy: feria-cli
+        audience: ['https://feria.example.com']
+```
+
+Key choices:
+
+- **The issuer key is Authelia's alone.** `/etc/authelia/oidc-issuer.pem` (RSA 4096) is generated by `create-lamaste` as the `lamaste-authelia` account, mode `0600`. The panel, which writes the configuration, cannot read it: the configuration carries a template expression instead of the key, and Authelia's unit (and `lamaste-priv authelia-totp`, which runs Authelia's CLI) sets `X_AUTHELIA_CONFIG_FILTERS=template` so Authelia expands it at load time. Because the whole file is then a Go template, the panel refuses to write any value containing `{{` or `}}`. The panel reads the file back by swapping that one line for a placeholder before parsing it as YAML.
+- **JWT access tokens.** `access_token_signed_response_alg: RS256` makes access tokens RFC 9068 JWTs a resource server (Feria) verifies against `/jwks.json`. `groups` and `preferred_username` are UserInfo claims by default; the per-client **claims policy** copies them into the access token when the client declares `accessTokenClaims` — only for claims whose scope was granted.
+- **Confidential clients** carry a pbkdf2-sha512 digest of their secret (`$pbkdf2-sha512$310000$<salt>$<key>`, salt and key in go-crypt's adapted base64: `+` written as `.`, no padding). The panel generates the secret, keeps the plaintext in `/etc/lamalibre/lamaste/oidc-clients.json` (0600), and shows it once.
+- **Client credentials.** For the panel's own `lamaste-server` client Authelia sets both `sub` and `client_id` to the client id (there is no end user), which is also why such a client must have `authorization_policy: one_factor` and no `openid`/`offline_access` scope — Authelia refuses the configuration otherwise. The panel calls the token endpoint on `127.0.0.1:9091` with `X-Forwarded-Proto: https` and `X-Forwarded-Host: auth.<domain>`, which is where Authelia takes the issuer from, so the JWT says `iss: https://auth.<domain>` exactly as through nginx.
+
+See [Registry Credential and OIDC Clients](../04-api-reference/registry-and-oidc.md) for the manifest fields and the API.
 
 ### Safety rule: never delete the last user
 

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.0.0` installation
+- **Self-signed + mTLS certs** — created during `npx @lamalibre/create-lamaste@4.1.0` 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.0.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.1.0/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.0.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.1.0/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.0.0`, the installer prints something like:
+After running `npx @lamalibre/create-lamaste@4.1.0`, 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.0.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.1.0`) 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/tickets.md

@@ -264,9 +264,9 @@ The integration flow:
 }
 ```
 
-### Client SDK (`@lamalibre/lamaste-tickets@4.0.0`)
+### Client SDK (`@lamalibre/lamaste-tickets@4.1.0`)
 
-The `@lamalibre/lamaste-tickets@4.0.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.1.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 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.0.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.1.0/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.0.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.1.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.
 
 ### 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.0.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.0.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.1.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.1.0`'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.0.0
+npm install -g @lamalibre/lamaste-agent@4.1.0
 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.0.0
+npm install -g @lamalibre/lamaste-agent@4.1.0
 ```
 
 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.
@@ -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.0.0
+npm install -g @lamalibre/lamaste-agent@4.1.0
 lamaste-agent update
 ```
 
@@ -171,7 +171,7 @@ lamaste-agent uninstall --label <l>  # stop and remove one agent, including its
 
 | 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.0.0`, then `lamaste-agent setup ...` again. The enrollment token was not spent.                                                                              |
+| `setup` says the agent must be installed globally           | It was run through `npx`. Run `npm install -g @lamalibre/lamaste-agent@4.1.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.         |

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.0.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.1.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.
 
 ### 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.0.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.1.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.
 
 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.0.0` ([setup guide](desktop-app-setup.md))                                                                                     |
+| **Desktop app installed** | `npx @lamalibre/create-lamaste-desktop@4.1.0` ([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,7 +221,7 @@ 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.0.0` on the droplet (up to 10 minutes)                                      |
+| **Installing Lamaste**          | Runs `npx @lamalibre/create-lamaste@4.1.0` on the droplet (up to 10 minutes)                                      |
 | **Retrieving credentials**      | Downloads the admin certificate (`.p12` file) 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`                                              |
@@ -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.0.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.1.0`) or by importing a certificate manually.
 
 ---