Spring Boot: desarrollar varios servicios en local

Actualizado: 14 de agosto de 2026

Un servicio Spring Boot en tu máquina es un problema resuelto: ejecutas la clase principal y estás trabajando. Cinco, hablando entre ellos, con un Kafka y un Postgres debajo, es por donde se va la mañana.

Lo que de verdad cuesta tiempo

• El orden. El que se registra tiene que estar levantado antes que el que lo busca, y «levantado» significa respondiendo a /actuator/health, no tener un PID.
• Los puertos. Dos servicios traen 8080 por defecto. El tercero que arrancas se encuentra uno ocupado y te toca averiguar cuál.
• Las URLs. Cada servicio tiene una propiedad que apunta a otro —app.catalog.url y sus quince hermanas— y apuntar tres a otro sitio significa editar ficheros que luego hay que acordarse de no comitear.
• La infraestructura. Kafka, Redis y PostgreSQL, levantados siempre igual, con los topics y el esquema que los servicios esperan.
• Tus propias librerías. Una librería compartida que además necesitas tocar significa mvn install, subir la versión y confiar en que nadie más se llevó el snapshot.

Qué hace Aseptic con eso

Aseptic detecta un servicio Spring Boot por su manifiesto —Maven o Gradle— y sabe cómo arrancarlo, dónde está su endpoint de salud y cómo pasarle configuración. La configuración se inyecta al arrancar, como propiedades de sistema -D o variables de entorno, así que las URLs entre servicios se reescriben sin tocar application.yml ni nada de tu repositorio. Nada que comitear, nada que acordarse de revertir.

Un escenario agrupa los servicios de un flujo y los arranca en orden de dependencia, esperando a la salud y no al proceso. Los puertos que chocan se remapean solos, y el valor nuevo es el que se les cuenta a los demás servicios. Kafka, Redis y PostgreSQL levantan en Docker, gestionados por la app.

Para cada dependencia eliges dónde se resuelve: otro servicio que tienes abierto en local, vuestro entorno compartido en la nube —con la VPN, si es así como llegáis— o un mock. Esa elección es por dependencia, no por entorno, así que «estos dos en local y el resto contra la nube» es un martes normal y no un ejercicio de configuración.

Librerías sin publicarlas

Si el cambio abarca un servicio y una librería tuya, Aseptic construye la librería y la enlaza en quienes la consumen donde Maven y Gradle la buscan —tu repositorio local ~/.m2— y puede reconstruirla y reenlazarla al cambiar. No edita el pom.xml ni el build.gradle del consumidor, y desenlazar deshace solo lo que hizo.

Lo que no hace

No sustituye a tu build. Maven y Gradle se quedan exactamente donde están, y Aseptic los llama. No ejecuta un clúster de Kubernetes, así que si lo que necesitas comprobar es un probe, un ingress o un sidecar, esta es la herramienta equivocada —un clúster local es la correcta—. Y necesita Docker para la infraestructura común, así que hace falta tener Docker Desktop o un motor Docker instalado.

Está en beta pública, se publica para Windows, macOS y Linux, y es gratis para uso personal.

Dónde queda esto frente a los sospechosos habituales

Si tus servicios ya tienen imágenes y manifiestos que mantienes, Tilt o Skaffold mantienen el bucle local con la forma de producción, a cambio de una build y un despliegue en cada cambio. La página de alternativas a Docker Compose despliega el campo entero, y la comparativa amplia cubre Compose y Kubernetes local directamente.

Hay equivalentes de esta página para Quarkus y para Node.

← Volver al inicio