Prepare your Java app for a managed VM

What this covers

We build your application from your repository and run the artefact it produces. That only works if we know exactly what to build, what it produces, how to start it, and how to tell whether it came up. Guessing any of the four produces a machine that builds and then fails to serve.

Before you start

Make sure your application builds cleanly from a fresh clone of the branch you give us — no local files, no IDE settings, no untracked configuration.

How to do it

1. Pin your JDK. Tell us 21 or 17 and set the same version in your pom.xml or build.gradle. "Latest" is not a supported answer and drifts under you.
2. Make your build produce one runnable artefact. For Maven that is usually spring-boot-maven-plugin repackage; for Gradle, bootJar.
3. Give us the exact artefact path, not a pattern. target/demo-1.0.0.jar is usable; target/*.jar is not, because a stale jar from an earlier version would match too.
4. Read the port from the environment rather than hard-coding it, so we can place the app behind our reverse proxy.
5. Expose a health endpoint that returns 200 only when the app can actually serve. Spring Boot's /actuator/health does this; a bare / that returns 200 while the database is down does not.
6. Keep secrets out of the repository. Give them to us as environment variables instead.
7. Let the JVM size its own heap from the machine, or set -XX:MaxRAMPercentage rather than a fixed -Xmx, so a later resize is actually used.

What our team checks

Support can tell you whether your artefact path and start command agree with what your build actually produces, and will check your health endpoint reports honestly before we rely on it for monitoring.