DigitalOcean and Heroku: How the Two Deployment Models Actually Differ

DigitalOcean and Heroku sit at opposite ends of the same problem. Heroku is a buildpack platform: push a repo, the platform decides how to build and run it, and you never see the machine. DigitalOcean started as the machine and grew a managed application layer on top, so you can take either path. The practical difference is not features but how much of the runtime you are responsible for, and that decision is much harder to reverse than it looks.

Almost every comparison of these two is really a comparison of PaaS against IaaS with two brand names attached. That framing is more useful than a feature grid, because the feature grids change every quarter and the underlying model has not moved in a decade.

Table of contents

• The core split: a managed process versus a machine you own
• Buildpacks, Procfiles and what actually gets built
• Where state lives, and the filesystem trap
• Databases and the add-on model
• How the pricing models differ in shape
• Which model fits which team
• How this fits the rest of the stack
• FAQ

The core split: a managed process versus a machine you own

On a buildpack platform, the unit of deployment is a process. You declare what commands should run, the platform builds an image, schedules it somewhere, gives it a port and a hostname, and restarts it when it dies. You do not choose the kernel, the base image, the init system or the patch schedule.

On a virtual machine, the unit of deployment is a server. You get an operating system and root access. Everything above that is yours: the runtime, the reverse proxy, the process supervisor, the certificate renewal, the firewall rules, the security updates.

Both approaches ship working software. They differ in where the work lives:

• Buildpack platform: less setup work, less control, and a hard ceiling when your app wants something the buildpack does not support.
• Virtual machine: total control, and a permanent low-level operational tax that never fully goes away.
• Managed application layer on top of a VM provider: a middle path that behaves like the first until you need to drop down to the second.

The middle path is where most of the industry has landed, and it is why the comparison is less stark than it was five years ago.

Buildpacks, Procfiles and what actually gets built

The buildpack model is worth understanding on its own terms because it has outlived the platform that popularised it. A buildpack inspects the repository, detects the language, installs the runtime, resolves dependencies and produces a runnable image without a Dockerfile.

web: node server.js
worker: node jobs/queue.js
release: npx prisma migrate deploy

That file is the entire deployment configuration for a lot of applications. The web process gets a port and public traffic, the worker process gets neither, and the release command runs before the new version takes over.

The convention it enforces is genuinely good practice: configuration in the environment, no writes to the local filesystem, processes that can be killed and restarted at any moment, logs to stdout. Applications written to that discipline are portable almost by accident.

The cost is the ceiling. A system dependency the buildpack does not know about means dropping to a container image anyway, at which point the simplicity you paid for is gone and you are managing a Dockerfile inside a platform that would rather you did not.

Where state lives, and the filesystem trap

This is the difference that catches people, and it catches them in production rather than in staging.

Managed process filesystems are ephemeral. Anything written to disk survives until the next deploy or restart, which on most platforms happens at least daily, and is not shared between instances. An upload handler that writes to a local directory works perfectly in testing, works perfectly on one instance, and silently loses files the moment there are two.

On a virtual machine, the disk is a real disk. Files persist, which solves the upload problem and creates a different one: that disk is now stateful infrastructure you have to back up, monitor and grow.

The resolution is the same on both: user uploads belong in object storage, sessions belong in a database or a cache, and the application filesystem should be treated as scratch space even when it is not. Teams that adopt that rule early can move between the two models freely. Teams that do not are stuck on whichever one they started with.

Databases and the add-on model

Buildpack platforms historically attached everything through an add-on marketplace: provision a database, get a connection string injected as an environment variable, never think about it again. It is a genuinely good developer experience and it has one structural consequence worth naming.

The add-on is a separate vendor relationship with separate limits. Connection caps, storage caps and backup retention are set by the add-on tier rather than by your application’s needs, and the failure mode is a connection-limit error at exactly the traffic level where you least want to be reading documentation.

Managed databases from the infrastructure provider behave differently. They are provisioned as first-class resources with their own sizing, they sit inside a private network with the application, and they are usually reachable from outside that network only if you explicitly allow it.

