DigitalOcean Droplets Explained: What They Are, How to Set One Up, and What They Cost

When a Java service is ready for the internet, someone has to decide where it runs. A managed platform hides the details but can cost more and limit what you control. A bare virtual machine gives you full control but asks you to handle the operating system, security, and deployment yourself. DigitalOcean's Droplets sit in the middle: a virtual machine you can create in under a minute, with a predictable price and a small set of concepts to learn.

This guide explains what a Droplet is, walks through creating and hardening one, shows how to run a Spring Boot service on it, and breaks down the cost.

What Is a Droplet?

A Droplet is a Linux (or Windows) virtual machine running on DigitalOcean's infrastructure. From your point of view it behaves like any server: it has a public IPv4 address, a root disk, memory, vCPUs, and a network interface. You SSH into it, install software, and run your processes.

Three properties make Droplets practical for backend teams:

  • Fast provisioning: you pick an image, a size, a region, and an SSH key, and the machine boots in about a minute.
  • Predictable billing: each plan has a fixed monthly price, and newer configurable sizes are billed hourly with no monthly usage cap.
  • Simple networking: each Droplet gets a public address, and you can attach a Cloud Firewall, a Reserved IP, or a Load Balancer as your needs grow.

Compared with a managed Kubernetes cluster or an App Platform deployment, a Droplet asks more of you operationally, but it gives you the same tools you would use on any Linux server.

Choosing the Right Size

The sizing decision comes down to memory first. The JVM is memory hungry, so a 512 MiB Droplet is suitable only for experiments, not for Spring Boot. A reasonable starting point for a single service with a modest workload is:

  • 1 vCPU and 1 GB RAM: a quick test environment or a small internal tool
  • 2 vCPU and 2 to 4 GB RAM: a production service with a database running on another host
  • 4 vCPU and 8 GB RAM or more: several services, a database, or a message broker on the same machine

Give the JVM an explicit heap, for example -Xmx1g on a 2 GB Droplet, so the operating system keeps room for its own processes and the page cache.

Creating a Droplet

You can create a Droplet from the control panel or from the command line with doctl. The control panel flow looks like this:

  1. Choose an Ubuntu LTS image, which is the most common base for Java workloads.
  2. Pick a region close to your users.
  3. Select a plan and size.
  4. Add your SSH public key. Avoid password authentication from the start.
  5. Set a hostname and optional tags, then create the Droplet.

With doctl, the same steps look like this:

doctl compute droplet create orders-api-01 \ --region nyc3 \ --image ubuntu-24-04-x64 \ --size s-2vcpu-2gb \ --ssh-keys "$SSH_KEY_FINGERPRINT" \ --tag-names api,production \ --wait

Once the Droplet is running, note its public IP address and connect:

ssh root@203.0.113.10

First Hardening Steps

A fresh Droplet is exposed to the internet, so harden it before installing anything else.

Create a regular user and give it sudo rights:

adduser deploy usermod -aG sudo deploy rsync --archive --chown=deploy:deploy ~/.ssh /home/deploy

Disable password login and root SSH in /etc/ssh/sshd_config:

PasswordAuthentication no PermitRootLogin no

Then reload SSH and open only the ports you need with the built-in firewall:

sudo systemctl reload ssh sudo ufw default deny incoming sudo ufw default allow outgoing sudo ufw allow OpenSSH sudo ufw allow 80/tcp sudo ufw allow 443/tcp sudo ufw enable

Keep the application port, for example 8080, closed to the internet. Only nginx should reach it. Also enable automatic security updates with sudo apt install unattended-upgrades.

Installing Java and Running a Spring Boot Service

Install a JDK and create a directory for the application:

sudo apt update sudo apt install -y openjdk-21-jre-headless sudo mkdir -p /opt/orders-api sudo chown deploy:deploy /opt/orders-api

Copy the built JAR to the server from your machine:

