Deploy Java on Nodion

Deploy Java step by step

1. Commit the Maven or Gradle wrapper With gradlew, Nodion runs ./gradlew build -x test --no-daemon; with mvnw, it runs ./mvnw -B -DskipTests clean package. A pom.xml without a wrapper builds with Nodion's own Maven. A Gradle project without gradlew fails, so create the wrapper with gradle wrapper and commit it together with the gradle/wrapper folder. Tests are skipped during the deploy; run them in your CI.
2. Pin the Java version Without a pin, Nodion builds and runs with Java 21. Name another version in system.properties. Toolchain settings in pom.xml or your Gradle build are not read, so keep them in line with this file. system.properties

   java.runtime.version=25

3. Listen on PORT Nodion sets PORT for the web process and passes it to the JVM as -Dserver.port, which covers Spring Boot. Other frameworks, or your own server, read PORT themselves and bind to 0.0.0.0.

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

4. Create the app In the dashboard, create an application from your GitHub, GitLab, Bitbucket or Gitea repository, pick the branch, the region EU Central and a size with at least 1 GB of memory. Keep the build strategy on Buildpacks; if the repository has a Dockerfile, the form picks Dockerfile instead.
5. Connect a database and migrate Attach a PostgreSQL database from the same region on the Environment tab. DATABASE_URL is a postgres:// URL, not a JDBC URL, so also inject host, port, database, user and password under your own names and build the JDBC URL from them, as the Spring Boot guide shows. Migrations that run at startup (Flyway, Liquibase) need nothing else; any other command can run from a release: line in a Procfile, once per build before the new version starts.

Good to know

• MemoryThe JVM gets JAVA_TOOL_OPTIONS=-XX:MaxRAMPercentage=80.0 by default, so the heap may use most of the instance's memory. Set JAVA_TOOL_OPTIONS yourself to replace it, or JAVA_OPTS to add flags to the start command. Most JVM web apps want 1 GB or more.
• Which jar startsNodion starts the largest jar directly in target/ or build/libs/ and skips -plain, -sources and -javadoc jars. In a multi-module build the runnable jar sits in a module folder; start it with a web: line in a Procfile and pass the port yourself.
• Quarkus and other frameworks-Dserver.port only configures Spring Boot. Quarkus, Micronaut and others need their own port setting from PORT. The Quarkus default fast-jar in target/quarkus-app/ is not picked up: start it with a Procfile line such as web: java -Dquarkus.http.port=$PORT -jar target/quarkus-app/quarkus-run.jar, or build an uber-jar.

What Nodion runs for you

• Deploys without downtime Push to your branch and Nodion builds a new release. Traffic switches once the new instances answer their health check; a failed release leaves the running one in place. Apps with a local volume restart instead, because the disk belongs to one instance.
• Databases next to the app Managed PostgreSQL, pgvector, MySQL, Valkey and ClickHouse in the same region. Attached databases arrive as DATABASE_URL, REDIS_URL or CLICKHOUSE_URL.
• Previews per pull request Turn on previews and pull requests from your repository get their own app with its own URL and fresh, empty databases, created automatically or by hand. Forks and bot pull requests are skipped.
• Workers, cron jobs and scaling Run workers as extra processes of the same app, schedule jobs on the Cron tab, and scale every process to up to 16 instances.
• Release step With buildpacks, a Procfile release: line runs with every new build. Dockerfile apps, and redeploys or rollbacks to an earlier image, use a release command set on the app itself, which also takes precedence over the Procfile line. On static sites a release step runs in an image that holds only the built files.
• Logs and metrics Build, release and runtime logs plus CPU, memory, disk and network metrics for every instance in the dashboard.
• Domains and HTTPS A default hostname with HTTPS from the first deploy; your own domains get certificates automatically.

Further reading

• Dockerfile vs Buildpacks: Which One Should You Use? Both turn your code into a container image. What differs is who writes the build steps, and that decides control, maintenance and security updates.
• Cloud Native Buildpacks Explained Buildpacks turn your source code into a container image without a Dockerfile. What they are, and how they work.

Java on Nodion: questions and answers