Deployment Platforms: The Five Kinds, and How to Pick One by the Shape of Your App

Deployment platforms come in five kinds, and the right one is decided by the shape of the app, not by the vendor listicle. A folder of static files wants a static host. A long-running server with a database wants a platform-as-a-service. Bursty, stateless request handlers can be serverless. Many services with strict control needs want a container platform. And a team that already lives in one hyperscaler can use its raw compute. Answer four questions about the app and the category picks itself; only then compare vendors within it.

Every page that ranks for this query is a top-ten list written by one of the ten. They are not useless, the better ones agree on what breaks after hello world, but a ranked list of vendors is the wrong tool for the decision. The category matters more than the brand, and most of the pain people report comes from picking a good vendor in the wrong category. This post is the category decision, with the trade-offs that actually bite.

Table of contents

• The five kinds
• Start from the shape of the app
• Static sites and single-page apps
• Long-running services and the database problem
• Serverless: when scale-to-zero is worth cold starts
• Containers and raw cloud: control you pay for in hours
• The decision table
• How this fits the rest of the stack
• FAQ

The five kinds

• Static hosts. Serve built files from a CDN. No server process. For sites, documentation, single-page apps and static exports.
• Platform-as-a-service. Push a repository, get a build, a running process, a URL, environment variables, logs and usually a managed database next to it. For long-running services and APIs.
• Serverless functions. Code split into request handlers a platform invokes on demand, scaling to zero between. For stateless, bursty, short-lived work.
• Container platforms. You provide images, the platform schedules them, often on Kubernetes underneath. For many services with specific networking, scheduling or compliance needs.
• Raw cloud compute. Virtual machines and managed services from a hyperscaler, assembled by you. For teams with the staff to run infrastructure and a reason to.

The lines blur at the edges: several PaaS products run containers underneath, and the hyperscalers each sell a PaaS layer of their own. The categories still hold, because what you are choosing is how much of the operation is yours.

Start from the shape of the app

Four questions sort almost any app into a category. Answer them before opening a pricing page.

1. Does it need a process running between requests? Websockets, background jobs, queues, cron and in-memory state all say yes. A yes rules out static hosting and makes serverless awkward.
2. Does it need a database next to it? Most apps do, and the platforms that fail after hello world are the ones where the database is a separate product with its own bill and its own network.
3. Is the traffic steady or bursty? Steady traffic is cheaper on a fixed plan; genuinely bursty, idle-most-of-the-time traffic is where scale-to-zero earns its cold starts.
4. How much control does the team want to own? Custom networking, sidecars, specific kernels and compliance scoping push toward containers or raw cloud. Wanting none of that is a fine answer and points at PaaS.

A blog, a portfolio and a marketing site answer no to the first two and belong on a static host. A SaaS backend with users and orders answers yes to both and belongs on a PaaS. The PaaS services post goes deeper on that middle category.

Static sites and single-page apps

If the build produces files and nothing runs at request time, this is the cheapest and most reliable category by a wide margin. There is no process to crash, no memory to size and no patching. The things to check are bandwidth included, custom domains with automatic certificates, header and redirect configuration, and a fallback rule for single-page apps so a refresh on a client-side route does not 404. The static pages post covers the category; the Netlify React app page not found post is the single most common thing that goes wrong on it.

Long-running services and the database problem

The PaaS category exists for one workflow: connect a repository, push, and have a build produce a running service with a URL, environment variables, logs, metrics and a rollback button. Node, Python, Go, Ruby, Java, .NET and Docker images all fit. This is where most web applications belong, and it is the category the vendor lists are really about.

The differentiator, as even the vendor-written lists admit, is what happens when the app needs a database, a cache or a worker. On a good PaaS the database is created next to the service, reachable over a private network, with backups and connection limits handled, and appears on the same bill. On a weak one the database is a separate product, the connection goes over the public internet, and the two never quite feel like one system. Ask specifically: can I create a managed Postgres or MySQL in the same project, and is it private by default? The database on RunxBuild docs are one answer to that question.

Serverless: when scale-to-zero is worth cold starts

Serverless is the right category for work that is stateless, short and irregular: a webhook receiver, an image resizer, a form handler, an API that gets ten thousand requests on Monday and none on Sunday. Paying nothing while idle is a genuine advantage there.