scp target/orders-api-1.0.0.jar deploy@203.0.113.10:/opt/orders-api/app.jar

Run it as a systemd service so it restarts on failure and starts on boot. Create /etc/systemd/system/orders-api.service:

[Unit] Description=Orders API After=network.target [Service] User=deploy WorkingDirectory=/opt/orders-api ExecStart=/usr/bin/java -Xms512m -Xmx1g -jar /opt/orders-api/app.jar Environment=SPRING_PROFILES_ACTIVE=prod Environment=SERVER_PORT=8080 Restart=on-failure RestartSec=5 [Install] WantedBy=multi-user.target

Enable and start it:

sudo systemctl daemon-reload sudo systemctl enable --now orders-api sudo systemctl status orders-api curl -s http://127.0.0.1:8080/actuator/health

Because the service listens on 127.0.0.1 behind nginx, you can apply the same reverse proxy pattern covered in our earlier article on nginx.

Backups, Monitoring, and Snapshots

Droplets offer optional backups and snapshots. Backups are automatic copies taken on a schedule, and they are billed as a percentage of the Droplet price, so a 20 percent weekly or 30 percent daily charge is a meaningful line item to plan for. Snapshots are manual images you take before risky changes, and they are billed by storage size.

For application logs, rely on journalctl -u orders-api at first, then forward logs to a central system when you scale out. Use the DigitalOcean monitoring graphs for CPU, memory, and disk, and set alerts on memory pressure, since a JVM that starts swapping will degrade quickly.

What Does a Droplet Cost?

Pricing changes, so always verify the current numbers on DigitalOcean's pricing page before you commit. At the time of writing, the entry point is small:

  • Basic Droplets start at about $4 per month for 512 MiB of memory, with the price rising with memory and vCPUs. A 1 GB plan is around $6 per month.
  • Bandwidth on bundled plans includes a generous transfer allowance. Outbound traffic beyond that is billed per GiB, typically around one cent per GiB.
  • Backups add a percentage of the Droplet price, and snapshots are billed by storage.
  • Configurable v5 Droplets let you pick vCPU, memory, and storage separately and are billed by the hour, with no monthly usage cap.

As a rough estimate, a 2 vCPU, 2 GB Droplet with weekly backups is a modest monthly bill, while a comparable managed platform often costs several times more. The trade-off is that you are responsible for patching, security, and deployment. Factor that operational time into the comparison.

Common Mistakes

  • Choosing too little memory. A JVM service on 512 MiB will be killed by the kernel under load. Start at 2 GB for production.
  • Leaving the application port open. Bind to localhost and expose only 80 and 443.
  • Skipping backups. Snapshot before upgrades, and test restoring them once.
  • Running as root. Use a dedicated user with the minimum permissions.
  • Ignoring time zones and clocks. Keep the system clock synchronized with timedatectl so logs and certificates behave predictably.

Best Practices Checklist

  • Use SSH keys, disable password login, and disable root login.
  • Enable the firewall and expose only the ports nginx needs.
  • Run the JVM under systemd with Restart=on-failure.
  • Set an explicit heap size that leaves room for the operating system.
  • Use tags and a consistent naming scheme for every Droplet.
  • Take a snapshot before every risky change and verify backups periodically.
  • Review your bill monthly, including backups, bandwidth, and reserved IPs.

Conclusion

A Droplet is the simplest way to run a production Java service on DigitalOcean with full control over the server. It takes a little more operational work than a managed platform, but the setup is short, the pricing is transparent, and the skills transfer to any Linux server you will run in the future. Start with a small plan, harden it, deploy your service under systemd, and grow the size as your workload demands.

Key takeaways

  • A Droplet is a Linux virtual machine you fully control.
  • Size for memory first, because the JVM needs room.
  • Harden access with SSH keys, a firewall, and a non-root user.
  • Run Spring Boot under systemd behind nginx.
  • Budget for backups and bandwidth, not just the base plan price.