Configurar el Puerto en Spring Boot: Opciones más allá del 8080

Cuando trabajas con Spring Boot, lo primero que notas es que tus aplicaciones suelen levantarse en el puerto 8080. Es práctico para empezar, pero en cuanto tienes dos servicios corriendo en tu máquina o necesitas desplegar en un servidor, el 8080 se te queda corto. Lo bueno es que cambiarlo es sencillo, pero hay varias formas de hacerlo y cada una tiene su momento. De hecho, yo mismo al principio me complicaba más de la cuenta hasta que entendí bien las diferencias.

La forma más común, y la que yo prefiero para la mayoría de los casos, es declararlo directamente en la configuración de la aplicación. Esto se hace en el archivo application.properties, que usualmente encuentras en src/main/resources/. Simplemente agregas una línea:

server.port=8090

Con esa simple línea, al levantar tu aplicación, esta intentará usar el puerto 8090. Si ese puerto ya está ocupado, la aplicación te lanzará un error y no podrá iniciar. Es una solución directa, legible y que queda versionada con tu código, lo que la hace ideal para entornos de producción donde quieres que el puerto sea fijo y predecible.

Alternativas para configurar el puerto

Aunque application.properties es mi método de cabecera, no es la única forma, y a veces ni siquiera la mejor, dependiendo del contexto. Aquí te detallo las principales:

1. Usando application.yml

Si eres de los que prefiere YAML por su sintaxis más limpia para configuraciones anidadas, puedes hacer exactamente lo mismo en application.yml. La lógica es idéntica, solo cambia el formato:

server:
  port: 8090

En mi experiencia, para una configuración tan simple como el puerto, no hay una ventaja real de usar YAML sobre .properties. Pero si ya tienes el resto de tu configuración en YAML, tiene sentido mantener la consistencia.

2. Configuración vía Argumentos de Línea de Comandos o Propiedades del Sistema

Esta es una opción súper potente, especialmente para entornos de desarrollo local, pruebas o despliegues donde necesitas flexibilidad sin modificar el código fuente. Puedes sobrescribir el puerto configurado en application.properties o .yml pasándolo como un argumento de línea de comandos cuando ejecutas tu JAR:

java -jar tu-app.jar --server.port=8090

O, si estás ejecutando directamente desde tu IDE o usando mvn spring-boot:run, puedes pasarlo como una propiedad del sistema (JVM argument):

java -Dserver.port=8090 -jar tu-app.jar

El prefijo -D indica que es una propiedad del sistema. Esto es útil si tienes varias aplicaciones Spring Boot corriendo en tu máquina y quieres evitar conflictos de puertos sin tener que ir a cambiar un archivo y reconstruir cada vez. Ojo que en entornos de CI/CD, o con Docker, esta flexibilidad es clave. Por ejemplo, en un contenedor Docker podrías mapear el puerto interno del contenedor a un puerto diferente en el host sin tocar la configuración de la app en sí.

3. Usando un Puerto Aleatorio

Hay escenarios donde no quieres especificar un puerto fijo, sino que la aplicación elija uno disponible al azar. Esto es increíblemente útil para tests de integración, donde no quieres que los tests fallen porque un puerto específico ya está ocupado, o para microservicios que se registran en un servicio de descubrimiento y no necesitan tener un puerto predecible.

Para esto, simplemente pones 0 como valor del puerto:

server.port=0

Cuando haces esto, Spring Boot buscará un puerto libre y lo usará. Si estás en un test, puedes inyectar el puerto real que se asignó usando la anotación @LocalServerPort, por ejemplo, en una clase de test:

@LocalServerPort
private int port;

Esto te permite construir URLs para tus tests usando el puerto dinámico. Es una solución muy elegante para evitar fricciones en los pipelines de pruebas.

4. Variables de Entorno

Una alternativa al argumento de línea de comandos, y muy popular en entornos de microservicios y despliegues en la nube, es usar variables de entorno. Spring Boot mapea automáticamente las variables de entorno que siguen ciertos patrones a sus propiedades de configuración. Por ejemplo, para configurar el puerto, podrías exportar una variable antes de ejecutar tu aplicación:

export SERVER_PORT=8090
java -jar tu-app.jar

Spring Boot transforma SERVER_PORT (que usa guiones bajos y mayúsculas) a server.port. Esto es mi método preferido cuando trabajo con Docker o Kubernetes, porque me permite externalizar la configuración del puerto de una forma muy limpia y estándar para el orquestador de contenedores. Es más robusto que un argumento de JVM porque los contenedores tienen su propia forma de manejar las variables de entorno.

¿Cuándo usar cada opción?

• application.properties o .yml: Para la configuración por defecto o en producción donde el puerto es fijo y predecible. Es la opción más clara y fácil de versionar.
• Argumentos de línea de comandos/JVM: Ideal para pruebas locales rápidas, desarrollo donde necesitas levantar varias instancias o para overrides puntuales en scripts de despliegue que no usan variables de entorno.
• Puerto aleatorio (server.port=0): Imprescindible para tests de integración robustos o para microservicios que se registran dinámicamente.
• Variables de entorno: Mi elección para despliegues en contenedores (Docker, Kubernetes) y entornos de nube, ya que permite una gestión de configuración muy desacoplada y escalable.

En mi caso, en proyectos propios y con clientes, me he encontrado con que muchas veces la gente sobreingenieriza la configuración del puerto. A veces basta con el application.properties y una buena práctica de nombramiento para los entornos. Pero la flexibilidad de las variables de entorno para Docker es un cambio de juego.

Si tuviera que empezar de cero un proyecto hoy, configuraría el puerto por defecto en application.properties y me aseguraría de que el README.md del proyecto explique claramente cómo sobrescribir ese puerto usando variables de entorno para el despliegue en contenedores, y con argumentos de línea de comandos para el desarrollo local. Esto me habría ahorrado un par de dolores de cabeza en el pasado, especialmente cuando los puertos de desarrollo local se ponían a pelear sin aviso. La claridad y la simplicidad en la configuración siempre son lo primero para mí.