PaaS Vendors: Choosing by Shape Instead of by Ranked List

Platform as a service means you deploy an application and someone else runs the operating system, the web server, and the scaling. The vendors differ on about six axes that no ranked list covers, and one of them — what you can take with you if you leave — matters more than everything else combined.

Searching for PaaS vendors returns two kinds of page: a definition of PaaS followed by a list, or a ranked roundup published by one of the vendors. Neither is much use for choosing, because the ranking reflects whoever wrote it and the list is out of date within a year. The axes below change more slowly than the roster does.

Table of contents

• What PaaS means, briefly
• Axis one: what it will actually run
• Axis two: the database question
• Axis three: the pricing model, not the price
• Axis four: what you can see and reach
• Axis five: what happens when you leave
• How to actually evaluate one
• How this fits the rest of the stack
• FAQ

What PaaS means, briefly

The ladder is familiar. Infrastructure as a service gives you a virtual machine and you install everything on it. Software as a service gives you a finished application. Platform as a service sits between: you supply the application code, the platform supplies the runtime, the operating system, the web server, the certificates, and the scaling.

The practical test for whether something is a PaaS: can you deploy by pushing code, without ever configuring a server? If yes, it is a platform. If you are handed an IP address and an SSH key, it is infrastructure with a nicer control panel.

The value proposition is straightforward. Most teams derive no advantage from configuring nginx or applying kernel patches, and every hour spent on it is an hour not spent on the product. The counter-argument is control, and it is a real one — the platform makes choices, and where its choices do not fit, you cannot override them.

That trade is the whole decision, and where it lands depends far more on what your application needs than on which vendor is ranked first anywhere.

Axis one: what it will actually run

The first filter, and the one that eliminates most options quickly.

• Which runtimes are first-class? Node, Python, Go, Ruby, Java, .NET, PHP — most platforms support several, and support quality varies between a documented first-class path and a Docker file you maintain yourself.
• Does it run containers? Docker support is the escape hatch for anything not natively supported, and a platform without it constrains you to its list.
• Does it run stateful services, or only stateless web processes? This is a major dividing line.
• Can it run background workers and scheduled jobs, or only request handlers? An application that needs a queue consumer and cannot have one is a serious limitation discovered late.
• Static sites as a distinct product, or does everything run as a service? It matters for cost — serving files should not cost the same as running a process.

The workers question is the one most often overlooked at evaluation time and most often needed within six months. Almost every application eventually has work that should not happen inside a request — sending email, generating a report, processing an upload — and a platform that cannot run a separate worker process forces awkward alternatives.

Axis two: the database question

This deserves its own axis because it is where platforms differ most and where the consequences are largest.

Some platforms offer managed databases as a first-class product. Some offer an integration with a third party. Some offer nothing and expect you to bring your own from elsewhere.

The differences that matter in practice:

• Is the database on a private network with the application, or reached over the public internet? The latter adds latency to every query and a security consideration you now own.
• Are backups automatic, and can you restore to a point in time?
• What is the connection limit, and does it suit your application’s pooling behaviour?
• Can you get a shell or run arbitrary SQL, or only what the console exposes?
• Can you export the whole thing in a standard format whenever you want?

That last point is the portability one. A standard Postgres or MySQL dump is portable to anywhere. A proprietary datastore with a bespoke API is not, and it is the single strongest form of lock-in a platform can create — far stronger than anything about the compute layer, because moving compute is a redeploy and moving data is a project.

RunxBuild offers managed MySQL and Postgres, both on the private network with backups, user management, and connection limits, and both exportable with the standard tools. That is deliberately unexciting, and unexciting is the correct property for the thing holding your data.

Axis three: the pricing model, not the price

Comparing headline prices across platforms is close to meaningless because they meter different things. Compare the model instead.

• Fixed plans. You choose a size and pay for it whether it is busy or not. Predictable, and you pay for idle capacity.
• Usage-based. You pay for what you consume. Efficient for spiky traffic and capable of producing a surprising bill.
• Per-request or per-invocation. Common for serverless models, cheap at low volume, and occasionally expensive at high volume in a way that is hard to predict in advance.
• Bandwidth. Sometimes included generously, sometimes metered aggressively. This is the most common source of an unexpected bill, particularly for anything media-heavy.
• Build minutes. Charged separately on some platforms, which matters if you deploy frequently.

The question worth asking of any usage-based model is what the worst case looks like. A platform that scales automatically and bills by consumption will happily scale through a traffic spike, a crawler loop, or a bug that retries indefinitely, and present the bill afterwards. A spending cap or a hard ceiling on scaling is worth more than a slightly better unit rate.

Fixed plans with an explicit floor and ceiling are the conservative choice: autoscaling between two plans you chose means the bill has a known maximum. That is how autoscaling works on RunxBuild — you set the smallest and largest plan and it moves between them, so the upper bound is a number you picked rather than a number you discover.

