Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/JuanSebax85/backend-prueba-fullstack/llms.txt

Use this file to discover all available pages before exploring further.

The project ships with a Dockerfile and a docker-compose.yml that together define the full runtime environment. A two-stage Docker build keeps the final image lean, and Docker Compose orchestrates the database and backend containers with a defined startup order.

​
Dockerfile: two-stage build

The Dockerfile uses two stages to separate the build environment from the runtime image:
Dockerfile
# Stage 1: build the JAR
FROM maven:3.9.6-eclipse-temurin-17 AS build
WORKDIR /app
COPY . .
RUN mvn clean package -DskipTests

# Stage 2: run the JAR
FROM eclipse-temurin:17-jdk
WORKDIR /app
COPY --from=build /app/target/*.jar app.jar
ENTRYPOINT ["java","-jar","app.jar"]
StageBase imagePurpose
buildmaven:3.9.6-eclipse-temurin-17Compiles the source code and packages the JAR
Runtimeeclipse-temurin:17-jdkRuns the compiled JAR — no Maven or source files included
The final image only contains the JDK and the application JAR, which reduces image size and attack surface.

​
Docker Compose services

docker-compose.yml
services:
  db:
    image: postgres:15
    container_name: postgres_db
    ports:
      - "5432:5432"

  backend:
    build: .
    container_name: backend_app
    ports:
      - "8080:8080"
    depends_on:
      - db
ServiceContainer namePort mappingDescription
dbpostgres_db5432:5432PostgreSQL 15 database
backendbackend_app8080:8080Spring Boot REST API

​
Startup order and health check

The backend service declares depends_on: db, so Docker Compose will not start the backend until the db service is running. The db service also defines a health check:
docker-compose.yml
db:
  healthcheck:
    test: ["CMD-SHELL", "pg_isready -U postgres"]
    interval: 5s
    timeout: 5s
    retries: 10
Docker runs pg_isready -U postgres every 5 seconds. After up to 10 retries (50 seconds total), if PostgreSQL is not accepting connections, the container is marked unhealthy. The backend connection pool is configured with initialization-fail-timeout=0, meaning it will keep retrying to acquire a connection rather than failing immediately.
depends_on in Compose v3 only waits for the container to start, not for it to be healthy, unless you combine it with condition: service_healthy. The Hikari pool retry behavior compensates for this in the current configuration.

​
Common commands

1

Start only the database

docker compose up -d db
Starts the postgres_db container in detached mode. Useful when you want to run the backend locally outside of Docker.
2

Build and start the backend

docker compose up --build backend
Rebuilds the backend_app image from the Dockerfile and starts the container. Run this after any source code changes.
3

Stop all services

docker compose down
Stops and removes all containers defined in docker-compose.yml. Database data persists if a named volume is configured; otherwise it is lost when the container is removed.
4

View backend logs

docker compose logs backend
Streams logs from the backend_app container. Add -f to follow in real time:
docker compose logs -f backend
5

Check container status

docker compose ps
Lists all services with their current state, health status, and port bindings.

​
Troubleshooting

​
Backend fails to connect to the database

If the backend logs show connection errors on startup, the database may not have finished initializing before the backend attempted its first connection.
1

Check database health

docker compose ps
Look at the STATUS column for the db service. It should read healthy. If it shows starting or unhealthy, wait a few seconds and check again.
2

Verify PostgreSQL is ready

docker exec -it postgres_db pg_isready -U postgres
If PostgreSQL is accepting connections, the output is:
/var/run/postgresql:5432 - accepting connections
3

Restart the backend

Once the database is healthy, restart the backend container:
docker compose restart backend
The Hikari pool will re-attempt the connection on startup.
If docker compose down is run without a named volume, all PostgreSQL data is deleted along with the container. Add a named volume to docker-compose.yml if you need data to persist across down/up cycles.

​
Next steps

Configuration guide

Understand the environment variables and connection pool settings.

Database guide

Explore the schema, connect to PostgreSQL, and restore backups.

Build docs developers (and LLMs) love

Get started for freeTalk to us