The practical questions to ask, whichever model you pick:

• How many concurrent connections does the tier allow, and does the application pool them?
• Are backups automatic, and has anyone tested a restore?
• Does traffic between the app and the database leave the private network?
• What happens to the connection string when the database is resized?

How the pricing models differ in shape

Specific prices change constantly and any number quoted here would be wrong within a quarter, so the useful comparison is structural.

A process-based platform bills per running process per unit of time. Scaling means running more processes, and the bill is roughly linear in the number of them. Add-ons are separate line items with their own tiers, so the total is the sum of a handful of independent ladders. Costs are predictable per unit and tend to surprise people in aggregate, because nobody adds the ladders up until the invoice arrives.

A machine-based provider bills per machine per hour, plus storage, plus bandwidth over an included allowance. Scaling means bigger or more machines. The bill is predictable in a different way: fewer line items, but the utilisation question is now yours, and an oversized machine running at eight percent costs the same as a busy one.

The comparison people actually want is total monthly cost for a specific workload, and that is only answerable by listing the components and pricing them individually. A web process, a worker, a database, object storage and outbound bandwidth is five numbers, not one, on either model.

Which model fits which team

The honest answer depends on one thing: whether someone on the team wants to own a server.

Pick the managed process model when the team is small, the application is a conventional web app, and nobody has both the time and the inclination to learn systems administration. The ceiling is real, but most applications never reach it, and hitting it later is a better problem than never shipping.

Pick the machine when you have a genuine requirement the platform cannot express, when you are running something with unusual system dependencies, or when you already have the operational skill in house and the tax is close to zero for you.

And be honest about the third case, which is the most common: you want the managed experience for the application and real infrastructure for the pieces around it. That is not a compromise any more, it is the default shape of a modern deployment, and both vendors have converged on offering it.

How this fits the rest of the stack

Whichever model wins the argument, the part worth doing before committing is the arithmetic, because both models hide the total in different places. Listing the pieces separately is what makes the comparison real, and the RunxBuild hosting calculator does exactly that: the web service, the database, the storage, the worker and the bandwidth as individual line items rather than one summary figure. On RunxBuild the shape is the managed one, deployed from a GitHub repository with build logs, a live route, environment variables and a rollback to the previous deploy, with a managed MySQL or Postgres instance on the private network beside it.

Useful related references:

• Maintenance Mode on Heroku: One Command, and the Migration It Cannot Save
• Heroku Config Vars Not Saving: Why the Dashboard Silently Fails
• Heroku Environment Variables: The Mental Model That Stuck Around After Heroku
• Services on RunxBuild

FAQ

Is a buildpack platform slower than a virtual machine?

Not meaningfully, for the same CPU and memory. Perceived slowness usually comes from cold starts on scale-to-zero tiers, from a database in a different region than the app, or from an undersized instance. All three are configuration problems rather than properties of the model.

Can I move an application from a buildpack platform to a virtual machine?

Usually yes, and the buildpack discipline is what makes it possible. An app that reads config from the environment, writes nothing important to local disk and logs to stdout is already container-shaped. The work is in rebuilding the surrounding infrastructure: the proxy, the certificates, the process supervisor and the deploy pipeline.

What is the difference between PaaS and IaaS in practice?

PaaS gives you a runtime and takes responsibility for the machine. IaaS gives you the machine and takes responsibility for the hardware. The dividing line is who patches the operating system, and everything else follows from that.

Do I need Docker to deploy on either platform?

No. Buildpack platforms detect the language and build an image for you, and virtual machines will happily run a process directly under systemd. Docker is useful when the build needs system dependencies the buildpack does not carry, or when you want the same image to run locally and in production.

Which model is cheaper?

Neither, in general. A machine-based setup usually costs less per unit of compute and more in engineering time. A managed platform costs more per unit and less in operations. Which is cheaper depends entirely on what an hour of your team’s time is worth and how many hours the difference actually consumes.