Llevar tu API de Spring Boot a producción con Render y Docker es el paso que convierte tu proyecto local en un servicio real disponible en Internet. Aquí aprenderás cómo construir un Dockerfile multi-stage, ajustar la configuración de tu base de datos PostgreSQL y publicar tu aplicación en la capa gratuita de Render, ideal para desarrolladores backend que quieren ver su API corriendo públicamente.

¿Cómo se construye un Dockerfile multi-stage para Spring Boot?

Un Dockerfile funciona como una receta: le dice a Docker cómo construir la imagen de tu aplicación. En este caso usamos dos etapas para optimizar el resultado final [01:00].

¿Qué hace la etapa de compilación?

La primera etapa se encarga de generar el JAR ejecutable. Aquí los puntos clave:

• Usa la imagen base gradle:8.14.2-jdk21, la misma versión que aparece en gradle/wrapper/gradle-wrapper.properties de tu proyecto local.
• Copia todo el contenido de la aplicación al contenedor en la ruta /app, que será el contexto de ejecución.
• Ejecuta el comando gradle bootJar --no-daemon, equivalente a correr la tarea bootJar desde tu IDE pero desde la línea de comandos [01:30].

Es importante alinear la versión de Gradle con la del wrapper para evitar incompatibilidades al construir.

¿Qué hace la etapa de ejecución?

La segunda etapa toma el JAR generado y lo deja listo para correr en producción:

• Parte de una imagen con JDK 21 (Eclipse Temurin funciona bien, pero puedes usar otra distribución).
• Copia desde build/libs/*.jar el artefacto producido en la etapa anterior y lo renombra como platzi-play.jar, sin incluir la versión.
• Documenta el puerto de la aplicación con EXPOSE.
• Ejecuta java -Dspring.profiles.active=prod -jar platzi-play.jar para arrancar con el perfil de producción [02:30].

¿Por qué usar un Dockerfile multi-stage? Porque la imagen final solo contiene el JDK y el JAR compilado, no Gradle ni el código fuente. El resultado es una imagen más liviana y segura.

¿Cómo configurar la base de datos interna en Render?

Antes de desplegar, ajusta el application.properties con la URL interna de PostgreSQL que te entrega Render. La diferencia con la URL pública está en el host: la interna omite el sufijo .oregon-postgres.render.com y deja solo el nombre del servicio antes del puerto.

Esto importa por dos razones:

• Latencia: la conexión interna entre el servicio web y la base de datos viaja por la red privada de Render, no por Internet.
• Seguridad: tu base de datos no necesita exponer su host público para que la aplicación se conecte.

Solo elimina el segmento .oregon-postgres.render.com y conserva el puerto y el nombre de la base. Listo [04:00].

¿Cómo desplegar el Web Service en Render paso a paso?

Con el Dockerfile y la configuración listos, sube los cambios a GitHub con un commit tipo Desplegar en Render y haz push a main. Render tomará el código directamente desde ese repositorio.

Dentro de Render, sigue este flujo:

1. Click en New y selecciona Web Service.
2. Conecta tu cuenta de GitHub o pega la URL del repositorio si es público.
3. Asigna un nombre al servicio, por ejemplo Platzi Play.
4. Selecciona Docker como lenguaje y la rama main.
5. Elige la capa gratuita como tipo de instancia.
6. Si tu app necesita variables de entorno como una API key de OpenAI, agrégalas en la sección correspondiente.
7. Presiona Deploy Web Service [05:30].

La capa gratuita tiene limitaciones: el servicio puede dormirse tras periodos de inactividad y no incluye acceso SSH, pero para una práctica o un side project es suficiente.

¿Qué significa el warning de spring.jpa.open-in-view? Es una advertencia, no un error. Ese parámetro mantiene abierta la conexión a la base de datos hasta que se renderiza la respuesta, lo que puede generar consultas inesperadas. Spring recomienda definirlo explícitamente como true o false según tu caso.

¿Cómo verificar que tu API está corriendo en Internet?

Cuando Render muestre el mensaje Live, tu servicio ya está disponible en la URL pública que aparece en la consola y en el panel superior. Si entras directo a la raíz, verás un 404 Not Found porque la aplicación tiene un context path definido en application.properties.

Prueba estos endpoints añadiendo el contexto correcto:

• /movies para listar todas las películas almacenadas en la base de datos.
• /hello para invocar la integración con LangChain4j y obtener una respuesta generada por IA [08:00].

Si ambos responden, tu API ya está en producción, conectada a PostgreSQL y servida desde un contenedor Docker.

¿Qué aprendiste construyendo este backend?

El recorrido cubrió las piezas que diferencian un proyecto de juguete de un backend profesional:

• Fundamentos de Spring Boot y arquitectura por capas.
• Conexión a bases de datos reales usando Docker y PostgreSQL.
• Validación de datos y manejo de excepciones.
• Integración con inteligencia artificial mediante LangChain4j.
• Empaquetado con bootJar y despliegue en la nube con Render.

Desde aquí puedes profundizar con Spring Data JPA para dominar persistencia avanzada, y luego con Spring Security para añadir autenticación y autorización profesional. ¿Qué endpoint vas a desplegar primero en tu propia cuenta de Render? Cuéntalo en los comentarios.