Running the service
What the application ships, and where the deployment boundary sits.
The team ships a Docker image, a health endpoint and documented environment variables. Runtime, scaling, networking, TLS and production secrets belong to DevOps. That line is deliberate: it keeps secrets out of the repository and lets the image be promoted unchanged between environments.
What the image contains
No secrets, ever
The image carries application code and dependencies only. Every credential
arrives at runtime through the environment. Local development may use a
.env file; it is gitignored and excluded from the build context.
Health
Two probes, deliberately different:
| Endpoint | Checks | Use for |
|---|---|---|
GET /health/live | Nothing. The process is up. | Liveness |
GET /health/ready | Postgres connectivity | Readiness |
/health/live never touches a dependency, so a slow database cannot get the
container killed. /health/ready returns 503 with a per-check breakdown when
something it depends on is unavailable:
{ "status": "not_ready", "checks": { "database": "unavailable" } }Graceful shutdown
The application factory owns the process-wide resources — the database engine and one shared HTTP client — and closes both on shutdown, so in-flight requests finish rather than being cut off mid-stream.
Configuration
Every setting is read once into a typed settings object at startup. A missing required value fails the process immediately rather than surfacing as a confusing error on the first request.