App Platform is DigitalOcean’s managed application layer: you point it at a repository, it builds a container and runs it, and you never see the underlying machine - which is the entire product and the entire trade-off.
The most-asked question about it is not how to use it, it is how it differs from a Droplet. That comparison is the useful one, because it is really a question about which layer of the stack you want to be responsible for, and the answer generalises far beyond one vendor.
Table of contents
- What the platform layer actually does for you
- What you give up
- The cost comparison, done honestly
- When a VM is still the right answer
- A migration path that does not hurt
- How this fits the rest of the stack
- FAQ
What the platform layer actually does for you
A Droplet is a virtual machine. You get an operating system and root access, and everything above that is yours: the runtime, the web server, the process manager, the certificates, the deploy mechanism, the updates.
The application platform layer replaces all of that with a build. You connect a repository, it detects the language or reads your Dockerfile, produces an image, and runs it behind a route with a certificate already issued. Push again and it does it again, with the previous version still available to roll back to.
- Build from a Git push, with a log for each build
- A live HTTPS route without you touching a certificate
- Environment variables as configuration rather than files on a disk
- Horizontal scaling by changing a number rather than by provisioning
- Rollback to the previous deploy when one goes wrong
None of that is magic. It is a container runtime, a build system, and a router that someone else operates. The value is entirely in the someone else.
What you give up
Three things, and it is worth being specific because the marketing pages are not.
Root access. You cannot install a system package, tune a kernel parameter, or run a daemon alongside your app unless it is in the container. For most web applications this is irrelevant. For anything that needs a system-level dependency, it is decisive.
Persistent local disk. Platform containers are ephemeral. Anything written to local disk disappears on the next deploy, which surprises people who were writing uploads to a folder. Files belong in object storage or attached persistent storage, and that is a code change if the app assumed otherwise.
Unusual process shapes. One long-running web process scales beautifully. A process that needs to be a singleton, or that coordinates with siblings, or that expects a fixed hostname, fits the model badly. Background workers are usually fine as a separate component; leader-election is not.
The cost comparison, done honestly
A platform instance costs more than an equivalently-sized VM. That is the visible number and it is the one people compare, and comparing only that number is how the decision gets made wrong.
The VM side has costs that do not appear on the invoice. Somebody configures the reverse proxy. Somebody sets up certificate renewal and finds out three months later that the cron for it stopped. Somebody writes the deploy script, and then somebody else has to understand it. Somebody applies security updates, or does not. Somebody is on the hook when the disk fills at 4am because logs were never rotated.
For a solo developer or a small team, those hours are the expensive resource and they are not fungible - they arrive as interruptions on the day you planned to ship. For a team with dedicated infrastructure people, the calculus genuinely flips, because the work is already someone’s job and the per-instance margin becomes real money at scale.
The honest framing: the platform is not cheaper, it is fewer decisions. Whether that is worth the premium depends entirely on what your time is worth and how many machines you would otherwise be running.
When a VM is still the right answer
- You need a system-level dependency the container cannot carry, or kernel access.
- You are running something that is not a web application - a game server, a mail server, a VPN endpoint, a build agent.
- You have a workload with very steady, very predictable load where the VM margin genuinely matters at your scale.
- You already have infrastructure engineers and a configuration management setup, so the marginal cost of one more machine is close to zero.
- You need to run several unrelated things on one box for cost reasons, which platforms deliberately make awkward.
Notice that none of these are about application size. Small applications belong on a platform. Large applications frequently belong on a platform too. The reason to drop a layer is a specific requirement, not a growth milestone.
A migration path that does not hurt
If you are on a VM and considering the move, the work is mostly making the application container-shaped, and that work is worth doing regardless of where you land.
- Move every piece of configuration into environment variables. No config files with secrets, no hardcoded paths.
- Move file writes out of local disk and into object storage or attached persistent storage.
- Move the database off the application server and onto a managed instance, if it is not already.
- Write a Dockerfile, or confirm the platform’s buildpack detects your project correctly.
- Deploy alongside the existing setup, test it, then move the domain.
An application that survives step one and two is portable between platforms and back to a VM. That portability is worth more than picking the right host first time, because it makes the decision reversible.
How this fits the rest of the stack
The layer decision is worth pricing rather than arguing about, and the platform side is easy to price because it is a small number of line items. The RunxBuild hosting calculator shows the service, the database, the storage, and the bandwidth separately so you can set it against a VM plus the hours it needs. RunxBuild deploys Node, Next.js, Python, Go, Ruby, Java, .NET, and Docker from a GitHub repository, with build logs, custom domains, runtime logs, rollback to a previous deploy, and autoscaling between a floor and ceiling plan you choose.
Useful related references:
- MCP Server Design for a Digital Goods Storefront
- RunxBuild vs Railway: App Platform Comparison
- RunxBuild vs Vercel: Full Cloud Comparison
- Services on RunxBuild
FAQ
What is the difference between App Platform and a Droplet?
A Droplet is a virtual machine you administer - OS, runtime, web server, certificates, deploys, updates. App Platform builds your repository into a container and runs it behind a route with a certificate, and you never see the machine. One is more control and more work; the other is fewer decisions at a higher unit price.
Can I run background workers on an application platform?
Yes, usually as a separate component in the same project - a worker process that shares the repository but has no HTTP route. What does not fit well is anything requiring singleton behaviour, leader election, or a fixed hostname, since instances are interchangeable by design.
Why do my uploaded files disappear after a deploy?
Because platform containers are ephemeral: local disk is discarded when a new version is deployed. Files need to go to object storage or attached persistent storage, with only the reference kept in your database. This is the single most common surprise when moving from a VM.
Is a managed platform more expensive than a VM?
Per instance, yes. In total, often not, once you count certificate renewal, reverse proxy configuration, deploy scripting, OS patching, and incident response. For teams with dedicated infrastructure engineers the comparison flips, because that work is already someone’s job.
How do I make my app portable between hosts?
Move all configuration into environment variables, keep no state on local disk, and put the database on a managed instance rather than the app server. An application that meets those three conditions runs on any container platform and can go back to a VM without a rewrite.