@cerefox/memory 1.19.6 → 1.21.0

package/dist/frontend/index.html

@@ -15,8 +15,9 @@
       href="https://fonts.googleapis.com/css2?family=Geist:wght@300;400;500;600;700&display=swap"
     />
     <title>Cerefox</title>
-    <script type="module" crossorigin src="/app/assets/index-lS0yMSGS.js"></script>
-    <link rel="stylesheet" crossorigin href="/app/assets/index-01k5C3sG.css">
+    <script type="module" crossorigin src="/app/assets/index-Dd1nIOAB.js"></script>
+    <link rel="modulepreload" crossorigin href="/app/assets/rolldown-runtime-COiEfhsA.js">
+    <link rel="stylesheet" crossorigin href="/app/assets/index-CV1iy1p2.css">
   </head>
   <body>
     <div id="root"></div>

package/dist/server-assets/_shared/ef-meta/index.ts

@@ -18,7 +18,7 @@
  * doesn't touch `supabase/functions/` leaves it alone).
  */
 
-export const EF_VERSION = "1.19.6";
+export const EF_VERSION = "1.21.0";
 
 /**
  * The Cerefox RELEASE version — what `cerefox --version` reports and what npm
@@ -36,7 +36,7 @@ export const EF_VERSION = "1.19.6";
  * is imported by the Deno Edge Functions, which cannot reach into the npm
  * package.
  */
