deploy java app on digitalocean: PaaS that runs your Spring Boot jar from a Git push, or a $4/mo droplet if you'd rather ssh in

There's a particular kind of frustration that hits you at 2 a.m. when your Java app works perfectly on your laptop but falls over the moment you try to put it somewhere real people can reach it. You've got a Spring Boot jar (or maybe a small Quarkus or Micronaut thing), you just want a URL that responds with something other than a connection refused error, and somehow you're now reading about ingress controllers. That gap — between "I have a working jar" and "I have a working URL" — is exactly what people mean when they search for ways to deploy java app on digitalocean. And it's a more interesting question than it looks, because the answer changes depending on what kind of night you're having.

Why this question keeps coming up

Java isn't the easiest language to deploy in 2026, and everyone knows it. A Node app is a folder and a npm start. A Go binary is one file you scp up. A Java app is a 60MB jar that wants a JVM, probably wants a database, definitely wants more than 512MB of RAM if it's Spring, and has opinions about memory limits that don't always match the container you put it in. So when someone types "deploy java app on digitalocean" into a search box, what they're really asking is: where on DigitalOcean do I put this thing, and how much of my weekend is this going to eat?

The honest answer is that DigitalOcean gives you three genuinely different paths, and the right one depends on whether you want to think about servers at all.

Path one: App Platform, where you don't manage a server

This is the path most people should probably start with. App Platform is DigitalOcean's managed PaaS — think of it as their answer to Heroku or Render. You connect a GitHub/GitLab/Bitbucket repo, point it at a Dockerfile, and it builds and runs your app for you. Spring Boot is explicitly listed in their supported frameworks, and the way it actually works is you bring a Dockerfile and App Platform treats it like any other container. So your workflow becomes: git push, App Platform builds the image, runs it, gives it a hostname, handles TLS, and you go to bed.

The thing that makes this pleasant for Java specifically is that you don't have to argue with anyone about how much heap the JVM gets — you pick the container size, and that's your memory budget. There's no SSH, no systemd unit file, no apt install openjdk-21-jre-headless at 3 a.m. If your app crashes, the platform restarts it. If you want a database, there's a one-click dev database (PostgreSQL, 512 MiB, $7/mo) or you can attach a full managed Postgres/MySQL/Redis.

If you want to try this without committing money, the entry point is the Free Tier at $0/month — though be honest with yourself: the free tier is for static sites, and a Spring Boot app is not a static site. The smallest paid container that will actually run a non-trivial Java app is the $5/month shared instance (1 vCPU, 512 MiB RAM, 50 GiB transfer). It will run a small Spring Boot service, but 512 MiB is tight for Spring — most people jump straight to the $10/month plan (1 vCPU, 1 GiB, 100 GiB transfer), which is the realistic starting point for a Java backend that isn't constantly fighting the garbage collector. From there it scales up cleanly: $12/mo gets you autoscaling-eligible shared resources, $25/mo is 2 vCPU / 2 GiB, $50/mo is 2 vCPU / 4 GiB. Bandwidth is bundled per container and overage is $0.02/GiB, so there are no surprise egress bills.

Want to kick the tires before you commit? New accounts opened through the referral program currently come with promotional credit — historically $200 valid for 60 days, though the exact amount and window DigitalOcean offers can change, so confirm the current figure on the signup page. Either way it's enough to run a real Java app for a month and decide if the platform fits you. 👉 Claim your DigitalOcean sign-up credit and try App Platform free

What you get on the free tier vs. paid

• Free Tier ($0/mo): 3 static-site apps, 1 GiB transfer each, automatic HTTPS, custom domain, global CDN, DDoS mitigation, unlimited team members. Great for a React frontend or a Hugo blog. Not where your Java backend lives.

• Paid tier (from $5/mo): everything in Free, plus container deploys, shared and dedicated CPU, horizontal and vertical scaling, CPU-based autoscaling (on dedicated instances), automatic OS patching, log forwarding, high availability, dedicated egress IP, dev and production databases, up to 10 revisions for rollback. This is where Spring Boot actually runs.

One detail worth knowing: autoscaling is only available on dedicated instances, not shared ones. Shared instances are fine for low-traffic sites and internal tools, but if your Java app is customer-facing and you want it to scale on its own during traffic spikes, you'll want a dedicated container.

Path two: Droplets, when you want the keys to the car

App Platform is the easy button, but a lot of Java developers don't actually want an easy button — they want a Linux box they understand. If that's you, a Droplet is the move. A Droplet is just a regular virtual machine, billed per second with a 60-second minimum, and you can have it running Ubuntu in roughly the time it takes to fill in a hostname.

The appeal here is full control. You ssh in, install your JDK (apt install openjdk-21-jre-headless is one line), drop your jar on the box (scp, rsync, whatever), write a systemd unit so it starts on boot and restarts on crash, point nginx at it for TLS, and you're done. It's more work than App Platform, but it's also more legible — when something breaks, you understand exactly which layer broke because you configured every layer yourself. For a Java shop that already has deployment scripts, an Ansible playbook, or a Docker Compose setup, a Droplet is often a more natural fit than a PaaS.

