Skip to content

Java hosting Spring Boot, built for you.

Push to GitHub. We read pom.xml or build.gradle, pick your Java version, build your jar with Maven or Gradle, and start it. Every deploy waits for the new version to answer before visitors see it.

Start deployingRead the guide
  • Java21 and 25
  • Builds withMaven or Gradle
  • FrameworksSpring Boot and more
  • Priced byWhat it uses

We read your code, so you don't write a build script.

Every build shows what we found and each command we ran, line by line. Anything we found, you can change in the app's settings.

FileWhat we do with it
pom.xmlMaven, and your Java version from java.version or the compiler's release. Spring Boot when it's there. We run mvn package without the tests.
mvnwMaven's wrapper: when it's in your code, we build with it, so the build uses your Maven version.
build.gradleGradle, through its wrapper gradlew, which must be in your code. build.gradle.kts works too.
tanzahost.jsonOptional: the version, system packages, and the build and start commands.

It starts the way Spring Boot expects.

We start your jar with java -jar: the one in target/ for Maven, or build/libs/ for Gradle. Spring Boot listens on 8080 by itself, which is our port.

  • Tests stay yours

    The build skips your tests, so a slow test suite never holds up a deploy. Run them in your own pipeline.

  • The right jar

    We skip the plain and sources jars Maven and Gradle also make, and start the one you can run.

  • Memory you choose

    Set the app's memory limit with a slider; Java sizes its memory to fit inside it.

Deploys that never take you down.

The new version starts beside the old one. Visitors switch only once it answers its health address, “/” unless you choose another.

  • If it fails, nothing changes

    A build or a “before going live” command that fails stops the deploy, and the version before it keeps serving your visitors.

  • Watched for five minutes

    If the new version stops by itself within five minutes, visitors go back to the previous one, and we tell you.

  • Roll back in one click

    The version before, deployed again without downtime.

Workers, tasks and a database next door.

Add what a real app needs beside its web process, each with the app's code and variables.

  • Up to 5 workers for queues and background jobs, and up to 10 scheduled tasks, as often as every minute, in UTC.
  • PostgreSQL with connection pooling, MySQL or Valkey in the same project, with their connection details added to your variables for Spring's datasource.
  • Logs live, a terminal in your browser, and the numbers for memory, processor and requests.

Java 21 and 25.

Both are long-term releases. We use the version your build file asks for, or the one you pick in the app's settings.

  • Java 25Supported
  • Java 21Recommended

New apps get Java 21 when their build file doesn't name a version.

A Java app, priced in the open.

Say a Spring Boot API holds 0.5 GB of memory and uses 3% of a processor, awake all month. You pay for that use, hour by hour, from your wallet. The limits you set cost nothing by themselves.

reading today's prices

Estimate your bill
Reading the prices

Before you push.

Step-by-step guideDeploying and rolling back
Do I need to change my code?
Usually not: Spring Boot listens on 8080. Read your database's address and password from variables, like SPRING_DATASOURCE_URL, instead of a file.
Can I use Gradle without its wrapper?
No: commit gradlew and its gradle folder, as Gradle recommends. Maven works with or without mvnw.
Where do my settings go?
Into variables, stored encrypted and given to your app when it starts and to its build. A variable like SPRING_DATASOURCE_PASSWORD wins over application.properties, as Spring Boot intends.
Does my app keep files it writes?
Only in its permanent folders, which you choose in the app's settings. Everything else is fresh on each deploy, so keep data in a database.

Push your Java app. We'll build the jar.

Start deploying