Droplets or App Platform: picking the right DigitalOcean product

DigitalOcean‘s catalogue is smaller than the hyperscalers’ by design, which makes the main decision refreshingly simple. For most applications it comes down to two products: a Droplet, which is a virtual machine you administer, or App Platform, which takes your code and runs it.

The question is not which is better. It is which operational burden you would rather carry.

What a Droplet gives you

A Droplet is a Linux virtual machine with root access. You choose the size and the image, and from that point everything above the kernel is yours: the web server, the runtime, the process manager, the TLS certificates, the firewall rules, the security updates, the log rotation, the deployment mechanism.

In exchange you get complete control and complete predictability. Nothing changes unless you change it. Anything that runs on Linux runs here. The price is fixed and easy to reason about.

The work is real but finite. A competent developer can get a production-shaped Droplet configured in a few hours, and the ongoing maintenance is measured in tens of minutes per month if you keep it simple.

What App Platform gives you

App Platform takes a repository, detects or is told how to build it, and runs the result. It handles TLS certificates, deployment on push, health checks, restarts, horizontal scaling and log aggregation. There is no operating system for you to patch because there is no operating system you can reach.

In exchange you accept a constrained environment. The runtime is what the platform supports. Long-running background work has to fit the platform’s model. Anything requiring a system-level daemon, an unusual binary, or persistent local disk needs rethinking.

For a standard web application with a managed database behind it, that constraint costs nothing, and the operational saving is substantial.

The decision, in practice

Reach for App Platform when the application is a conventional web service or API, state lives in a managed database or object storage rather than on local disk, the team would rather spend its time on the application than on the server, and deployment on git push is worth more than fine-grained control.

Reach for a Droplet when you need system-level access, when you are running something the platform does not support, when you want several services co-located on one machine for cost reasons, when you need persistent local storage, or when predictable fixed cost matters more than elasticity.

There is also an honest middle answer that people underuse: a single Droplet running containers. You keep full control and a fixed price, while getting most of the deployment convenience through a compose file and a reverse proxy. For a small team with modest traffic this is frequently the best value on offer anywhere.

Cost behaves differently

A Droplet has a fixed monthly price for a fixed amount of resource. Your bill does not change when traffic does, until you outgrow the machine.

App Platform scales with what you run, which means it can be cheaper when idle and more expensive under load. For genuinely spiky traffic that is the right shape. For steady traffic a correspondingly sized Droplet is usually cheaper.

Bandwidth allowances are attached to Droplets and pooled across your account, which is worth knowing before assuming egress is free.

What is easy to change later

Moving from App Platform to a Droplet is straightforward: your application already runs in a container-shaped way, and you are taking on more control rather than less.

Moving from a Droplet to App Platform is harder, because applications that grew on a virtual machine accumulate assumptions about the filesystem, about local services, about cron, and about things being installed. None of those survive the move without work.

If you are genuinely unsure, starting on App Platform keeps the cheaper migration direction available. If you already know you need system access, start with the Droplet and do not litigate it again.

Things people get wrong

Putting the database on the same Droplet as the application and never backing it up. Managed databases exist precisely so that backups, failover and patching are not your problem. On a small budget, co-locating is defensible; skipping backups is not.

Choosing a Droplet size from peak traffic. Start smaller than you think and resize. Resizing is quick, and DigitalOcean’s sizes are close to linear in price, so there is no discount for guessing high.

Assuming App Platform removes the need to understand deployment. It removes the mechanics, not the thinking. Build failures, environment variables and health check configuration still need attention.

Forgetting the firewall. A fresh Droplet with a database port open to the internet is discovered by scanners within hours. Configure the cloud firewall before the service starts, not after.

For the vendor’s own reference on the services involved here, see the DigitalOcean documentation.

Questions people ask