How to launch a Java or Spring Boot app on the cloud: step-by-step guide (2026)

Java hosting is not just Tomcat any more

For years, hosting Java meant a servlet container and WAR files. Modern Java apps — Spring Boot, Quarkus, Micronaut, Javalin, Dropwizard — usually ship as a single executable JAR with an embedded web server. That makes them easy to host: give the app a Java runtime, a port and its configuration, and it runs. This guide walks through it with Spring Boot, using Cloud Ninza as the worked example.

Step 1 — Pick the Java version and plan

Java apps are memory-hungry, so size by RAM. Cloud Ninza Java plans: Starter (₹3,588 a year, 768 MB RAM, 1 app), Growth (₹7,188, 1.5 GB), Business (₹10,788, 2 GB, 2 apps) and Pro (₹19,188, 4 GB, 3 apps). Prices are before GST.

Choose the OpenJDK version your app targets — 11, 17, 21 or 25. Spring Boot 3 needs Java 17 or newer; 21 is the long-term default for new projects. The JVM's heap is set to about 70% of your plan's memory automatically, leaving room for the rest of the process.

Step 2 — Make the app read its port and settings

Spring Boot reads server.port from configuration; the presets pass --server.port=$PORT on the command line, so you change nothing in code. Keep secrets out of application.properties in Git: use environment variables such as SPRING_DATASOURCE_URL, SPRING_DATASOURCE_USERNAME, SPRING_DATASOURCE_PASSWORD and SPRING_PROFILES_ACTIVE=prod, which Spring maps to properties automatically.

Step 3 — Build on the server or upload a JAR

Two routes. Build on the server: connect your repository on the Git page and choose the Spring Boot (Maven) or (Gradle) preset — the build runs ./mvnw package (or mvn) or ./gradlew bootJar, skipping tests, and the start command runs the JAR it produced. Maven and Gradle wrappers in your repository are used when present.

Or upload a built JAR: run mvn package on your computer or in CI, upload target/app.jar with the File manager and choose the Executable JAR preset. Uploading is faster for large projects and avoids building on a small plan. WAR files work when packaged as executable Spring Boot WARs and started with java -jar.

Step 4 — Database

Create a MySQL/MariaDB or PostgreSQL database on the Databases page and put its URL in SPRING_DATASOURCE_URL — for example jdbc:postgresql://localhost:5432/yourdb or jdbc:mysql://localhost:3306/yourdb. Flyway or Liquibase migrations run at startup as usual. For MongoDB, use MongoDB Atlas with the server IP 151.185.41.197/32 allowed.

Step 5 — Deploy, watch the logs, go live

Click Deploy. The output streams live — you see the build and then Spring's startup banner in Logs. With Git deployments, each push builds a new release, checks the app answers, and keeps the previous release live if it does not. Point A records for @ and www to the server IP on the Domains page; free SSL is issued automatically and renewed.

Quarkus, Micronaut and other frameworks

Presets cover Quarkus (fast-jar: target/quarkus-app/quarkus-run.jar with the HTTP port set), Micronaut (port and host set on the command line), and a generic Maven fat-JAR for Javalin, Dropwizard or Vert.x. Anything else works with a custom start command: read the port from the PORT environment variable and bind to 127.0.0.1.

What you get with Cloud Ninza Java hosting

Java hosting without running a server:

• OpenJDK 11, 17, 21 and 25, switchable per app
• Presets: Spring Boot (Maven and Gradle), Quarkus, Micronaut, executable JAR, Maven fat JAR
• Builds with Maven or Gradle on the server, or upload a JAR
• Heap sized to your plan automatically; restart on crash
• MySQL/MariaDB and PostgreSQL on the server; MongoDB Atlas by connection string
• Git deployments with health check and automatic rollback
• Environment variables, live build output, logs and restart
• Free SSL issued automatically, terminal and key-only SSH
• Servers in India, isolated accounts, from ₹3,588 a year

Troubleshooting Java deploys

The app is killed shortly after starting: it needs more memory than the plan has — reduce the heap with JAVA_TOOL_OPTIONS or move up a plan. The placeholder page still shows: the start command did not find the JAR; check the build output and the target/ or build/libs/ folder. Slow first start: Spring Boot apps take a little time to warm up; Quarkus and Micronaut start faster. Database connection refused: check the JDBC URL host (localhost) and the database user's password.

Tuning memory for Spring Boot

Spring Boot's memory use comes from the heap (your objects), metaspace (loaded classes) and thread stacks. On a hosting plan the heap is set to about 70% of the plan's memory automatically, which leaves room for the rest. If you see the app restarted under load, look at what grows: large caches, big result sets loaded at once, or many threads. Lazy initialisation (spring.main.lazy-initialization=true) reduces startup memory for apps with many beans, and keeping Hibernate's second-level cache modest helps on smaller plans.

When an app genuinely needs more, move up a plan in place — Growth gives 1.5 GB, Business 2 GB and Pro 4 GB — and the heap grows with it on the next restart.

Profiles, secrets and configuration

Use Spring profiles to keep environments apart: application.properties for defaults, application-prod.properties for production values that are not secret, and environment variables for anything secret. Set SPRING_PROFILES_ACTIVE=prod in App settings. Spring's relaxed binding maps SPRING_DATASOURCE_URL to spring.datasource.url, so any property can be set from an environment variable without code changes.

Health checks and Actuator

Spring Boot Actuator gives you /actuator/health out of the box. Expose only health publicly (management.endpoints.web.exposure.include=health) and keep everything else private. A health endpoint is useful for uptime monitors and confirms that the app, its database and other dependencies are up, not just that the process is running.

From local to live: a release routine

A simple routine keeps Java releases boring. Run the test suite and package locally or in CI. Push to the branch connected to Git deployments; the server builds with your Maven or Gradle wrapper, starts the new JAR alongside nothing else in your account, and checks it answers before switching. Database changes go through Flyway or Liquibase so the schema always matches the code that starts. If the health check fails — a missing variable, a migration error — the previous release keeps serving and you get the log by email.

For bigger changes, deploy to a second app on a subdomain first, with its own database, and switch your main domain only when it is proven. Business and Pro host more than one app, which makes a permanent staging app affordable.

Keep build times short by caching nothing you do not need and skipping tests on the server — they belong in CI, before the push.

Key takeaways

The short version, for anyone skimming:

• Modern Java ships as an executable JAR: give it a runtime, a port and its config.
• Choose OpenJDK 11, 17, 21 or 25; size the plan by memory.
• Build with Maven/Gradle from Git, or upload a JAR built in CI.
• Settings through environment variables; MySQL or PostgreSQL on localhost.
• Cloud Ninza Java hosting starts at ₹3,588 a year before GST.