It is the wrong category for the app that has a database connection pool, a websocket, a job queue or anything that takes longer than the function timeout. Those apps end up with a serverless front and a separate long-running service behind it, which is two platforms and two bills for one app. The serverless architecture post is the honest version of the trade-off. If the app is mostly the second kind of work, start on a PaaS and carve out functions later if a piece genuinely wants them.

Containers and raw cloud: control you pay for in hours

A container platform or a hyperscaler gives the most control and asks the most in return. Networking, scheduling, secrets, ingress, observability and upgrades are configurable because they are yours to configure. For a team with platform engineers and requirements the managed categories cannot meet, that is the correct trade. For a three-person startup it is a part-time job nobody applied for.

The honest test is whether anyone on the team wants to be paged for infrastructure. If the answer is no, the control is a liability. The deploy Next.js to a VPS post shows what running one app by hand involves; multiply by every service and every upgrade. The Kubernetes as a service post is the middle path when the answer is yes but not the whole cluster.

The decision table

• Files only, no server: static host.
• One or a few long-running services with a database: PaaS.
• Stateless handlers, idle most of the time: serverless, possibly alongside a PaaS for the stateful part.
• Many services, custom networking, compliance scoping, a platform team: container platform.
• Already deep in one hyperscaler with staff to run it: that hyperscaler’s compute and managed services.

RunxBuild sits in the second category, with the first folded in. Static sites deploy from a repository with 120GB of bandwidth included; web services in Node, Next.js, Python, Go, Ruby, Java, .NET or Docker deploy from GitHub with build logs, a live route, environment variables and rollback; managed MySQL and Postgres are created beside them on a private network; and n8n runs as a managed tool. A service starts on the Dev plan at $4 a month (0.3 vCPU, 624MB), and autoscaling moves it between a floor and a ceiling plan when traffic changes. The services on RunxBuild docs describe the deployment path.

How this fits the rest of the stack

Choose the category by asking whether the app needs a running process, a database beside it, steady or bursty traffic, and how much control the team wants to own. Then, and only then, compare vendors inside the category. The RunxBuild hosting calculator prices the static site, the service, the database and the bandwidth together, so the PaaS answer for a specific app is a monthly number rather than a position on someone’s list. Ship on the category that fits, and move up a category only when the app earns it.

Useful related references:

• PaaS Services: What You Are Actually Buying
• Serverless Architecture: The Patterns That Hold Up and the Ones That Do Not
• Container Platforms Compared: Matching the Tool to Your Team, Not the Hype
• Services on RunxBuild

FAQ

What is a deployment platform?

A service that takes application code, or a built artefact or container image, and runs it on infrastructure you do not manage: building it, giving it a URL, injecting configuration, keeping it running, and usually providing logs, metrics and a database alongside. The categories range from static hosts through platform-as-a-service and serverless to container platforms and raw cloud compute.

What is the difference between PaaS and serverless?

A PaaS runs a long-lived process for your app, so it can hold connections, run jobs and keep state in memory, and you pay for the plan whether or not requests arrive. Serverless runs short-lived functions per request and scales to zero, so idle time is free but cold starts, timeouts and the lack of a persistent process constrain what the app can do.

Should I just use AWS, Google Cloud or Azure directly?

Only if the team already runs infrastructure there and has the staff to operate it. Raw cloud gives the most control and the most operational work; for a small team shipping one application, a PaaS delivers the same running app with far less to maintain, and the hyperscalers each sell a PaaS layer for exactly that reason.

Are there free deployment platforms?

Most categories have a free tier with limits: bandwidth caps on static hosts, small or sleeping instances on PaaS, invocation quotas on serverless. They are good for prototypes and demos. For anything with users, budget for the smallest paid plan, which is typically a few dollars a month for a service and starts the clock on backups and uptime you can rely on.

Can I move between deployment platforms later?

Within a category, usually yes: a Docker image or a repository with a build command moves between PaaS products with modest effort. Across categories it is harder, because the app takes the platform’s shape: serverless apps assume functions and platform caches, container apps assume orchestration. Keeping the app a plain process with configuration in environment variables is the best insurance.