Desplegar Spring Boot: por qué un Dockerfile es la respuesta correcta, no un respaldo

Rails tiene una convención de servidor web, Django tiene gunicorn, Laravel tiene Octane o PHP-FPM — cada ecosistema convergió en un conjunto pequeño y adivinable de formas de iniciar en realidad un proceso web. El mundo de la JVM nunca lo hizo de la misma manera: una app de Spring Boot puede ser un jar plano, un WAR en Tomcat, construida con Maven o Gradle, iniciada con media docena de formas de comando razonables según cómo esté armado el proyecto. Adivinar mal cuál de ellas no falla de forma ruidosa — falla de una manera que parece un problema de la app en vez de uno de la detección.

Por qué Dockerfile primero es la elección honesta aquí

En vez de fingir que se puede autodetectar un comando de build y arranque de la JVM que es genuinamente ambiguo entre proyectos, un repo con su propio Dockerfile es el método de build de primera elección real en Railyard — se verifica antes que Railpack, antes que Nixpacks, antes que cualquier otra cosa. Para Spring Boot en particular, eso no es una función faltante que hay que rodear; es la herramienta correcta para una forma de build que tiene demasiadas respuestas válidas como para adivinar con seguridad. Un Dockerfile dice exactamente qué versión de JDK, qué herramienta de build y qué comando de arranque final necesita la app — información que ningún escáner de pom.xml o build.gradle por sí solo puede inferir de forma confiable.

FROM eclipse-temurin:21-jre
COPY target/my-app.jar app.jar
ENV SERVER_PORT=$PORT
CMD ["java", "-jar", "app.jar"]

El único requisito real: la app tiene que enlazarse a $PORT (Spring Boot lo lee de SERVER_PORT o server.port), el mismo contrato que espera cualquier método de build en la plataforma.

Lo que sigue funcionando igual que en cualquier otra app

• Configuración y secretos: todo lo que se lee vía @Value o la sintaxis ${VAR} de application.properties es una variable de entorno simple en Variables, o se define con railyard env:set my-app KEY=VALUE — nunca horneada en la imagen, así que el mismo build corre sin cambios desde staging hasta producción.
• Bases de datos: apunta la app a un complemento de Postgres o MySQL desde el canvas y conecta su connection string en application.properties como una variable — el complemento en sí se aprovisiona de la misma forma sin importar el lenguaje.
• Deploy en cada push: una vez que el Dockerfile construye en local, git push (o railyard create my-app https://github.com/me/my-app) reconstruye y redespliega en cada push, igual que cualquier otro repo.

El trade-off real, dicho sin rodeos

Esto significa un poco más de trabajo inicial que el que recibe gratis un repo de Rails o Django — escribir el Dockerfile una vez, en vez de que se infiera. A cambio, el build se comporta exactamente como el Dockerfile dice que lo hará, cada vez, lo cual para un build de la JVM vale más que una comodidad que habría adivinado mal en un porcentaje real de proyectos.

Referencia completa: Métodos de build, Desplegar una imagen de Docker.