Java and Spring Boot hosting in India: a 2026 guide

How Java hosting works now

Most modern Java web apps are Spring Boot (or Quarkus, Micronaut and friends) packaged as an executable JAR with an embedded server. That changes hosting: instead of deploying a WAR into a shared Tomcat, the host runs your JAR as its own process, keeps it running, restarts it if it stops, and puts HTTPS in front of it.

On Cloud Ninza the app runs as its own user inside your account, listening on the port the platform gives it, with nginx and free SSL in front. You pick the Java version — 11, 17, 21 or 25 — and change it later from App settings.

Build from source or upload a JAR

You can upload a finished JAR, or let the platform build it. The Spring Boot (Maven) preset runs the Maven wrapper or Maven to package the app; the Gradle preset runs bootJar. The start command then runs the JAR with the right port and address. Quarkus, Micronaut and a plain executable JAR have presets too.

Presets only fill in the install, build and start commands — you can edit any of them, and what runs is exactly what is saved.

• Spring Boot with Maven or Gradle
• Executable JAR (or an executable WAR)
• Quarkus and Micronaut
• Custom start command for anything else

Memory: the setting that matters most

Java apps fail on hosting for one reason more than any other: the JVM tries to use more memory than the account allows and gets stopped. The platform sets the heap to about 70% of your plan's memory automatically, leaving room for the rest of the JVM. If your app needs more, move to a bigger plan rather than raising the heap by hand.

Check the memory ceiling on the plan card before you buy: it is the number that decides whether a Spring Boot app is comfortable.

Databases and configuration

Each plan includes MySQL/MariaDB or PostgreSQL databases. Put the connection URL, username and password in environment variables — edited as key/value pairs in the dashboard — and read them in application.properties with ${...} placeholders, so no secret sits in your code. External databases, including MongoDB Atlas, connect by connection string.

Deploy from Git with automatic rollback

Connect GitHub, GitLab or Bitbucket and every push to your branch builds the JAR in a fresh release folder, switches the app to it, checks that it answers and rolls back automatically if it does not. Earlier releases stay available, so making an older build live again is one click. Builds run on the server, so a large Maven build needs a plan with enough memory to compile.

Logs, terminal and restarts

The app's output streams into Logs in the dashboard. A browser terminal — or SSH with your key — opens a sandboxed shell in your account with Java, Maven and Git available. Start, stop and restart are buttons; touching tmp/restart.txt restarts the app for scripted deploys.

When to move to a cloud server

Managed Java hosting suits APIs, admin panels, small SaaS products and internal tools. Move to a cloud server when the app needs several gigabytes of heap, long-running batch jobs, a message broker alongside it, or root access. Cloud servers start at ₹1,073 a month, memory-intensive ones at ₹6,755.

Preparing a Spring Boot app for hosting

A few small changes make a Spring Boot app at home on managed hosting. Read the port from the environment — server.port=${PORT} — and bind to 127.0.0.1, since the platform puts nginx in front. Move the datasource URL, username and password into environment variables. Write logs to standard output, not to files in the app folder, so they appear in the dashboard's Logs. Turn on graceful shutdown so restarts during a deploy finish in-flight requests.

If the app serves file uploads, store them outside the release folder — in a shared folder or object storage — so they survive deployments.

Keeping the JVM healthy

Most Java problems on hosting are memory problems. Watch the app's memory in its status panel after a deploy and under real traffic. If it grows steadily until restart, look for caches without limits, large in-memory collections or connection pools that are too big for the plan. Keep the database connection pool small — a handful of connections is plenty for most apps on a single instance.

Startup time also matters: a slow-starting app is still starting when the health check runs. Trim unused starters and auto-configuration, and the deploy pipeline will be able to confirm the new release faster.

A simple first deployment

Create the Java app from Launch an app, choose the Java version, then open App settings and pick the Spring Boot preset for Maven or Gradle. Add your environment variables. Connect the GitHub repository under Git deployments and press Deploy. The live log shows the source, build and deploy stages; when it finishes, open the site over HTTPS. From then on, every push to the branch does the same, and a failed build leaves the previous release running.

Databases for Java apps

Spring Boot works with MySQL or MariaDB and PostgreSQL through the usual JDBC drivers; create the database from the dashboard and put its address, name, user and password in environment variables. Run schema changes with Flyway or Liquibase so each release brings its own migrations and every environment ends up the same.

If your data already lives in a managed database elsewhere, such as MongoDB Atlas, add its connection string as an external database and attach it to the app as an environment variable. For Atlas, add our server's address to the cluster's network access list first.

Scheduled jobs and background work

Small scheduled tasks can run inside the app with Spring's @Scheduled, as long as they are short and the app runs as a single instance. For tasks that should run even when the app restarts, use a cron job from the dashboard that calls a protected endpoint or runs a command. Long-running or heavy work belongs on a cloud server, where it will not compete with web requests for the plan's memory.

When to move to a cloud server

Managed Java hosting suits most business apps. Move to a cloud server when the app needs more memory than the largest plan, needs to run several instances behind a load balancer, needs software that cannot run in a hosting account, or runs heavy background processing all day. The same code moves across; only the infrastructure around it changes.

Key takeaways

The short version, for anyone skimming:

• Modern Java hosting runs your executable JAR as its own process behind HTTPS.
• Java 11, 17, 21 and 25, built from Maven or Gradle on deploy.
• Memory is the deciding limit; the heap is set to about 70% of the plan automatically.
• Secrets go in environment variables, not in application.properties.
• Java plans start at ₹3,588 a year; heavy apps move to cloud servers.