Deploy: make the NAS GUI path work, and stop sourcing the env file

Synology Container Manager and QNAP Container Station build a project from a
folder and look for `docker-compose.yml` in it. Pointing either at `docker/`
finds the DEV service stack and starts the wrong thing, so production now has
a root-level entry point.

- docker-compose.yml at the repo root: `include`s the prod stack (relative
  paths resolve against the included file's directory, so the build context
  and backup.sh still resolve) and pins `name: webmail-prod`. A project name
  typed into the GUI overrides the file's, so the docs say to type the same
  one.
- webmail.sh init now drops a `.env` symlink to docker/.env.prod in the repo
  root: the GUI reads `.env` from the project folder, and a symlink keeps one
  file to edit instead of two copies that drift.
- Required-variable guards on DATA_ROOT / MASTER_KEY / POSTGRES_PASSWORD /
  APP_DOMAIN. A bare `docker compose up` with no env file used to interpolate
  DATA_ROOT to "" and bind-mount /postgres at the root of the filesystem; it
  now aborts with a message naming the variable.
- require_env no longer sources the env file. Sourcing executed it as shell:
  ENABLED_PLUGINS=calendar contacts labels filters ran `contacts` as a command
  and broke every subcommand, and anything else in the file that holds the
  master key would have been executed too. Replaced with a compose-compatible
  KEY=VALUE parser; the template quotes the value as well.
- doctor: no longer aborts on a not-yet-created DATA_ROOT (set -e + pipefail
  killed it inside a `df` assignment — on exactly the pre-install run where
  its NFS/SMB check is the one that matters), and probes the nearest existing
  ancestor so that check works before the directory exists.
- docs §2.5 rewritten with what the GUI can and cannot do: no compose
  profiles (so no Meilisearch), no health-gated update, no restore; plus the
  Task Scheduler route for generating MASTER_KEY without enabling SSH, and
  why init/migrate showing "Exited (0)" is correct.

Verified by running `docker compose up -d --wait` from the repo root with no
-f and no --env-file (what the GUI does): all services healthy, migrations
applied, app served, and deploy/webmail.sh manages the same project.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Nux3LCu4zP9nih4BRhPyHw

.gitignore

@@ -2,6 +2,7 @@
 .env.dev
 docker/.env.prod
 docker/.env
+/.env
 .env.*.local
 gitea-server-credentials.md
 

deploy/webmail.sh

@@ -35,10 +35,30 @@ compose() {
     docker compose --env-file "$ENV_FILE" -f "$COMPOSE_FILE" "$@"
 }
 
