The Prisma CLI ships Studio, which brings React and a graph-layout
engine along with it — tens of megabytes for a browser tool this image
will never run. Removing them takes the image from 705 MB to 649 MB.
`effect` looks like part of the same bundle and is not: the CLI itself
requires it, and removing it breaks `migrate deploy` outright. That was
found by running the migration in the pruned image rather than by
reading the dependency tree.
Worth recording how the first attempt at this went wrong: the prune was
tried inside a running container, where the files belong to root and the
process runs as node, so every `rm` failed silently behind a `2>/dev/null`.
The migration then passed against an untouched tree and looked like
proof. The check only became a check once the prune happened at build
time.
The entrypoint migrates on every start, so an over-eager prune now fails
loudly at first boot rather than quietly at the worst moment.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012cSY9pVhZmJUKNN7wf1Myd
Multi-stage build on node:22-alpine, standalone output, non-root user,
healthcheck on /api/health, and migrations applied by the entrypoint
before the first request. A failed migration stops the container rather
than serving an inconsistent database.
Getting the Prisma CLI into the runtime image took three attempts and
the reasoning is recorded in the Dockerfile. Copying it out of the build
stage leaves its transitive dependencies behind; patching them in one at
a time is a losing game. It now gets its own stage and its own tree,
with the schema and prisma.config.ts beside it, and the entrypoint runs
from there so every import resolves locally. The version is read from
our own package.json so it cannot drift from the generated client.
Two things had to change to build without a database, which a build
container rightly does not have. prisma.config.ts no longer reads the
URL through prisma's env() helper, which throws on a missing variable
even for `generate`. And lib/db.ts creates the client on first use
rather than on import: Next imports every route module while collecting
page data, so a module that threw on import failed the build with an
error naming whichever route was analysed first, which says nothing
useful. The failure now lands on the first query, where it belongs.
Verified by running the image against a real database: migrations
applied, cron scheduled in Europe/Zurich, a device paired, and the panel
image served as a genuine 1-bit 800x480 BMP — so satori, resvg and the
vendored fonts all work on musl. The image hash came out identical to
the one produced on the glibc host, which is the reproducibility the
vendored fonts were for.
The production overlay publishes through an existing Traefik, drops the
host port, mounts the filesystem read-only, and adds a nightly dump kept
for a fortnight.
README and DEPLOY are in French and cover what actually bites: the panel
receives nothing and only updates when it wakes; the issuer must match
to the character; the captive portal URL takes no trailing slash; a
rollback across a migration needs the dump, because Prisma does not
undo one.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012cSY9pVhZmJUKNN7wf1Myd
vliaudatandClaude Opus 5