Spring Boot auf Nodion deployen

Spring Boot Schritt für Schritt deployen

1. Wrapper behalten und Java festlegen Projekte aus dem Spring Initializr bringen mvnw oder gradlew schon mit. Nodion führt ./mvnw -B -DskipTests clean package oder ./gradlew build -x test --no-daemon aus und startet das größte Jar in target/ oder build/libs/, das -plain-Jar von Gradle bleibt außen vor. Gradle ohne Wrapper scheitert; Maven ohne Wrapper baut Nodion mit dem eigenen Maven. Die Java-Version kommt aus system.properties (Standard 21), nicht aus der Toolchain in deiner Build-Datei. system.properties

   java.runtime.version=21

2. Actuator für den Health Check einbinden Der Traffic wechselt erst, wenn der Health-Check-Pfad mit 2xx oder 3xx antwortet, und der Standardpfad / liefert in vielen Spring-Boot-Apps 404. Bind Actuator ein (in Gradle: implementation 'org.springframework.boot:spring-boot-starter-actuator') und trag in den App-Einstellungen /actuator/health als Health-Check-Pfad ein. pom.xml

   <dependency>
     <groupId>org.springframework.boot</groupId>
     <artifactId>spring-boot-starter-actuator</artifactId>
   </dependency>

3. Datasource auf eigene Variablen zeigen lassen Spring Boot erwartet eine JDBC-URL und liest DATABASE_URL nicht, das ist eine postgres://-URL. Verweise in application.properties auf eigene Variablen und nimm den PostgreSQL-Treiber org.postgresql:postgresql als Runtime-Dependency auf. Nodion füllt die Variablen, wenn du im nächsten Schritt die Datenbank anhängst. application.properties

   spring.datasource.url=jdbc:postgresql://${DB_HOST}:${DB_PORT}/${DB_NAME}
   spring.datasource.username=${DB_USER}
   spring.datasource.password=${DB_PASSWORD}

4. App anlegen und PostgreSQL anhängen Lege eine Application aus deinem Repository in der Region EU Central mit mindestens 1 GB Arbeitsspeicher an, dann eine PostgreSQL-Datenbank in derselben Region. Beim Anhängen auf dem Tab Environment lässt du host, port, database, user und password als DB_HOST, DB_PORT, DB_NAME, DB_USER und DB_PASSWORD injizieren. Sie kommen beim nächsten Deploy an.
5. Pushen und deployen Jeder Push auf den Branch baut ein neues Release. Flyway- oder Liquibase-Migrationen laufen beim Start der neuen Version, bevor sie den Health Check besteht; bis dahin bedient die laufende Version weiter, halte Migrationen also kompatibel zum alten Code.

Gut zu wissen

• ArbeitsspeicherPlane 1 GB oder mehr pro Instanz ein. Die 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, um das zu ersetzen, oder JAVA_OPTS, um dem Startbefehl Flags mitzugeben.
• Spring SecurityDefinierst du eine eigene Security Filter Chain, gib /actuator/health ohne Login frei. Eine 401 oder 403 auf dem Health-Check-Pfad wird nie bereit, und nach 10 Minuten wird das Release abgebrochen, während die alte Version weiterläuft.
• Multi-Modul-ProjekteNodion sucht Jars nur direkt in target/ und build/libs/ des Base Directory. Entsteht das Boot-Jar in einem Modulordner, startest du es mit einer Procfile-Zeile und übergibst den Port selbst, zum Beispiel web: java -Dserver.port=$PORT -jar app/build/libs/app.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

• Heroku-Alternativen mit EU-Hosting: 5 Optionen im Vergleich Eine deutsche Plattform und US-Clouds mit EU-Regionen, verglichen nach Sitz, Regionen und Managed Databases.
• 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.

Spring Boot auf Nodion: Fragen und Antworten