- docker-compose.yml used "websecure" as the entrypoint name; the
actual falcon_network convention (confirmed against the real
traefik/compose.yml) is "web-secure". Also switched the networks
block from a hardcoded falcon_network to the same
compose_network-aliased ${NETWORK_NAME} pattern already used in the
Traefik labels, instead of only half-respecting that variable.
- config.yml gave the Traefik widget an href, but this deployment runs
with --api.dashboard=false - there's no dashboard to link to.
Multi-stage Dockerfile (deps -> build -> prod-deps -> runtime) that
ships a full production node_modules rather than Next's standalone
output, since standalone tracing is incompatible with a custom server
(noted back in M1). Runs as a non-root user with a read-only rootfs,
dropped capabilities, and tini as PID 1. tsx moves from dev to a real
runtime dependency since the production start script runs server.ts
directly rather than a precompiled bundle. next.config.ts marks
dockerode/systeminformation as serverExternalPackages so Next's
bundler leaves their OS-conditional requires alone.
docker-compose.yml mirrors the sibling stacks' own conventions
(TRAEFIK_HOST/NETWORK_NAME in .env, falcon_network as an external
network, the same traefik.* label shape) so it fits their existing
tooling, plus a new /api/health route and healthcheck.mjs for the
container HEALTHCHECK.
Verified end-to-end with a real `docker build` + `docker compose up`:
non-root/read-only/cap-dropped container boots cleanly, is reachable
by container name from another container on the shared network (as
Traefik would reach it), and the container's own HEALTHCHECK reports
healthy. That run surfaced a real gap - the non-root user got EACCES
on /var/run/docker.sock, since it's owned by root:docker on the host -
fixed via group_add on a DOCKER_GID env var (documented in .env.example
with the command to find it), then re-verified that both docker.sock
access and label-based auto-discovery work correctly under the fix.
valknar