DigitalOcean App Platform vs Droplet Pricing and Where Each One Wins

DigitalOcean sells two ways to run the same web application. App Platform is a managed platform: you point it at a repository, it builds a container and runs it, and you pay per component per month. A Droplet is a virtual machine: you pay for the machine and everything on it is yours to install and maintain. The pricing models are different enough that the cheaper option changes as an application grows, and the crossover is not where most comparisons put it.

Every figure below was read from DigitalOcean's own pricing and documentation pages in September 2026. Rates change, so check them before you commit a budget.

DigitalOcean App Platform pricing

App Platform bills each component separately. A shared CPU web service starts at $5 a month for 1 vCPU and 512 MiB, a development database is $7, and a production managed Postgres or MySQL starts at $15.15. Static sites are the exception: three are included at no cost, and additional ones are $3 each.

The detail that drives the arithmetic: the transfer allowance comes with each container instance, so an app with a web service and two workers gets three allowances but also pays three fees. A queue worker that sits idle most of the day costs the same as one that is busy.

Droplet pricing for the same workload

A Droplet is one fee for the whole box. Shared CPU Droplets run $4 for 1 vCPU and 512 MB, $6 for 1 GB, $12 for 2 GB, $18 for 2 vCPU and 2 GB, $24 for 2 vCPU and 4 GB, $48 for 4 vCPU and 8 GB, and $96 for 8 vCPU and 16 GB. Whatever fits in that memory runs at no extra charge: the web application, its queue workers, its scheduler, Redis, and the database if you are willing to host it yourself.

That is the real difference. On App Platform a queue worker is a line on the invoice. On a Droplet it is a Supervisor process that uses memory you already paid for. The Droplet also comes with a far larger transfer allowance, so the $0.02 per GiB overage that catches busy App Platform apps rarely applies.

The cost that does not appear on the DigitalOcean invoice is the work. Someone has to install the stack, keep the operating system patched, renew certificates, keep queue workers alive and deploy without dropping requests. Either that person is on your payroll or you buy a panel. DeployManage does that job from $59 a month on Starter for 3 servers, $129 on Growth for 10 servers with atomic releases and rollback across 10 team members, and $299 on Business with no limits. Every comparison below adds the panel fee to the Droplet column, because pretending the work is free is how these comparisons usually go wrong.

Is App Platform cheaper than a Droplet?

For one or two simple applications, yes, and clearly so. Once an application has several components, or every client needs an isolated managed database, the Droplet becomes much cheaper. Five worked bills, using the rates above.

Read down the right hand column and the pattern is clear. App Platform wins on cash at small scale by a wide margin, and the gap narrows steadily as components multiply. The crossover in these examples lands somewhere around ten apps with a single worker each. Push past that, give each client its own database, or add a second worker per app, and the per component model overtakes the flat one decisively.

Two adjustments will move the crossover for your own numbers. If you have the skills to run the database on the Droplet yourself, every $15.15 managed database disappears from the right hand column and the crossover arrives much earlier. If you are one developer with one app, the panel fee dominates and App Platform is simply the right answer.

What App Platform cannot do

App Platform containers have no persistent filesystem and no SSH access. DigitalOcean's own documentation is blunt about the first: data in the host instance's local filesystem is permanently lost after deployments and other container replacements, and the guidance is to put user uploads in Spaces object storage or a managed database. The local filesystem is capped at 4 GiB and exists only for the life of the container.

On SSH the documentation is equally direct: you cannot open SSH or SFTP ports on App Platform containers, and code changes have to go through your repository or a container image. That rules out a whole category of ordinary maintenance, from running a one-off Artisan command against production to reading a log file that the platform did not forward.

Other limits worth knowing before you migrate: builds time out after an hour, the default deployment timeout is 30 minutes, and an app can scale to 250 containers with fixed scaling or 100 with request based autoscaling. Build machines get 8 CPU cores, 15 GiB of memory and 24 GiB of disk, and DigitalOcean recommends keeping images under 1 GiB.

None of that is a flaw. It is the trade an application platform makes, and for a stateless API or a marketing site it costs you nothing. It matters when your application writes to disk, needs a PHP extension the buildpack does not ship, runs a long import, or has to be poked at by a human during an incident.

What a Droplet costs you in work, not money

The honest case against the Droplet is not the invoice. It is that the machine becomes yours. Security updates, certificate renewal, PHP upgrades, Supervisor configuration for the queue, a firewall, log rotation and a deploy process that does not serve half updated code are all now jobs someone owns. A panel handles the mechanics, but the knowledge still has to live somewhere a second person can find it at two in the morning.

That is the part teams underestimate. The runbook ends up split across a wiki page, a pinned Slack message and one engineer's memory, and the on-call developer who did not write any of it has to reconstruct it under pressure. Teams past about five people usually fix that with a tool that can search every internal document and chat thread at once rather than with another wiki nobody updates. It is a small investment next to the cost of a bad hour on a production box.

If you would rather the mechanics were not yours at all, that is a legitimate reason to pay App Platform's per component premium, and no amount of arithmetic changes it.

Should I use App Platform or a Droplet?

Use App Platform when the application is small and stateless, you have fewer than roughly five components in total, and nobody on the team wants to own a server. Use a Droplet when you need root, a writable disk, custom extensions, many applications on shared capacity, or a database per client.

Three concrete decision rules that hold up in practice:

• Count the components, not the apps. Every web service, worker and database is a separate monthly fee on App Platform. Four components is $35 to $45. On a Droplet those four things share one $24 box.
• Check whether anything writes to disk. User uploads, generated PDFs, image derivatives and file based caches all need Spaces on App Platform, which is another service and another integration to build.
• Ask who is on call. If the answer is nobody, the Droplet's cheaper invoice is a bad trade unless you buy a panel with it.

If you land on Droplets, the work after that is standard: size the box, install the stack the same way every time, and deploy without downtime. Our deploy to DigitalOcean page covers provisioning and deploys from a Git push, the DigitalOcean pricing breakdown prices Droplets, volumes, load balancers and bandwidth against each other, and hosting multiple websites on one server explains how far a single Droplet stretches before you need a second. If you have already decided to leave, our DigitalOcean App Platform alternative page maps each component to its Droplet equivalent and lists the migration steps. Teams coming from a platform and wanting the release model back should read zero downtime deployment.