Good call on keeping it a liveness check. The /api/health route in the post only returns a status and the process uptime, with no database call, and that's on purpose: if a DB blip fails the probe, Docker marks the container unhealthy and Coolify or Swarm can pull containers that are actually fine. If you want DB status, put it on a separate endpoint that your monitoring watches.

On base images, I measured slim and Alpine in the same test: 287 MB on node:24-slim vs 229 MB on node:24-alpine. I didn't build a distroless variant or run a CVE scan, so I don't have numbers there. Sharp ships prebuilt musl binaries, so Alpine works for it, but I keep slim as the default because glibc is the safer bet for other native modules. A distroless runner with a Trivy or Docker Scout comparison would make a good follow-up.

Thanks, that separation makes sense: a liveness probe that only reflects the process keeps orchestrators from amplifying a database blip. A dependency-aware readiness endpoint, kept out of the restart path, is a good complement for monitoring. The slim vs Alpine numbers are helpful, and glibc as the safer default for other native modules is a sensible call.