What Is PaaS? Platform as a Service Explained

A platform as a service (PaaS) is a hosting model in which you hand over your application code, or a container image, and the provider runs it for you. You do not install an operating system, configure a web server, renew certificates or restart crashed processes: the platform builds the code, deploys it, routes traffic to it and keeps it alive. You decide what the app does and how much capacity it gets; the platform decides how that capacity is provided.

The term is part of the classic trio of cloud service models defined by the US standards institute NIST. Infrastructure as a service (IaaS) gives you virtual machines and networks; software as a service (SaaS) gives you a finished application. PaaS sits in between, which is why it appeals to developers who want to ship features rather than maintain servers. A side-by-side breakdown of the three models is in PaaS vs. IaaS vs. serverless.

What a PaaS does for you

A typical platform covers the same chain of tasks, whichever provider you pick:

• Build: detects the language from your repository (often with buildpacks) or uses your Dockerfile, then produces a runnable image.
• Deploy: starts the new version, checks that it responds and switches traffic over, usually with a rollback button.
• Routing and TLS: gives you a public URL, connects your custom domain and issues certificates automatically.
• Scaling: lets you add instances or larger instance sizes with a slider or a config value; some platforms scale automatically.
• Operations: restarts crashed processes, collects logs and basic metrics, and stores environment variables and secrets.
• Add-ons: managed databases, caches, queues and cron jobs that attach to the app with a connection string.

What stays your job

A PaaS does not make an application production-ready by itself. You remain responsible for:

• the code, its dependencies and their security updates;
• database schema, backups you can actually restore, and data retention;
• access control, secrets hygiene and who in your team can deploy;
• costs, including what happens to the bill when traffic spikes;
• legal questions such as where personal data is processed and under which contract.

That last point matters more in Europe than in most vendor blogs suggest. A platform can run in a Frankfurt or Amsterdam region and still be operated by a company under non-EU law. We explain the difference between data residency and legal control in sovereign cloud explained.

Where PaaS fits

Situation	PaaS a good fit?	Why
Small team, web app or API, standard stack	Yes	Saves the time you would spend on servers and deployment pipelines
Prototype or side project	Yes	Fast to start; watch free-tier limits and sleep behaviour
Steady, high and predictable load	Often not	Per-instance or usage pricing can exceed a well-run server
Special networking, GPUs, custom kernels	Rarely	Platforms standardise; exotic needs fall outside the model
Strict data-location or procurement rules	Depends	Region choice, provider seat and contract documents decide

Hosted, self-hosted and Kubernetes-based

Three flavours compete today.

Hosted platforms such as Railway, Render, DigitalOcean App Platform or the French providers Clever Cloud and Scalingo run everything on their infrastructure. You pay for convenience. Our Heroku alternatives comparison lists them with regions and company seats.

Self-hosted PaaS tools such as Coolify, Dokku and CapRover install a Heroku-like workflow on a server you rent. You keep the convenience of git-push or dashboard deployments but take over updates, backups and monitoring of that server. See self-hosted PaaS for how they differ.

Platforms on Kubernetes add a developer-friendly layer on top of a cluster. They suit teams that already run Kubernetes or need its flexibility; for everyone else they add a layer of complexity. Background on that world is in what cloud-native means.

How PaaS pricing works

There are two main models. Instance-based pricing charges a fixed monthly amount per running instance size, which makes bills predictable. Usage-based pricing charges for the CPU, memory and network the app actually consumes, which is cheap for idle apps and less predictable for busy ones. On top come databases, storage, outbound traffic (egress) and sometimes per-seat team fees.

Because the components add up differently from one provider to the next, it helps to estimate before committing. Our PaaS cost calculator walks through the factors, including the admin time you save or spend.

Lock-in: what to check before you start

The convenience of a platform is also where lock-in starts. Four questions keep your exit open:

1. Can you deploy from a standard Dockerfile, so the same image runs elsewhere?
2. Can you export database dumps in a standard format at any time?
3. Are configuration files proprietary, or close to common formats?
4. Do add-ons use open protocols (PostgreSQL, Redis-compatible, S3-compatible storage)?

If the answer is yes to most of them, moving later is a matter of days rather than months.

Bottom line

A PaaS is the shortest path from code to a running app with HTTPS, logs and rollbacks. It is the right default for small teams and new products, provided you keep an eye on three things: how pricing grows with traffic, where the platform runs and who operates it, and how easily you can take your app and data elsewhere.