+# Read KEY=VALUE pairs the way compose's .env parser does, WITHOUT sourcing.
+# Sourcing would execute the file as shell — it would choke on an ordinary
+# value containing spaces (ENABLED_PLUGINS) and would run anything else that
+# found its way into the file that holds the master key.
+load_env_file() {
+    local line key val
+    while IFS= read -r line || [ -n "$line" ]; do
+        case "$line" in ''|'#'*) continue ;; esac
+        case "$line" in *=*) ;; *) continue ;; esac
+        key="${line%%=*}"
+        val="${line#*=}"
+        # Trim whitespace around the key; strip one layer of surrounding quotes.
+        key="$(printf '%s' "$key" | tr -d '[:space:]')"
+        case "$val" in
+            \"*\") val="${val#\"}"; val="${val%\"}" ;;
+            \'*\') val="${val#\'}"; val="${val%\'}" ;;
+        esac
+        [ -n "$key" ] && export "${key}=${val}"
+    done < "$1"
+}
+
 require_env() {
     [ -f "$ENV_FILE" ] || die "$ENV_FILE not found. Run: ./deploy/webmail.sh init"
-    # shellcheck disable=SC1090
+    load_env_file "$ENV_FILE"
-    set -a; . "$ENV_FILE"; set +a
     [ -n "${DATA_ROOT:-}" ]         || die "DATA_ROOT is not set in $ENV_FILE"
     [ -n "${MASTER_KEY:-}" ]        || die "MASTER_KEY is not set in $ENV_FILE"
     [ -n "${POSTGRES_PASSWORD:-}" ] || die "POSTGRES_PASSWORD is not set in $ENV_FILE"
@@ -80,6 +100,9 @@ cmd_init() {
         sed "s|^MASTER_KEY=.*|MASTER_KEY=${master}|; s|^POSTGRES_PASSWORD=.*|POSTGRES_PASSWORD=${pgpass}|" \
             "$ENV_FILE" > "${ENV_FILE}.tmp" && mv "${ENV_FILE}.tmp" "$ENV_FILE"
         chmod 600 "$ENV_FILE"
+        # The NAS GUIs read `.env` from the project folder (the repo root).
+        # A symlink keeps one source of truth instead of two copies to drift.
+        [ -e "${ROOT_DIR}/.env" ] || ln -s docker/.env.prod "${ROOT_DIR}/.env" 2>/dev/null || true
         grn "created $ENV_FILE with freshly generated secrets"
         ylw ""
         ylw "  >> BACK UP MASTER_KEY NOW. Copy it into your password manager. <<"

docker-compose.yml

@@ -0,0 +1,23 @@
+# Production stack, at the repo root so the NAS GUIs find it.
+#
+# Synology Container Manager and QNAP Container Station create a project from a
+# folder and look for `docker-compose.yml` in it. Pointing them at `docker/`
+# would find the DEV service stack (docker/docker-compose.yml: throwaway
+# Postgres/Redis/Meilisearch/GreenMail on published dev ports) and start the
+# wrong thing entirely — so the production entry point lives here instead.
+#
+# Everything real is in docker/docker-compose.prod.yml; `include` resolves that
+# file's relative paths against its own directory, so the build context and
+# backup.sh still resolve correctly from here.
+#
+# Config comes from `.env` in this directory — `deploy/webmail.sh init` creates
+# it as a symlink to docker/.env.prod so there is only ever one copy to edit.
+#
+#   GUI:  create a project on this folder, name it `webmail-prod`
+#   CLI:  ./deploy/webmail.sh up        (preferred: adds backup, health-gated
+#                                        updates, rollback and restore)
+
+name: webmail-prod
+
+include:
+  - docker/docker-compose.prod.yml

docker/.env.prod.example

@@ -76,7 +76,7 @@ OAUTH_MS_CLIENT_SECRET=
 
 # Plugins whose schema is migrated on every start. Remove one to stop shipping
 # its tables; `hello` is the SDK demo and is intentionally not listed.
-ENABLED_PLUGINS=calendar contacts labels filters
+ENABLED_PLUGINS="calendar contacts labels filters"
 
 # --- Backups ----------------------------------------------------------------
 BACKUP_AT=03:30

docker/docker-compose.prod.yml

@@ -31,10 +31,10 @@ x-backend-image: &backend-image
       GIT_SHA: ${GIT_SHA:-unknown}
 
 x-backend-env: &backend-env
-  APP_DOMAIN: ${APP_DOMAIN}
+  APP_DOMAIN: "${APP_DOMAIN:?set APP_DOMAIN in your .env}"
-  DATABASE_URL: postgresql+asyncpg://${POSTGRES_USER:-webmail}:${POSTGRES_PASSWORD}@postgres:5432/${POSTGRES_DB:-webmail}
+  DATABASE_URL: postgresql+asyncpg://${POSTGRES_USER:-webmail}:${POSTGRES_PASSWORD:?set POSTGRES_PASSWORD in your .env}@postgres:5432/${POSTGRES_DB:-webmail}
   REDIS_URL: redis://redis:6379/0
-  MASTER_KEY: ${MASTER_KEY}
+  MASTER_KEY: "${MASTER_KEY:?set MASTER_KEY in your .env - generate one with openssl rand -base64 32}"
   BLOB_ROOT: /data/blobs
   SEARCH_BACKEND: ${SEARCH_BACKEND:-pg}
   MEILI_URL: ${MEILI_URL:-http://meilisearch:7700}
@@ -110,7 +110,7 @@ services:
       - effective_cache_size=${PG_EFFECTIVE_CACHE_SIZE:-768MB}
       # Full page writes stay ON: NAS filesystems (btrfs/ext4) are not 8k-atomic.
     volumes:
-      - ${DATA_ROOT}/postgres:/var/lib/postgresql/data
+      - ${DATA_ROOT:?set DATA_ROOT in your .env (see docker/.env.prod.example)}/postgres:/var/lib/postgresql/data
     healthcheck:
       test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER:-webmail} -d ${POSTGRES_DB:-webmail}"]
       interval: 10s

docs/nas-install.md

@@ -106,14 +106,62 @@ is small or you'd rather not tie it up, build on your PC instead — see §6.3.
 Open `http://your-nas:8088/`, create your account, and add a mail account
 through the wizard.
 
-### 2.5 Synology Container Manager (UI instead of SSH)
+### 2.5 Synology Container Manager (GUI instead of SSH)
 
-If you prefer the GUI: *Container Manager → Project → Create*, path
+Yes, this runs from the GUI. *Container Manager → Project → Create*, point it at
-`/volume1/docker/webmail/src/docker`, and select `docker-compose.prod.yml`.
+the **repo root** (`/volume1/docker/webmail/src`), and name the project
-Container Manager reads a file named exactly `.env` from that folder, so run
+`webmail-prod`.
-`cp docker/.env.prod docker/.env` first (and re-copy it whenever you change
+
-settings). The SSH route is still the better one — `webmail.sh` gives you the
+Point it at the repo root, **not** at `docker/`. Both folders contain a
-backup, update, health-gate and rollback logic that the UI has no equivalent for.
+`docker-compose.yml`: the one in `docker/` is the throwaway *dev* service stack
+(Postgres/Redis/Meilisearch/GreenMail on dev ports) and starting it does not
+give you a webmail server. The root one is production.
+
+Name the project `webmail-prod` too — the name you type in the UI overrides the
+one in the compose file, and keeping them the same means `deploy/webmail.sh`
+and the GUI manage the same stack instead of two rival copies.
+
+**You still need a shell once**, to create `docker/.env.prod` with a generated
+`MASTER_KEY` — there is no way to generate a random key in the GUI. Either SSH
+in and run `./deploy/webmail.sh init`, or, if you would rather not enable SSH at
+all, use *Control Panel → Task Scheduler → Create → Scheduled Task → User-defined
+script*, run as `root`, with:
+
+```bash
+cd /volume1/docker/webmail/src && ./deploy/webmail.sh init
+```
+
+Run it once, then edit `docker/.env.prod` in DSM's Text Editor (`init` also puts
+a `.env` symlink in the repo root, which is what Container Manager reads — one
+file, one place to edit).
+
+**What you get in the GUI:** start/stop, live logs, per-container resource use,
+automatic restart after reboot, and the nightly database backups (the `backup`
+service is an ordinary container, so it runs regardless of how you started the
+stack).
+
+**What the GUI cannot do:**
+
+| | Why | Instead |
+|---|---|---|
+| Start Meilisearch | compose profiles aren't exposed in the UI | `./deploy/webmail.sh up` — or delete the `profiles:` line from `docker/docker-compose.prod.yml` |
+| Health-gated updates | it just pulls and restarts; no gate, no rollback | `./deploy/webmail.sh update` |
+| Backup before migrating | — | `./deploy/webmail.sh update` does it automatically |
+| Restore a dump | — | `./deploy/webmail.sh restore <file>` |
+| Pre-flight checks, reindex | — | `./deploy/webmail.sh doctor` / `reindex` |
+
+**Two things that look wrong but aren't:** `init` and `migrate` sit there as
+**Exited (0)** — they are one-shot jobs that did their work and stopped, and
+every other service waited for them. And the first start builds both images on
+the NAS, which is slow and wants ~2 GB of RAM; §6.3 shows how to build them on
+your PC instead.
+
+After editing `.env`, containers keep their old values until they are recreated
+— `./deploy/webmail.sh up` does that cleanly.
+
+The honest recommendation: install and update over SSH, and use the GUI for
+day-to-day watching, starting and stopping. The update path is where all the
+safety lives, and it is the one thing the GUI has no equivalent for.
 
 ### 2.6 Starting automatically after a reboot