Pricing starts at $4/month for the smallest Basic Droplet (shared vCPU, 512 MiB, 50 GiB SSD, 500 GiB transfer). For a real Spring Boot service you'll outgrow that immediately — $6/mo gets you 1 GiB RAM, $12/mo gets you 2 GiB, and a comfortable production baseline for a single Java service is around the $24/mo tier (2 vCPU, 4 GiB, 4 TiB transfer). Basic Droplets are shared CPU and ideal for bursty low-to-medium load; for steady production traffic, General Purpose or CPU-Optimized Droplets give you dedicated cores and fewer noisy-neighbor surprises.

The cheapest way to find out which side of that fence you're on is to spin one up with the new-user credit and break things for a weekend. 👉 Get started on DigitalOcean with referral credit and spin up your first Droplet

Path three: Kubernetes, when you've outgrown both

If you're deploying more than a couple of Java services, or you're already containerizing everything, DigitalOcean Kubernetes (DOKS) is the third option and the one people tend to graduate to. You bring your Docker image (built locally or pushed to the DigitalOcean Container Registry), write a Deployment and a Service, and DOKS handles scheduling, rolling updates, and scaling. It's the most powerful of the three and also the most work — you're writing YAML and learning a control plane — so it only makes sense once you have a real reason, like multi-service architecture, team-based deploys, or autoscaling across several apps. The good news is your Java Dockerfile is the same one App Platform would run, so nothing you've built is wasted if you move up later.

So which one should you pick

A rough way to think about it:

• Solo developer, side project, small startup, "I just want it online" → App Platform, start at the $10/mo container.

• Existing deployment scripts, comfort with Linux, want to control cost exactly → Droplet, start at $12–24/mo.

• Multiple Java services, team, autoscaling across apps, you're already writing Helm charts → DigitalOcean Kubernetes.

The nice part is that all three sit on the same account, share the same networking, and can talk to the same managed databases — so you can start your Java backend on a Droplet, move it to App Platform when you're tired of patching the OS, and lift it into Kubernetes the day you actually need to scale, without re-architecting anything. The Dockerfile you wrote once follows you up the ladder.

A practical Spring Boot walkthrough on App Platform

If you're going the PaaS route, the actual steps are short enough to list:

1. Push your Spring Boot project to GitHub with a Dockerfile in the root. A typical one is a multi-stage build — maven:3.9-eclipse-temurin-21 for the build stage, eclipse-temurin:21-jre-jammy for the runtime, EXPOSE 8080, CMD java -jar /app.jar.

2. Open the App Platform create page and pick your repo as the source.

3. Pick a container size. For a first deploy, the $10/mo 1 GiB shared instance is the sweet spot — Spring Boot's JVM overhead fits, and you're not paying for capacity you don't need yet.

4. Set environment variables. Database URL, secrets, anything you'd put in application.properties. Mark the sensitive ones as encrypted.

5. (Optional) Attach a dev database. $7/mo, 512 MiB Postgres, lives with the app. Fine for staging; switch to a managed database for production.

6. Deploy. First build takes a few minutes; subsequent pushes are faster. You get a *.ondigitalocean.app URL with HTTPS out of the box.

7. Point your custom domain at it if you want — DNS is handled in the same panel, certs are auto-renewed.

That's the whole loop. The thing that surprises people who've only ever deployed Java to a hand-built VM is that there's no apt install, no systemctl, no nginx config, no certbot. You write a Dockerfile once, and from then on git push is your deploy command.

Worth knowing before you commit

A few honest caveats from people who've run Java on DigitalOcean for a while:

• Memory. Spring Boot really wants at least 1 GiB to be happy. The $5/mo 512 MiB container will run a tiny service, but you'll spend time tuning -XX:MaxRAMPercentage and you'll still occasionally get OOM-killed during startup. Skip it unless your app is genuinely small.

• Build minutes. App Platform builds your Docker image for you, and Java builds aren't instant. Builds themselves aren't billed as a separate line item, but each push rebuilds, so structure your Dockerfile so that the dependency-resolution layer is cached and your code changes don't invalidate it.

• Cold starts. Containers on shared instances can take a few seconds to come up after a scale-out event. For an internal API that's fine; for a user-facing endpoint with strict latency budgets, look at dedicated instances or keep a warm minimum.

• Droplets bill per second. If you destroy a Droplet the same day you created it, you pay cents, not a month. That makes it almost free to prototype, but it also means a Droplet you forgot about will quietly bill you forever — set a billing alert.

• The credit is a trial, not a perpetual discount. The new-user credit is meant to let you evaluate the platform; once it's spent or expired, you're on the meter. Plan your monthly cost as if the credit weren't there.

The short version

If you came here searching for how to deploy a Java app on DigitalOcean, the practical answer is: there are three doors, and the middle one — App Platform — is the one most people walk through. You write a Dockerfile (which you probably already have, or can write in 20 lines), you push to GitHub, you pick a $10/mo container, and you're done. If you'd rather have a real Linux box, a $12–24/mo Droplet does the job and gives you the keys. If you're running a fleet of services, DOKS is waiting upstairs. The reason the search keeps happening isn't that the answer is complicated — it's that the three options are genuinely different tools for genuinely different nights, and DigitalOcean is one of the few clouds where all three live under one roof and one bill.

If you want to see which one fits your Java app, the cheapest way to find out is to open an account with the referral credit and try both the App Platform path and a Droplet over a weekend. The credit covers the experimentation; what you decide to keep running after that is up to you. 👉 Start your Java deployment on DigitalOcean with sign-up credit