Despliega Java en Nodion

Despliega Java paso a paso

1. Haz commit del wrapper de Maven o Gradle Con gradlew, Nodion ejecuta ./gradlew build -x test --no-daemon; con mvnw, ejecuta ./mvnw -B -DskipTests clean package. Un pom.xml sin wrapper se compila con el Maven propio de Nodion. Un proyecto Gradle sin gradlew falla, así que crea el wrapper con gradle wrapper y haz commit de él junto con la carpeta gradle/wrapper. Los tests no se ejecutan durante el despliegue; ejecútalos en tu CI.
2. Fija la versión de Java Si no fijas ninguna versión, Nodion compila y ejecuta con Java 21. Indica otra versión en system.properties. Nodion no lee la configuración de toolchain de pom.xml ni de tu build de Gradle, así que mantenla alineada con este archivo. system.properties

   java.runtime.version=25

3. Escucha en PORT Nodion define PORT para el proceso web y la pasa a la JVM como -Dserver.port, lo que basta para Spring Boot. Otros frameworks, o tu propio servidor, leen PORT por su cuenta y escuchan en 0.0.0.0.

   int port = Integer.parseInt(System.getenv().getOrDefault("PORT", "8080"));

4. Crea la app En el dashboard, crea una aplicación desde tu repositorio de GitHub, GitLab, Bitbucket o Gitea y elige la rama, la región EU Central y un tamaño con al menos 1 GB de memoria. Deja la estrategia de build en Buildpacks; si el repositorio tiene un Dockerfile, el formulario selecciona Dockerfile en su lugar.
5. Conecta una base de datos y ejecuta las migraciones En la pestaña Environment, vincula una base de datos PostgreSQL de la misma región. DATABASE_URL es una URL postgres://, no una URL JDBC, así que inyecta también host, port, database, user y password con nombres propios y construye con ellos la URL JDBC, como muestra la guía de Spring Boot. Las migraciones que se ejecutan al arrancar (Flyway, Liquibase) no necesitan nada más; cualquier otro comando puede ejecutarse desde una línea release: en un Procfile, una vez por build, antes de que arranque la nueva versión.

A tener en cuenta

• MemoriaPor defecto, la JVM recibe JAVA_TOOL_OPTIONS=-XX:MaxRAMPercentage=80.0, así que el heap puede usar la mayor parte de la memoria de la instancia. Define tú JAVA_TOOL_OPTIONS para sustituirlo, o JAVA_OPTS para añadir flags al comando de arranque. La mayoría de las apps web en la JVM necesitan 1 GB o más.
• Qué jar se arrancaNodion arranca el jar más grande que esté directamente en target/ o build/libs/ y omite los jars -plain, -sources y -javadoc. En una build multimódulo, el jar ejecutable está en la carpeta de un módulo; arráncalo con una línea web: en un Procfile y pasa tú el puerto.
• Quarkus y otros frameworks-Dserver.port solo configura Spring Boot. Quarkus, Micronaut y los demás necesitan su propia configuración de puerto a partir de PORT. El fast-jar por defecto de Quarkus en target/quarkus-app/ no se detecta: arráncalo con una línea del Procfile como web: java -Dquarkus.http.port=$PORT -jar target/quarkus-app/quarkus-run.jar, o genera un uber-jar.

Lo que Nodion gestiona por ti

• Despliegues sin downtime Haz push a tu rama y Nodion construye una nueva release. El tráfico pasa a las nuevas instancias cuando superan el health check; si una release falla, la que está en marcha sigue activa. En cambio, las apps con un volumen local se reinician porque el disco pertenece a una sola instancia.
• Bases de datos junto a la app PostgreSQL, pgvector, MySQL, Valkey y ClickHouse gestionados en la misma región. Al vincular una base de datos, sus datos de conexión llegan como DATABASE_URL, REDIS_URL o CLICKHOUSE_URL.
• Previews por pull request Activa las previews: cada pull request de tu repositorio tendrá su propia app, con URL y bases de datos nuevas y vacías. Puedes crearla automáticamente o a mano. Se omiten las pull requests de forks y bots.
• Workers, cron jobs y escalado Ejecuta workers como procesos adicionales de la misma app, programa tareas en la pestaña Cron y escala cada proceso hasta 16 instancias.
• Paso de release Con buildpacks, una línea release: del Procfile se ejecuta con cada nueva build. Las apps con Dockerfile, así como los redeploys o rollbacks a una imagen anterior, usan un comando de release definido en la propia app, que además tiene prioridad sobre la línea del Procfile. En los sitios estáticos, el paso de release se ejecuta en una imagen que solo contiene los archivos generados por la build.
• Logs y métricas Logs de build, release y runtime, además de métricas de CPU, memoria, disco y red de cada instancia, en el dashboard.
• Dominios y HTTPS Un nombre de host predeterminado con HTTPS desde el primer despliegue; tus propios dominios reciben certificados automáticamente.

Para seguir leyendo

• Dockerfile vs buildpacks: ¿cuál deberías usar? Los dos convierten tu código en una imagen de contenedor. Lo que cambia es quién escribe los pasos de la build, y eso decide el control, el mantenimiento y las actualizaciones de seguridad.
• Cloud Native Buildpacks: qué son y cómo funcionan Los buildpacks convierten tu código fuente en una imagen de contenedor sin Dockerfile. Te explicamos qué son y cómo funcionan.

Java en Nodion: preguntas y respuestas