Files
webmail-client/deploy/build-push.sh
T
lukasandClaude Opus 5 5553b5febe Deploy: production Docker stack for a single host (Synology/QNAP NAS)
Everything needed to run the app on an Intel NAS that is also doing other
jobs: one published port, no host networking, memory/CPU caps and log
rotation on every container, and all state in bind mounts under DATA_ROOT
so mail survives image updates, project deletion in the NAS UI, and full
reinstalls — and so Hyper Backup/HBS3 can actually see it.

- docker/Dockerfile.backend: multi-stage, non-root (uid 10001), tini for
  the <10s graceful lease release. Installs the four plugins as entry-point
  distributions. One image, several roles via docker/entrypoint.sh
  (api | worker-sync | worker-jobs | migrate | reindex | plugins).
- docker/Dockerfile.frontend + nginx.conf: SPA + /api reverse proxy with
  the WebSocket upgrade for /api/ws, and X-Forwarded-Proto preserved so
  the API still emits __Host-/Secure cookies when TLS is terminated by
  the NAS reverse proxy (identity/cookies.py keys off request scheme).
- docker/docker-compose.prod.yml: project name webmail-prod, NOT webmail —
  docker-compose.yml (dev services) owns that name, and two compose files
  sharing one project name fight over each other's containers.
  Meilisearch is an opt-in profile; SEARCH_BACKEND=pg is the default so a
  small NAS pays nothing for search.
- migrate runs as a one-shot (core Alembic head + every plugin branch)
  that everything else waits on, so a bad migration can never leave new
  code running against an old schema.
- docker/backup.sh: nightly pg_dump verified with `pg_restore --list`
  before it counts as a backup, with retention and a baseline on first
  start.
- deploy/webmail.sh: init/doctor/up/down/status/logs/update/rollback/
  backup/restore/reindex/psql/shell. `update` is backup -> images ->
  migrate -> roll workers, api, web -> health-gate, with automatic
  rollback to the previous version if the gate fails. `doctor` refuses to
  be quiet when DATA_ROOT is on NFS/SMB (silent Postgres corruption).
- deploy/build-push.sh: build images off-NAS (the frontend build wants
  ~2GB RAM) and push to Gitea, or --save a tar to carry over.
- scripts/reindex_search.py: rebuild the search index from Postgres alone.
  Every SearchDoc field is already stored, so the index is derived data
  that never needs backing up — this closes the only real objection to
  running Meilisearch on a box whose volumes may be wiped.
- pyproject: package-data for accounts/presets.yaml and the shared plugin
  Alembic env. Without it a non-editable install (i.e. any image) silently
  ships a package that fails at runtime.
- GET /api/version, used by the deploy health gate.

Verified end to end on a real stack: fresh install, all services healthy,
core + 4 plugin migration branches applied, login/SPA/plugin bundles
through nginx, WS upgrade returning 101, __Host- cookies under a
simulated TLS proxy, backup -> restore round-trip preserving user and
plugin schema, failed-update auto-rollback (both a bad migration and a
boot-crashing API), and Meilisearch profile serving a live query.
ruff + mypy --strict clean, 363/363 backend tests pass.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Nux3LCu4zP9nih4BRhPyHw
2026-09-14 18:53:50 +02:00

78 lines
2.9 KiB
Bash
Executable File

#!/usr/bin/env bash
# Build the two production images on THIS machine and either push them to a
# registry or export them as a file you can copy to the NAS.
#
# Why you'd use this instead of building on the NAS: the frontend build (Vite +
# tsc) wants ~2 GB of RAM and a lot of CPU. On a 2-4 GB NAS that is slow at best
# and an OOM at worst, and it competes with everything else the box is doing.
#
# ./deploy/build-push.sh v1.0.0 # build + push to $REGISTRY_PREFIX
# REGISTRY_PREFIX=192.168.1.185:8418/claude/webmail \
# ./deploy/build-push.sh v1.0.0
# ./deploy/build-push.sh v1.0.0 --save # build + write a .tar to load on the NAS
#
# On the NAS afterwards:
# push mode: set REGISTRY_PREFIX and IMAGE_TAG in docker/.env.prod, then
# ./deploy/webmail.sh update v1.0.0
# save mode: docker load -i webmail-v1.0.0.tar && ./deploy/webmail.sh update v1.0.0
set -euo pipefail
ROOT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd)"
TAG="${1:-}"
MODE="${2:-push}"
REGISTRY_PREFIX="${REGISTRY_PREFIX:-webmail}"
PLATFORM="${PLATFORM:-linux/amd64}" # Synology and QNAP Intel boxes
[ -n "$TAG" ] || { echo "usage: $0 <version-tag> [--save]" >&2; exit 1; }
GIT_SHA="$(git -C "$ROOT_DIR" rev-parse --short HEAD 2>/dev/null || echo unknown)"
if ! git -C "$ROOT_DIR" diff --quiet 2>/dev/null; then
echo "warning: working tree has uncommitted changes; tagging ${TAG} anyway" >&2
fi
build() {
local name="$1" dockerfile="$2"
echo "== building ${REGISTRY_PREFIX}/${name}:${TAG}"
docker build \
--platform "$PLATFORM" \
-f "${ROOT_DIR}/docker/${dockerfile}" \
--build-arg "APP_VERSION=${TAG}" \
--build-arg "GIT_SHA=${GIT_SHA}" \
-t "${REGISTRY_PREFIX}/${name}:${TAG}" \
-t "${REGISTRY_PREFIX}/${name}:latest" \
"$ROOT_DIR"
}
build backend Dockerfile.backend
build web Dockerfile.frontend
if [ "$MODE" = "--save" ]; then
out="${ROOT_DIR}/webmail-${TAG}.tar"
echo "== saving both images to ${out}"
docker save -o "$out" \
"${REGISTRY_PREFIX}/backend:${TAG}" \
"${REGISTRY_PREFIX}/web:${TAG}"
echo "done. Copy it to the NAS and run: docker load -i $(basename "$out")"
exit 0
fi
if [ "$REGISTRY_PREFIX" = "webmail" ]; then
cat >&2 <<'MSG'
REGISTRY_PREFIX is still the local default ("webmail"), so there is nothing to
push to. Either set it to your registry path, e.g.
REGISTRY_PREFIX=192.168.1.185:8418/claude/webmail ./deploy/build-push.sh v1.0.0
(run `docker login 192.168.1.185:8418` once first), or re-run with --save to
produce a tar file instead.
MSG
exit 1
fi
echo "== pushing"
docker push "${REGISTRY_PREFIX}/backend:${TAG}"
docker push "${REGISTRY_PREFIX}/web:${TAG}"
docker push "${REGISTRY_PREFIX}/backend:latest"
docker push "${REGISTRY_PREFIX}/web:latest"
echo "pushed ${TAG}. On the NAS: ./deploy/webmail.sh update ${TAG}"