Production Practices: Configuration, Logging, Docker and Health Checks for Spring Boot

An application that works on your machine is not yet an application that runs in production. Someone has to give it its configuration and secrets, decide where its logs go, ask whether it is healthy, and package it so that it starts the same way everywhere. This article does that for the Job Application Tracker.

• How to configure one build for many environments, and handle secrets.
• What and how to log in production.
• How to add health checks with Actuator.
• How to package the application with Docker and Compose.
• A checklist for going live.

Honesty about verification: the Actuator endpoints below were run on a real application. The Dockerfile and Compose file are standard patterns but were not built or run, because Docker was not installed where this course was verified. Treat them as a starting point to check on your own machine.

The principle from the twelve-factor app method: build once, configure from the environment. The jar you test is the jar you deploy. Everything that differs between development, testing and production is supplied from outside:

Spring Boot makes this easy, as article 32 showed: an environment variable such as DB_URL or SECURITY_ALLOWEDORIGINS overrides the file, and the project's application.properties reads secrets with ${JWT_SECRET} and has no defaults for them. If a required value is missing, the application refuses to start, with a message that does not reveal the value (article 36). Failing at start-up is much better than failing on the first request.

Rules for secrets in production:

• Never commit them, and never bake them into a Docker image: anyone who can pull the image can read them.
• Inject them at run time, from your platform's secret store, or from environment variables set by the orchestrator.
• Use a different secret in every environment, and rotate them if they may have leaked.
• Do not print them: not in logs, not in error messages, not in /actuator/env.

Logging is how you learn what happened when you were not watching (article 22 taught the basics). In a deployed service:

• Write to standard output, not to files. The platform (Docker, Kubernetes, a log service) collects it. Spring Boot does this by default.
• Use INFO as the default level, and raise a package to DEBUG temporarily for diagnosis: logging.level.com.example.jobtracker=debug, without redeploying code.
• Log events, with context: the user id, the resource id, the outcome. Log an error once, with its stack trace, where it is handled. The catch-all handler in the API does exactly that and returns a generic message to the client.
• Never log secrets, tokens, passwords or personal data. A debug log of a request body can contain all of them.
• Correlate requests. A request id carried through the logs lets you follow one request across components. Structured (JSON) logging makes logs searchable. Spring Boot supports structured logging formats through configuration.
• Watch for the noisy ones: show-sql is for development only, and DEBUG logging in production is slow and may expose data.

A load balancer or container platform needs to ask the application: are you alive, and can you take traffic? Spring Boot Actuator provides that. Add the starter (spring-boot-starter-actuator) and expose only what you need:

management.endpoints.web.exposure.include=healthmanagement.endpoint.health.probes.enabled=truemanagement.endpoint.health.show-details=never

The first line exposes only the health endpoint over HTTP. The second turns on liveness and readiness probes, the two questions orchestrators ask: liveness ("is the process healthy, or should it be restarted?") and readiness ("is it ready to receive traffic?"). The third makes sure the public response says only UP or DOWN and never lists components such as the database. The security configuration permits GET /actuator/health without a token (a one-line change in SecurityConfig) and keeps everything else denied. This is the real output from the running application, with PostgreSQL connected:

$ curl -i http://localhost:18085/actuator/healthHTTP/1.1 200 Content-Type: application/vnd.spring-boot.actuator.v3+json{"groups":["liveness","readiness"],"status":"UP"}$ curl -i http://localhost:18085/actuator/health/readinessHTTP/1.1 200 {"status":"UP"}$ curl -i http://localhost:18085/actuator/envHTTP/1.1 401 

• /actuator/health returned UP and listed the two groups, liveness and readiness.
• /actuator/health/readiness returned UP. Readiness depends on the application context being ready; it is what a platform checks before sending traffic.
• /actuator/env, which would list the environment (including secrets), is not exposed and is behind authentication anyway: it returned 401.

Actuator can also expose metrics, thread dumps and more. Expose the minimum, protect it, and never leave management endpoints open to the internet. The same build still passes all 125 tests (the run for this article used JDK 21).

Flyway runs at start-up and applies pending migrations (article 34). That is convenient, and it has consequences in production:

