Java auf Nodion deployen

Java Schritt für Schritt deployen

1. Maven- oder Gradle-Wrapper committen Mit gradlew führt Nodion ./gradlew build -x test --no-daemon aus, mit mvnw ./mvnw -B -DskipTests clean package. Eine pom.xml ohne Wrapper baut Nodion mit dem eigenen Maven. Ein Gradle-Projekt ohne gradlew scheitert: Leg den Wrapper mit gradle wrapper an und committe ihn samt Ordner gradle/wrapper. Tests laufen beim Deploy nicht, die gehören in deine CI.
2. Java-Version festlegen Ohne Angabe baut und startet Nodion mit Java 21. Eine andere Version trägst du in system.properties ein. Toolchain-Angaben in pom.xml oder im Gradle-Build liest Nodion nicht, halte sie also mit dieser Datei synchron. system.properties

   java.runtime.version=25

3. Auf PORT lauschen Nodion setzt PORT für den Web-Prozess und reicht ihn als -Dserver.port an die JVM weiter, das deckt Spring Boot ab. Andere Frameworks oder ein eigener Server lesen PORT selbst und binden an 0.0.0.0.

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

4. App anlegen Lege im Dashboard eine Application aus deinem GitHub-, GitLab-, Bitbucket- oder Gitea-Repository an, wähle Branch, Region EU Central und eine Größe mit mindestens 1 GB Arbeitsspeicher. Lass die Build-Strategie auf Buildpacks; liegt ein Dockerfile im Repository, wählt das Formular stattdessen Dockerfile.
5. Datenbank anbinden und migrieren Häng auf dem Tab Environment eine PostgreSQL-Datenbank aus derselben Region an. DATABASE_URL ist eine postgres://-URL und keine JDBC-URL: Lass dir host, port, database, user und password zusätzlich unter eigenen Namen injizieren und bau daraus die JDBC-URL, wie im Spring-Boot-Guide gezeigt. Migrationen, die beim Start laufen (Flyway, Liquibase), brauchen nichts weiter; jeden anderen Befehl führt eine release:-Zeile in einer Procfile bei jedem Build einmal aus, bevor die neue Version startet.

Gut zu wissen

• ArbeitsspeicherDie JVM bekommt standardmäßig JAVA_TOOL_OPTIONS=-XX:MaxRAMPercentage=80.0, der Heap darf also den Großteil des Speichers der Instanz nutzen. Setz JAVA_TOOL_OPTIONS selbst, um das zu ersetzen, oder JAVA_OPTS, um dem Startbefehl Flags mitzugeben. Die meisten JVM-Web-Apps brauchen 1 GB oder mehr.
• Welches Jar startetNodion startet das größte Jar direkt in target/ oder build/libs/ und überspringt -plain-, -sources- und -javadoc-Jars. Bei Multi-Modul-Builds liegt das lauffähige Jar in einem Modulordner; dann startest du es mit einer web:-Zeile in einer Procfile und übergibst den Port selbst.
• Quarkus und andere Frameworks-Dserver.port wirkt nur bei Spring Boot. Quarkus, Micronaut und andere brauchen ihre eigene Port-Einstellung aus PORT. Das Standard-Fast-Jar von Quarkus unter target/quarkus-app/ findet Nodion nicht: Starte es mit einer Procfile-Zeile wie web: java -Dquarkus.http.port=$PORT -jar target/quarkus-app/quarkus-run.jar oder bau ein Uber-Jar.

Was Nodion für dich betreibt

• Deploys ohne Downtime Push auf deinen Branch und Nodion baut ein neues Release. Der Traffic wechselt erst, wenn die neuen Instanzen ihren Health Check bestehen; ein fehlgeschlagenes Release lässt das laufende stehen. Apps mit lokalem Volume starten stattdessen neu, weil die Disk zu einer Instanz gehört.
• Datenbanken neben der App Managed PostgreSQL, pgvector, MySQL, Valkey und ClickHouse in derselben Region. Angehängte Datenbanken kommen als DATABASE_URL, REDIS_URL oder CLICKHOUSE_URL in die App.
• Previews pro Pull Request Schalte Previews ein, und Pull Requests aus deinem Repository bekommen eine eigene App mit eigener URL und frischen, leeren Datenbanken, automatisch oder per Hand angelegt. Forks und Bot-Pull-Requests werden übersprungen.
• Worker, Cron Jobs und Skalierung Worker laufen als weitere Prozesse derselben App, Jobs planst du auf dem Tab Cron, und jeden Prozess skalierst du auf bis zu 16 Instanzen.
• Release-Schritt Mit Buildpacks läuft eine release:-Zeile in der Procfile bei jedem neuen Build. Dockerfile-Apps sowie Redeploys und Rollbacks auf ein früheres Image nutzen einen Release Command, der an der App selbst gesetzt ist; er hat auch Vorrang vor der Procfile-Zeile. Bei statischen Sites läuft ein Release-Schritt in einem Image, das nur die gebauten Dateien enthält.
• Logs und Metriken Build-, Release- und Laufzeit-Logs sowie CPU-, Speicher-, Disk- und Netzwerk-Metriken für jede Instanz im Dashboard.
• Domains und HTTPS Ein Default-Hostname mit HTTPS ab dem ersten Deploy; deine eigenen Domains bekommen automatisch Zertifikate.

Weiterlesen

• Dockerfile vs Buildpacks: was solltest du nutzen? Beide machen aus deinem Code ein Container-Image. Der Unterschied ist, wer die Build-Schritte schreibt, und das entscheidet über Kontrolle, Wartung und Security-Updates.
• Cloud Native Buildpacks erklärt Buildpacks machen aus deinem Quellcode ein Container-Image ohne Dockerfile. Was sie sind und wie sie funktionieren.

Java auf Nodion: Fragen und Antworten