-export const CEREFOX_VERSION = "1.19.6";
+export const CEREFOX_VERSION = "1.21.0";
 
 /**
  * The most recent version whose EF-side SOURCE actually changed (#127).

package/docs/guides/configuration.md

@@ -45,6 +45,7 @@ Full rule documented in [`docs/specs/polish-and-distribution-design.md` §7](../
 | `CEREFOX_DATABASE_URL` | `""` | For scripts | Direct Postgres URL for deployment scripts. **Use the Session Pooler** (port `5432`) — Transaction Pooler (`6543`) does not support DDL. Username must include the project-ref suffix (`postgres.<project-ref>`). Append `?sslmode=require`. See [`setup-supabase.md` → Connection pooling (2026)](setup-supabase.md#connection-pooling-2026). |
 | `CEREFOX_API_KEY` | `""` | Local web server (#229) | **Local API key** (`cfx_lak_…`) for `/api/v1` and `/rest/v1` on the machine running `cerefox web`. Callers on **loopback need no credential**; callers arriving on any other interface must send `Authorization: Bearer <key>`. Unset means the gate is off and the server behaves exactly as it did before v1.12.0 — so upgrading never breaks a working install. Minted by `cerefox api-key generate`; Cerefox Local mints its own at first boot (`cerefox-local api-key`). **Never sent to Supabase**; distinct from `CEREFOX_ACCESS_TOKEN`, which is the *cloud* credential for the Edge Functions. |
 | `CEREFOX_API_REQUIRE_KEY` | `""` | Local web server (#229) | Set to `1` to demand the API key from **every** caller, loopback included. The one topology that needs it: a same-host reverse proxy, which reconnects from `127.0.0.1`, so every proxied request would otherwise look local and be exempt. `X-Forwarded-For` is deliberately never consulted to recover the original address — it is caller-supplied, so trusting it would let anyone claim to be local. Has no effect when `CEREFOX_API_KEY` is unset (demanding a key that does not exist would lock you out of your own server). |
+| `CEREFOX_ALLOWED_HOSTS` | `""` | Local web server (v1.20.0) | Extra host names a request **without a key** may use to reach the server, comma-separated (`nas.local,cerefox`); `*` allows any. Without it, a keyless request must name the server by an IP address, `localhost` or `host.docker.internal`, which stops a web page from reaching it through DNS rebinding. Requests that present the key are not checked. See [`securing-local-access.md`](securing-local-access.md#web-pages-in-your-browser-v1200). |
 | `SUPABASE_ACCESS_TOKEN` | *(unset)* | For EF deploys (optional) | Supabase **personal access token** (`sbp_…`, from [supabase.com/dashboard/account/tokens](https://supabase.com/dashboard/account/tokens)), read by the **Supabase CLI** that `cerefox server deploy` shells out to for Edge Function deploys. Optional — without it the CLI falls back to its `supabase login` credential, which on **macOS lives in the Keychain and triggers a password dialog per function deploy** (9 per full deploy; a denied dialog fails that function with `LegacyPlatformAuthRequiredError`). Setting it in `~/.cerefox/.env` avoids the dialogs entirely: Cerefox exports every key from its `.env` to the environment, so the child CLI inherits it. Not a `CEREFOX_` variable — the name is the Supabase CLI's own. **Keep secret** (it grants management access to your Supabase account). |
 
 **When each is needed:**

package/docs/guides/securing-local-access.md

@@ -94,12 +94,43 @@ while making the common case worse for everyone. On a single-user machine,
 loopback access and key-file access are the same trust boundary, so the gate is
 drawn at the place where the trust actually changes: the network.
 
-This is also why **the browser never holds a key**. The web UI is a static
-file, so a key embedded in the page could be read by anything that can load the
-page — precisely the attacker the key exists to stop. A key in an
+This is also why **the browser holds no key on a local install**. The web UI is
+a static file, so a key embedded in the page could be read by anything that can
+load the page — precisely the attacker the key exists to stop. A key in an
 unauthenticated page is not a secret. The UI works because it is local, not
 because it holds a credential.
 
+**When the gate is on for the browser too** (a container published beyond
+loopback, `CEREFOX_API_REQUIRE_KEY=1`, a native server opened from another
+machine), the web UI asks for the key once, keeps it in that browser for that
+address only, and sends it like any other client (v1.20.0+). Nothing is ever
+embedded in the page; the key comes from you. Running Cerefox on another
+machine on your network is covered in [`setup-lan.md`](setup-lan.md).
+
+### Web pages in your browser (v1.20.0+)
+
+Trusting the machine has one catch: your browser is on the machine, and it runs
+pages from anywhere. So a request the server lets in **without a key** (from
+loopback, or with the gate off) also has to pass two browser checks:
+
+- **No cross-site requests.** A page from another site cannot post to Cerefox:
+  the server refuses a request the browser marks as cross-site
+  (`Sec-Fetch-Site`), or one whose `Origin` is neither this server nor a page
+  served from this machine. Agents, curl and the CLI send neither header, so
+  they are not affected.
+- **Only local names.** A keyless request must reach the server by an IP
+  address, `localhost`, or `host.docker.internal` (the `Host` header). This stops *DNS rebinding*, where
+  a page re-points its own domain name at `127.0.0.1` and reads your store as
+  if it were Cerefox. If you reach a gate-off server by a name on purpose (a
+  `.local` name, a Docker Compose service name), list it:
+
+  ```bash
+  CEREFOX_ALLOWED_HOSTS=nas.local,cerefox   # comma-separated; * turns the check off
+  ```
+
+Both refusals are a `403` whose message says which rule applied. A request
+that presents the key skips both checks: a foreign page cannot send one.
+
 ## Getting a key
 
 ### `cerefox web` (npm install)
@@ -171,9 +202,9 @@ KEY="cfx_lak_$(openssl rand -base64 32 | tr -d '=+/' | cut -c1-43)"
 { echo "CEREFOX_API_KEY=$KEY"; echo "CEREFOX_API_REQUIRE_KEY=1"; } >> ~/.cerefox/local/.env
 cerefox-local restart
 
-# Note: with the gate on, YOUR BROWSER needs the key too. If you use the web UI
-# daily, prefer leaving Cerefox published on loopback with the gate off and
-# giving your harness host networking instead.
+# Note: with the gate on, YOUR BROWSER needs the key too: the web UI asks for it
+# once (v1.20.0+). If you would rather not, leave Cerefox published on loopback
+# with the gate off and give your harness host networking instead.
 
 # 3. Give the same value to your client container, however it takes config.
 docker run -e CEREFOX_API_KEY="$KEY" … your-harness
@@ -203,8 +234,8 @@ The answer is to stop exempting loopback:
 CEREFOX_API_REQUIRE_KEY=1
 ```
 
-Now every caller presents the key, proxy included. Your browser will need it
-too, so this mode suits headless deployments rather than daily UI use.
+Now every caller presents the key, proxy included. The web UI asks for it once
+per browser (v1.20.0+).
 
 ## What this does not protect
 
@@ -239,6 +270,21 @@ a Docker network, not loopback. Give it the key (see the recipe above).
 That is the v1.12.0 bug, not a configuration problem. Run
 `cerefox-local upgrade` to get v1.12.1 or newer.
 
+**The web UI asks for an API key.** The server refused the browser, so the gate
+is on for it: paste the key (`cerefox api-key show`, `cerefox-local api-key`, or
+the `CEREFOX_API_KEY` you set). On v1.19.x and older the UI cannot send a key
+at all and a gated server is unusable from a browser; upgrade.
+
+**A `403` that says "a page from another site cannot use this server".** A web
+page tried to call Cerefox from another site. If it was a tool of yours, call
+the API from a script or give the tool the key; a browser page from another
+site is exactly what this refuses.
+
+**A `403` that says the server "was reached as" some name.** You reached a
+server with no key by a host name. Use `127.0.0.1` or `localhost`, add the name
+to `CEREFOX_ALLOWED_HOSTS` (in `~/.cerefox/local/.env` for Cerefox Local, then
+`cerefox-local restart`), or turn the key on.
+
 **`cerefox-local api-key` says no key was found.** The image predates v1.12.0.
 Run `cerefox-local upgrade`.
 

package/docs/guides/setup-cloud-run.md

@@ -9,6 +9,16 @@
 
 Deploy the Cerefox web UI to Google Cloud Run for a lightweight, serverless hosting option. This guide uses Supabase (free tier) for the database.
 
+> **v1.20.0 changed the image: it now requires `CEREFOX_API_KEY`.** The repo's
+> `Dockerfile` (the same one the published `cerefox-web` image is built from)
+> refuses to start without it, and turns the API key gate on for every caller.
+> Before v1.20.0 this guide deployed it `--allow-unauthenticated` with no key,
+> which left a Cerefox that can read and change your whole store open to the
+> internet. **If you deployed it that way, add the key (Step 3) before you
+> redeploy**, or the new revision will not start. If Cloud Run IAM or IAP
+> already controls access, `CEREFOX_WEB_NO_KEY=1` starts it without one. The
+> web UI asks for the key once per browser.
+
 > **Note:** The Cerefox web UI is the TypeScript server (`cerefox web` — Hono backend +
 > React/Mantine SPA); the Python/FastAPI app was removed at v1.0.0. The container `Dockerfile`
 > builds and serves the TS `cerefox web` server (port 8000).
@@ -56,6 +66,24 @@ gcloud builds submit --tag $IMAGE .
 
 ## Step 3 — Deploy to Cloud Run
 
+Keep the API key in Secret Manager rather than in a plain env var:
+
+```bash
+echo -n "cfx_lak_$(openssl rand -base64 32 | tr -d '=+/' | cut -c1-43)" | \
+  gcloud secrets create cerefox-api-key --data-file=-
+```
+
+Let the service read it. Cloud Run runs as the project's default compute
+service account unless you deployed with `--service-account`; grant that
+account access to this one secret, or the revision cannot start:
+
+```bash
+PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format='value(projectNumber)')
+gcloud secrets add-iam-policy-binding cerefox-api-key \
+  --member="serviceAccount:${PROJECT_NUMBER}-compute@developer.gserviceaccount.com" \
+  --role=roles/secretmanager.secretAccessor
+```
+
 ```bash
 gcloud run deploy $SERVICE_NAME \
   --image $IMAGE \
@@ -69,9 +97,13 @@ gcloud run deploy $SERVICE_NAME \
     CEREFOX_SUPABASE_URL=https://YOUR-REF.supabase.co,\
     CEREFOX_SUPABASE_KEY=YOUR-SERVICE-ROLE-KEY,\
     OPENAI_API_KEY=YOUR-OPENAI-KEY,\
-    CEREFOX_MAX_RESPONSE_BYTES=200000
+    CEREFOX_MAX_RESPONSE_BYTES=200000 \
+  --set-secrets CEREFOX_API_KEY=cerefox-api-key:latest
 ```
 
+Read the key back when the web UI asks for it:
+`gcloud secrets versions access latest --secret cerefox-api-key`.
+
 **Memory**: Cerefox uses cloud embeddings (OpenAI API) — no local model is loaded. `--memory 512Mi` is sufficient for the TS `cerefox web` server alone.
 
 **CPU**: `--cpu 1` is sufficient for personal use. Scale up for concurrent users.
@@ -84,7 +116,8 @@ gcloud run deploy $SERVICE_NAME \
 gcloud run services describe $SERVICE_NAME --region $REGION --format="value(status.url)"
 ```
 
-Open the printed URL — the Cerefox dashboard should load.
+Open the printed URL followed by `/app/`. The web UI asks for the API key once;
+then the dashboard loads.
 
 ---
 
@@ -95,9 +128,14 @@ After making code changes:
 ```bash
 docker build -t $IMAGE .
 docker push $IMAGE
-gcloud run deploy $SERVICE_NAME --image $IMAGE --region $REGION --platform managed
+gcloud run deploy $SERVICE_NAME --image $IMAGE --region $REGION --platform managed \
+  --set-secrets CEREFOX_API_KEY=cerefox-api-key:latest
 ```
 
+Upgrading a service deployed before v1.20.0 without a key: create the secret
+and grant the service account access to it (Step 3) first, or the new revision
+refuses to start.
+
 Cloud Run performs a zero-downtime rolling update.
 
 ---
@@ -112,19 +150,18 @@ all other deployment options. See `docs/guides/operational-cost.md` for a full b
 
 ## Securing access
 
-By default `--allow-unauthenticated` makes the URL public. To restrict access:
+`--allow-unauthenticated` makes the URL public; the API key is what protects it
+then. To also restrict who can reach it:
 
 ### Option 1 — Cloud Run IAM
 
-Remove `--allow-unauthenticated` and use `gcloud run services add-iam-policy-binding` to add specific Google accounts.
+Remove `--allow-unauthenticated` and use `gcloud run services add-iam-policy-binding` to add specific Google accounts. IAM reads the `Authorization` header itself, so with IAM set `CEREFOX_WEB_NO_KEY=1` instead of a key.
 
 ### Option 2 — Cloud Run proxy
 
 Use Identity-Aware Proxy (IAP) in front of Cloud Run for Google SSO.
 
-### Option 3 — Add HTTP basic auth
-
-Add a Hono middleware to the TS `cerefox web` server that checks `Authorization: Basic ...`
-headers, using `CEREFOX_BASIC_AUTH_USER` / `CEREFOX_BASIC_AUTH_PASSWORD` env vars
-(implement it against the current TS `cerefox web` server's middleware hook).
+The API key (v1.20.0) replaces the "add HTTP basic auth" option this guide used
+to suggest: both would need the `Authorization` header, and the key is already
+built in.
 

package/docs/guides/setup-lan.md

@@ -0,0 +1,220 @@
+# Running Cerefox on another machine on your network
+
+Run Cerefox on an always-on machine on your home or office network (a NAS, a
+mini PC, a home server) and use it from your other machines: agents, the CLI,
+and the web UI in a browser. Requires **v1.20.0 or newer**.
+
+There are two ways to do it, and they do not depend on each other:
+
+| | What runs on the LAN host | Where the data lives | Image |
+|---|---|---|---|
+| **A. Cerefox Local** | Everything: database, server, web UI | On the LAN host | `ghcr.io/fstamatelopoulos/cerefox-local` |
+| **B. Web container** | The server and web UI | Your Supabase project | `ghcr.io/fstamatelopoulos/cerefox-web` |
+
+Pick **A** if you want the data at home and no cloud database. Pick **B** if you
+already run Cerefox on Supabase and want the web UI (and the `/api/v1` API)
+served from your network instead of from your laptop.
+
+## The one rule: the API key gate is on
+
+On your laptop, Cerefox trusts connections that start on the same machine and
+needs no key. **On a LAN host that rule cannot apply.** Inside a container every
+caller looks remote, because Docker rewrites the source address of every
+request that comes through a published port, so the container cannot tell your
+laptop apart from any other device on the network. Without a key, anything that
+can reach the port can read, change and delete the whole store.
+
+So both setups turn the gate on for every caller (`CEREFOX_API_REQUIRE_KEY=1`)
+and use a key you choose. Make one now and keep it somewhere safe, such as your
+password manager:
+
+```bash
+echo "cfx_lak_$(openssl rand -base64 32 | tr -d '=+/' | cut -c1-43)"
+```
+
+Every client then presents it as `Authorization: Bearer <key>`. **The web UI
+asks for it once per browser** (see [Using the web UI](#using-the-web-ui)).
+
+## A. Cerefox Local on a LAN host
+
+The same all-in-one image the [local install](setup-local.md) uses, run directly
+with Docker instead of through `cerefox-local`.
+
+### With `docker run`
+
+```bash
+docker run -d --name cerefox --restart unless-stopped \
+  -p 8000:8000 \
+  -v /path/on/host/cerefox-db:/var/lib/postgresql/data \
+  -e CEREFOX_API_REQUIRE_KEY=1 \
+  -e CEREFOX_API_KEY=cfx_lak_YOUR-KEY \
+  -e CEREFOX_EMBEDDER=openai \
+  -e OPENAI_API_KEY=YOUR-OPENAI-KEY \
+  --memory 2g \
+  ghcr.io/fstamatelopoulos/cerefox-local:v1.20.0
+```
+
+- **The data folder** (`/path/on/host/cerefox-db`) holds the database. Deleting
+  or recreating the container keeps it, which is how you upgrade.
+- **Publish only port 8000.** Postgres (5432) and PostgREST (3000) stay inside
+  the container; do not publish them.
+- **`CEREFOX_API_KEY`** sets the key. Without it the container mints one on
+  first boot and keeps it in the data folder; you can read that one with
+  `docker exec cerefox cat /var/lib/postgresql/data/.cerefox_api_key`. Setting
+  it yourself is easier on hosts whose Docker app gives you no shell.
+- **Embeddings:** `CEREFOX_EMBEDDER=openai` with your key, or
+  `CEREFOX_EMBEDDER=local` for the bundled offline model (no API key, needs more
+  memory; see [`setup-local.md`](setup-local.md) for the figures).
+- **Memory:** 2 GB is comfortable with OpenAI embeddings.
+
+### With a compose file (or a NAS Docker app)
+
+Most NAS Docker apps (Synology Container Manager, QNAP Container Station,
+Unraid, Portainer) accept a compose file as a "project" or "stack". Use one:
+an upgrade is then a one-line change to the image tag.
+
+```yaml
+services:
+  cerefox:
+    image: ghcr.io/fstamatelopoulos/cerefox-local:v1.20.0
+    container_name: cerefox
+    restart: unless-stopped
+    ports:
+      - "8000:8000"
+    volumes:
+      - /path/on/host/cerefox-db:/var/lib/postgresql/data
+    environment:
+      CEREFOX_API_REQUIRE_KEY: "1"
+      CEREFOX_API_KEY: "cfx_lak_YOUR-KEY"
+      CEREFOX_EMBEDDER: openai
+      OPENAI_API_KEY: "YOUR-OPENAI-KEY"
+    mem_limit: 2g
+```
+
+The compose file holds both keys, so treat it as a secret. Give the project its
+own folder, never the data folder.
+
+Set only the variables above. The image's own variables (`PGDATA`,
+`POSTGRES_*`, `CEREFOX_DATABASE_URL`, `CEREFOX_SUPABASE_URL`,
+`CEREFOX_POSTGREST_UPSTREAM`, `PGRST_*`, `CEREFOX_MODELS_DIR`) are defaults
+baked into it; some Docker apps display them, but do not change them.
+
+### If the host cannot pull the image
+
+Some NAS Docker apps fail to pull from `ghcr.io` (for example "registry returned
+bad result"). Pull it on another machine and copy it over as a file. Most NAS
+hosts are x86-64, so ask for `linux/amd64` explicitly when the other machine is
+an Apple Silicon Mac:
+
+```bash
+docker pull --platform linux/amd64 ghcr.io/fstamatelopoulos/cerefox-local:v1.20.0
+docker save ghcr.io/fstamatelopoulos/cerefox-local:v1.20.0 -o cerefox-local-v1.20.0-amd64.tar
+```
+
+Then import the `.tar` in the Docker app (usually Image → Add → From file). Keep
+the `image:` line exactly as the imported name and tag, or the app will try to
+pull again.
+
+### Upgrading
+
+Change the tag (and import the new `.tar` first if the host cannot pull), then
+recreate the container. The data folder carries the database and, if you let the
+container mint it, the key. Cerefox Local applies pending schema migrations on
+boot.
+
+## B. The web container, with your Supabase backend
+
+You need a working Supabase-backed Cerefox first (see
+[`setup-supabase.md`](setup-supabase.md)): the schema, RPCs and Edge Functions
+are deployed by `cerefox server deploy`, not by this image.
+
+```bash
+docker run -d --name cerefox-web --restart unless-stopped \
+  -p 8000:8000 \
+  -e CEREFOX_SUPABASE_URL=https://YOUR-REF.supabase.co \
+  -e CEREFOX_SUPABASE_KEY=YOUR-SECRET-KEY \
+  -e OPENAI_API_KEY=YOUR-OPENAI-KEY \
+  -e CEREFOX_API_KEY=cfx_lak_YOUR-KEY \
+  ghcr.io/fstamatelopoulos/cerefox-web:v1.20.0
+```
+
+- **The image refuses to start without `CEREFOX_API_KEY`** and turns the gate
+  on for every caller. It holds your Supabase secret key, so an open container
+  on the network would hand out full access to your cloud store.
+- **`CEREFOX_WEB_NO_KEY=1`** starts it without a key. Use it only when
+  something in front of the container already controls who can reach it (an
+  authenticating proxy, Cloud Run IAM). It logs a warning at every start, and
+  sets `CEREFOX_ALLOWED_HOSTS=*` unless you set it, since the container is then
+  reached by the proxy's host name.
+- The image runs as an unprivileged user and has a healthcheck that uses the
+  key from its own environment.
+- The local offline embedder is not included: it runs only in Cerefox Local.
+
+## Using it from your other machines
+
+Use the host's address and the published port, for example
+`http://192.168.1.20:8000`.
+
+```bash
+KEY=cfx_lak_YOUR-KEY; HOST=http://192.168.1.20:8000
+curl -s -o /dev/null -w '%{http_code}\n' "$HOST/api/v1/projects"                              # 401
+curl -s -o /dev/null -w '%{http_code}\n' -H "Authorization: Bearer $KEY" "$HOST/api/v1/projects"  # 200
+```
+
+**Check `/api/v1/projects`, not `/api/v1/version`.** The version route never
+touches the database, so it answers even when the data path is broken. (From
+v1.12.1 to v1.19.5 a gated Cerefox Local container answered `version` while
+every data route failed; fixed in v1.19.6.)
+
+The HTTP API is documented in [`api.md`](api.md).
+
+### Using the web UI
+
+Open `http://<host>:<port>/app/`. The page loads, the server refuses its first
+call, and the UI asks for the key:
+
+- **Paste the key** and press Continue. The UI checks it with the server before
+  keeping it, so a mistyped key is refused in the dialog.
+- **"Remember on this browser"** keeps it in the browser's local storage for
+  this address. Unticked, it lasts until the tab closes.
+- **The key-off icon** in the header forgets it. So does a key the server stops
+  accepting (rotated, or the container recreated with a new one): the UI says
+  the saved key was not accepted and asks again.
+
+The key is kept per address and port, so other apps on the same host cannot
+read it. It is readable by scripts running in the Cerefox page itself; the page
+renders documents without raw HTML, and the project's tests fail on any change
+that would let a document inject script.
+
+## What this does not protect
+
+**Traffic on the wire.** Plain `http://` on your network sends the key, and
+everything else, unencrypted. That is usually acceptable on a home network you
+control; it is not on a shared one. For TLS, put a reverse proxy in front (see
+[`securing-local-access.md`](securing-local-access.md#recipe-a-reverse-proxy-on-the-same-machine));
+the gate stays on, since a proxy makes every request look local.
+
+**The internet.** Do not forward the port from your router. These setups are
+for your own network.
+
+**Anyone with the key**, or with access to the host's files, the data folder or
+the compose file.
+
+## Troubleshooting
+
+**Nothing answers on the port.** Check which host port is actually published in
+your Docker app; the container may be running on a different one than you
+planned.
+
+**Every data route returns 500 with the key, but `/version` works.** The image
+is older than v1.19.6. Upgrade.
+
+**The web UI shows a white page or keeps failing after the key.** The image is
+older than v1.20.0, which is the first version whose web UI can send a key.
+
+**The container exits right away (web container).** Read its log: it refuses
+to start without `CEREFOX_API_KEY` and says so.
+
+**A markdown image in a document does not load.** An image whose address is a
+`/api/v1/…` path is fetched by the browser without the key. Links work; images
+from the API do not.

package/docs/guides/setup-local.md

@@ -10,6 +10,10 @@ Cerefox web server. You get the same web UI, CLI, and MCP server as the cloud se
 > container, fully offline, no API key. See
 > [Choose your embedder](#choose-your-embedder-openai-vs-fully-local).
 
+> **On another machine on your network?** To run this image on a NAS or a home
+> server and use it from your other machines (browser included), follow
+> [`setup-lan.md`](setup-lan.md) instead of the installer below.
+
 ## Cloud vs. Local — pick one
 
 Cerefox has two independent "worlds". Most people run **one or the other**:

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@cerefox/memory",
-  "version": "1.19.6",
+  "version": "1.21.0",
   "description": "Cerefox \u2014 user-owned shared memory for AI agents. CLI + stdio MCP server + web UI + ingestion for a knowledge base on your own Supabase project (or fully self-hosted with Cerefox Local).",
   "license": "Apache-2.0",
   "homepage": "https://github.com/fstamatelopoulos/cerefox",
@@ -58,7 +58,7 @@
     "onnxruntime-node": "^1.21.0"
   },
   "devDependencies": {
-    "@types/bun": "^1.4.3",
+    "@types/bun": "^1.4.4",
     "@types/cli-progress": "^3.11.5",
     "@types/node": "^24.19.2",
     "@types/prompts": "^2.4.9",