Deploy by framework

Spring Boot

Build a Spring Boot executable JAR and run it in a managed Java container.

Nitroship detects Spring Boot from spring-boot in pom.xml or the org.springframework.boot plugin in build.gradle or build.gradle.kts. The managed preset builds an executable JAR and runs it on compute with a pinned Temurin JRE.

Deploy

Install the CLI

curl -fsSL https://nitroship.co/install.sh | bash
ntro login

Already installed? Skip ahead. Full options, PATH setup, and updates: Install the CLI.

Choose a compute region; there is no default. Select Spring Boot explicitly in the deployment root:

nitroship.json
{
  "build": {"framework": "spring-boot"},
  "compute": {"regions": ["kr-icn"]}
}
ntro apps create my-spring-app
ntro deploy . --prod

This preset requires the hosted builder. Remove --local from your deploy command. After deploying, open an application route at the URL printed by the CLI.

Build and Java version

Commit the project manifest. If your project uses a build wrapper, commit mvnw or gradlew and its wrapper files too: wrappers take precedence. Without a wrapper, the generated build uses a pinned Maven or Gradle toolchain image.

  • Maven runs ./mvnw -B -DskipTests package, or mvn -B -DskipTests package without a wrapper, and reads JARs from target/.
  • Gradle runs ./gradlew --no-daemon bootJar, or gradle --no-daemon bootJar without a wrapper, and reads JARs from build/libs/.

The build requires exactly one runnable JAR after excluding *-plain.jar, *-sources.jar, and *-javadoc.jar. Several output JARs need a custom Dockerfile to choose the server. WAR deployments and multi-module layouts that do not produce a single executable JAR in these folders are not handled by this preset.

Java version selection reads Maven's java.version, maven.compiler.release, or maven.compiler.source; for Gradle it reads Java toolchain or source/target compatibility declarations. .tool-versions is the fallback. The build selects pinned supported toolchain/base versions nearest the declaration, or stable defaults when none is declared.

Runtime and static files

The final image contains /app/app.jar and starts it with Java, setting --server.port=$PORT and using 3000 when PORT is unset. Keep the application's listening address on 0.0.0.0; do not override server.address to localhost.

This preset does not extract static resources from the JAR to the CDN. Spring serves its packaged CSS, JS, images, pages, and APIs through compute. If you need CDN-hosted static assets, use your own Dockerfile with a public-only directory and build.outputDirectory. That directory must exclude Java source, secrets, and server artifacts; the custom Dockerfile guide explains image extraction and URL paths.

Environment and persistence

Use Environment variables for production profiles and secrets. For example, set SPRING_PROFILES_ACTIVE when your app uses a production profile, and SPRING_DATASOURCE_URL, SPRING_DATASOURCE_USERNAME, and SPRING_DATASOURCE_PASSWORD for a Spring-configured datasource. DATABASE_URL is not automatically converted into datasource settings; use it only if your project reads it. Connect to an external database.

Generated images run as a non-root user. The instance filesystem is ephemeral; use /tmp for temporary files and JVM temporary writes. Store uploads in S3 or other object storage, not inside the image.

Nitroship does not automatically run migrations, queue workers, or schedulers. Run migration tooling in CI or locally against the external database. If your app runs Flyway or Liquibase during startup, that is your application's behavior, not a platform migration step; coordinate it deliberately. Run workers separately and use Cron jobs for scheduled HTTP work rather than relying on an in-process scheduler.

Framework selection and Dockerfile escape hatch

build.framework: "spring-boot" explicitly selects this preset and overrides an automatically discovered Dockerfile. It cannot coexist with build.dockerfile.

Without an explicit framework, Nitroship detects the build as described in How Nitroship chooses a build. For custom JAR selection, WARs, native images, OS packages, or different static handling, remove build.framework and use your own Dockerfile.

On this page