• The application's database user needs the permission to change the schema. Many teams run migrations as a separate step with a more privileged user, and run the application with a restricted one.
• Migrations must be backwards compatible with the previous version of the application, so a rolling deployment (old and new versions running together) works. Add a column in one release, use it in the next, drop the old one in a third.
• Back up before migrating, and test restoring a backup. A backup you have never restored is a hope.

A container image packages the application with its runtime, so it runs the same way everywhere. A Dockerfile describes how to build it. This one uses two stages: the first compiles with Maven and the second contains only a Java runtime and the jar:

# Build stage: compile and package with MavenFROM maven:3.9-eclipse-temurin-21 AS buildWORKDIR /buildCOPY pom.xml .COPY src ./srcRUN mvn -B -ntp -q package -DskipTests# Run stage: only a Java runtime and the jar, running as an unprivileged userFROM eclipse-temurin:21-jreRUN useradd --system --uid 10001 appuserWORKDIR /appCOPY --from=build /build/target/jobtracker-*.jar app.jarUSER appuserEXPOSE 8080ENTRYPOINT ["java", "-jar", "app.jar"]

Why it is written this way:

• Multi-stage build: the final image has no Maven, no source code and no build caches, so it is smaller and exposes less.
• A non-root user: if an attacker takes over the process, they do not have administrator rights inside the container.
• No secrets in the image. Nothing sensitive is copied or set. The application reads its configuration from the environment when it starts.
• Pin versions deliberately. Image tags such as 21-jre move over time. Decide how you track updates and security patches of the base image.
• Possible improvements: layer the dependencies for better build caching, a .dockerignore file, a health check instruction, and memory settings for the JVM in a container.

Docker Compose describes several containers together. This file starts PostgreSQL and the API, waits for the database to be healthy, and passes all configuration through environment variables, with the secrets coming from the shell or an .env file that is not committed (the project's .gitignore lists .env):

services:  db:    image: postgres:18    environment:      POSTGRES_DB: jobtracker      POSTGRES_USER: jobtracker      POSTGRES_PASSWORD: ${DB_PASSWORD}    healthcheck:      test: ["CMD-SHELL", "pg_isready -U jobtracker -d jobtracker"]      interval: 5s      timeout: 3s      retries: 10  api:    build: .    depends_on:      db:        condition: service_healthy    environment:      DB_URL: jdbc:postgresql://db:5432/jobtracker      DB_USER: jobtracker      DB_PASSWORD: ${DB_PASSWORD}      JWT_SECRET: ${JWT_SECRET}      SECURITY_ALLOWEDORIGINS: http://localhost:3000    ports:      - "8080:8080"

To use it you would set the two secrets in your shell (for example export DB_PASSWORD=... and export JWT_SECRET=$(head -c 32 /dev/urandom | base64)), run docker compose up --build, and call http://localhost:8080/actuator/health. This was not run here. Note that postgres:18 and the base image names are the ones expected to exist, so check them against the current Docker Hub tags.

• HTTPS terminates in front of the application, and plain HTTP redirects or is refused.
• Secrets come from the platform, are unique per environment, and are not in Git, images or logs.
• Database: migrations tested, a restricted application user, backups taken and restored in a test, connection pool sized to the database limit.
• Health checks configured for liveness and readiness, with sensible timeouts.
• Logging and monitoring: logs collected, errors alerting someone, basic metrics (request rate, errors, latency).
• Limits: memory and CPU limits for the container, request size limits, rate limiting on login.
• Dependencies updated and scanned, and the base image patched.
• CORS limited to the real front-end origins.
• A rollback plan: you can deploy the previous version, and the database changes allow it.
• Documentation: a README with how to build, configure, run and diagnose.

• Different jars for different environments, so what you tested is not what runs.
• Secrets in the image, the repository or the logs.
• Exposing all Actuator endpoints, or health details, to the public.
• Logging in files inside the container, which disappear with it.
• Running the container as root, and using the latest tag everywhere.
• Letting the application start with missing configuration, then failing later.
• Never testing a restore of the backups.
• Applying breaking schema changes while the old version still runs.

• Next: Project 3: The Job Application Tracker API assembles and reviews the whole backend.
• For interviews: Interview Concepts, Part 2 covers configuration, logging, health checks and containers as questions.