LanguageGB
App Deployment

Deploy a Java app

Spring Boot, Quarkus and Micronaut run on App Deployment like any other app: push to Git and the platform builds the jar and runs it.

What this covers

The platform clones your repository, builds it with Maven or Gradle, finds the runnable jar and starts it under systemd behind nginx. Java needs App Business or higher because a JVM sizes its heap from the memory it is given, and the entry tier's 1 GB is not enough to do useful work. Your heap follows your plan automatically — the app starts with -XX:MaxRAMPercentage=70 against the plan's cap, so upgrading gives the JVM more room on the next deploy with nothing to edit. No database is provisioned automatically.

Before you start

Your repository needs a pom.xml, build.gradle or build.gradle.kts, and your build must produce one runnable fat jar — spring-boot-maven-plugin repackage for Maven, bootJar for Gradle. Gradle's plain jar task produces a thin jar with no dependencies and, since Boot 3, no Main-Class; running it fails with “no main manifest attribute”. Read the port from the environment: the platform passes --server.port and also sets PORT. Commit your ./mvnw or ./gradlew wrapper if you use one — we prefer it over the node's own Maven and Gradle, because it pins the version your project is tested against.

How to do it

  1. Buy an App Business or App Pro plan from the Services page. App Starter refuses the Java runtime.
  2. Push your project to GitHub. In a multi-module repository, note which module holds your build file.
  3. Open Portal → Services and your App Hosting service.
  4. In the Deploy App section set Runtime to java. Spring, Spring Boot, Quarkus, Micronaut, Maven and Gradle are all accepted and all mean the same thing.
  5. Paste your repository URL and branch. For a private repository, save a GitHub token with repo scope in Deploy settings first — without it the clone fails, and GitHub answers the same way for a private repository and one that does not exist.
  6. Set App directory if your build file is not at the repository root.
  7. Set Health path — /actuator/health if you use Spring Boot Actuator.
  8. Add your environment variables, including the database connection if you have one. They persist across deploys.
  9. Click Redeploy App. The build takes a minute or two; the deploy log shows Maven or Gradle output as it runs.
  10. Every later deploy is just git push — your deploy hook rebuilds and swaps traffic only once the new release is healthy.

What our team checks

Support checks that the repository is reachable, the build file is where we looked, the build produced a runnable jar, and the app answered its health path. We can tell you which of those failed and why.

Next step

Make sure your build produces one fat jar from a clean clone, then open the deploy form and choose the java runtime.

Contact Support