Axis four: what you can see and reach

Operational visibility varies enormously and is hard to evaluate from a marketing page.

• Build logs. Can you see why a build failed, in full, without opening a support ticket?
• Runtime logs. Are they live, searchable, retained for a useful period, and exportable?
• Metrics. CPU, memory, request rates, and error rates, or nothing?
• Shell access. Can you get into a running container to investigate, or run a one-off command such as a migration?
• Rollback. Can you return to the previous deploy in one action, and how long does it take?

The shell access one divides platforms sharply. Some give you a console into a running instance; some consider that an abstraction violation. When something behaves differently in production than locally, being unable to look inside turns a ten-minute investigation into a day of deploying diagnostic logging.

Rollback is the one to verify rather than assume. Every platform claims it. What matters is whether it is one click, how many previous releases are retained, and whether it also reverts environment variable changes or only the code.

Axis five: what happens when you leave

The question no vendor comparison asks, and the one that determines how much the other five matter.

Score any platform on three things.

Is your application still ordinary? If it runs from a standard repository with a standard runtime and a Dockerfile, it runs anywhere. If it has been restructured around platform-specific functions, a proprietary routing model, or vendor-only APIs woven through the code, leaving means rewriting.

Is your data exportable? A standard database dump is portable. Object storage with an S3-compatible API is portable. A proprietary datastore is not, and neither is a database you can only reach through a web console.

Is your configuration reproducible? Environment variables in a file you can read, and infrastructure described in the repository, transfer. Configuration that exists only as clicks in a dashboard has to be reconstructed from memory.

You are not obliged to avoid every convenience — some platform-specific features are genuinely worth the coupling. The point is to know which ones you have accepted, so the cost of leaving is a number you know rather than one you discover during a migration you did not plan.

A useful habit: keep a short document listing every platform-specific thing the application depends on. If it stays short, you are portable. If it grows, that is a decision worth making consciously.

How to actually evaluate one

Marketing pages will not tell you any of the above. Deploy something.

1. Take a real application, not a hello world. Something with a database, an environment variable, and a background job if you have one.
2. Deploy it and time how long the first deploy takes from an empty account.
3. Break it deliberately — a syntax error, a failing migration — and see what the build log tells you.
4. Find the runtime logs and check whether you could debug a production issue from them.
5. Roll back and time it.
6. Add a database, connect to it, and export it.
7. Read the bill after a week and check it matches what you expected.

That takes an afternoon and tells you more than every comparison article combined, because it tests the things that are only visible from inside.

Do it on two platforms rather than one. The comparison is what makes the differences legible — individually, every platform seems reasonable.

How this fits the rest of the stack

Choose a platform on what it runs, what it does for your database, how it meters, what it lets you see, and what you keep if you leave. A ranked list answers none of those and is stale within a year. Deploy a real application on two candidates for an afternoon and the differences become obvious. The RunxBuild hosting calculator prices services, managed MySQL and Postgres, storage, and bandwidth as separate line items, which makes it straightforward to compare against a platform that quotes one number.

Useful related references:

• PaaS Services: What You Are Actually Buying
• Vercel Alternative: When the Hosted PaaS Stops Fitting and What to Move To
• Coolify vs Dokploy: What Self-Hosted PaaS Actually Costs You
• Services on RunxBuild

FAQ

What is the difference between PaaS and IaaS?

Infrastructure as a service hands you a virtual machine and you install and maintain everything on it. Platform as a service takes your application code and runs it, providing the operating system, web server, certificates, and scaling. The practical test is whether you can deploy by pushing code without ever configuring a server.

How do I compare PaaS vendors?

Not by ranked lists, which reflect whoever wrote them and go stale quickly. Compare on what runtimes and workloads it runs, whether it offers managed databases on a private network, how it meters and whether the bill has a ceiling, what logs and shell access you get, and what you can take with you if you leave.

What is the biggest risk with a PaaS?

Lock-in through data rather than compute. Moving an application between platforms is a redeploy if it is an ordinary repository with a standard runtime. Moving data out of a proprietary datastore with no standard export is a project. Keep the database standard and the application ordinary and the rest is portable.

Can a PaaS run background workers and scheduled jobs?

Some can and some cannot, and it is the capability most often overlooked at evaluation time and most often needed within six months. Almost every application eventually needs work that should not happen inside a request. Check for it explicitly rather than assuming a platform that runs web processes will run workers.

How do I avoid an unexpected PaaS bill?

Ask what the worst case looks like under a usage-based model. A platform that scales automatically and bills by consumption will scale through a crawler loop or a retry bug and invoice you afterwards. Prefer a model with an explicit ceiling — autoscaling between a floor plan and a top plan you chose means the maximum is a number you set.