"IaaS, PaaS, SaaS" gets thrown around like everyone agrees on the boundaries. They don't — the lines blur, and modern platforms straddle them. But the core idea is genuinely useful: the three models describe how much of the stack you operate yourself versus how much the provider operates for you. Get that and you can place any product on the spectrum.
The pizza-as-a-service mental model
The classic analogy: making pizza.
- On-premises = make it at home. You buy ingredients, own the oven, cook, serve. Total control, total work.
- IaaS = take-and-bake. You get the ingredients and a kitchen; you assemble and bake.
- PaaS = pizza delivery. You provide the table and drinks; the pizza shows up made.
- SaaS = dining out. You just eat.
Corny, but it captures the essence: as you move from IaaS to SaaS, you hand off more responsibility and gain less control.
The stack, layer by layer
Here's who manages what across the models:
| Layer | On-prem | IaaS | PaaS | SaaS |
|---|---|---|---|---|
| Application | You | You | You | Provider |
| Data | You | You | You | Provider |
| Runtime | You | You | Provider | Provider |
| Middleware | You | You | Provider | Provider |
| OS | You | You | Provider | Provider |
| Virtualization | You | Provider | Provider | Provider |
| Servers | You | Provider | Provider | Provider |
| Storage | You | Provider | Provider | Provider |
| Networking | You | Provider | Provider | Provider |
The pattern is clean: the responsibility boundary slides up the stack as you go IaaS → PaaS → SaaS.
IaaS: Infrastructure as a Service
You rent raw compute, storage, and networking. The provider runs the physical hardware and virtualization; you run everything from the OS up.
- Examples: AWS EC2, Google Compute Engine, DigitalOcean Droplets, bare-metal VPS.
- You manage: OS patching, runtime installation, web server config, security hardening, scaling logic, certs.
- Best for: teams needing maximum control — custom kernels, specific OS tuning, lift-and-shift of legacy workloads, or unusual networking.
- Cost shape: usually cheapest per raw resource, most expensive in human time.
IaaS gives you a blank server and a lot of rope.
PaaS: Platform as a Service
You bring code; the platform handles the runtime, OS, scaling, and deployment plumbing. You don't touch the OS or patch servers.
- Examples: Heroku (the archetype), Google App Engine, and modern developer clouds like PandaStack.
- You manage: your application code, your data model, your config (env vars).
- Provider manages: build, deploy, runtime, OS, networking, SSL, scaling, the registry, ingress.
- Best for: product teams who want to ship features, not operate infrastructure.
- Cost shape: a premium over raw IaaS in exchange for dramatically less ops time.
PandaStack is a PaaS: you connect a Git repo and "push code, it runs." The platform builds your image (rootless BuildKit in ephemeral pods), pushes to a registry, deploys via Helm, terminates SSL, routes traffic through Kong ingress, and wires up a managed database with DATABASE_URL injected. You never SSH into a box.
SaaS: Software as a Service
You consume finished software over the network. No code, no infrastructure — just a login.
- Examples: Gmail, Slack, Notion, Salesforce, Stripe's dashboard.
- You manage: your data and configuration within the app.
- Best for: end users and businesses who need the *function*, not the building blocks.
- Cost shape: per-seat or usage subscription; zero ops.
Note the recursion: SaaS products are usually *built on* PaaS or IaaS. Your SaaS CRM runs on someone's servers.
The lines are blurry on purpose
Real products mix models:
- A managed database is arguably PaaS for storage — you bring the data, the provider runs the engine, backups, and failover.
- Serverless / edge functions are sometimes called "FaaS" (Functions as a Service), a PaaS subspecies where you deploy a function instead of a whole app.
- Containers-as-a-service sit between IaaS and PaaS depending on how much the platform automates.
Don't get hung up on labels. Ask the operative question instead.
How to choose
The useful question isn't "which acronym?" — it's "how much of this do I want to operate, and what do I gain by operating it?"
- 1Do you need OS-level or kernel-level control? If yes → IaaS. If no → you're probably overpaying in time by choosing it.
- 2Is the thing you need already a finished product? If yes → SaaS. Don't rebuild Slack.
- 3Are you shipping an application and want to focus on the app? → PaaS.
Most web product teams land on PaaS for their app, SaaS for commodity functions (email, payments, auth), and IaaS only when they hit a genuine control requirement.
A concrete comparison
Imagine deploying the same Node + Postgres app:
- IaaS: provision a VM, install Node, install Postgres, configure nginx, set up certbot, write a systemd unit, set up backups, write a deploy script. Days of setup; ongoing maintenance.
- PaaS: connect the repo, provision a managed database, push. Minutes; the platform maintains the rest.
- SaaS: not applicable — you're building the app, not buying one.
That gap — days vs minutes, plus ongoing toil — is the entire value proposition of PaaS.
References
- [NIST Definition of Cloud Computing (SP 800-145)](https://csrc.nist.gov/pubs/sp/800/145/final)
- [AWS: Types of cloud computing](https://aws.amazon.com/types-of-cloud-computing/)
- [Red Hat: IaaS vs PaaS vs SaaS](https://www.redhat.com/en/topics/cloud-computing/iaas-vs-paas-vs-saas)
- [Microsoft Azure: cloud service types](https://azure.microsoft.com/en-us/resources/cloud-computing-dictionary/what-is-paas)
- [The Twelve-Factor App](https://12factor.net/)
---
If you've decided PaaS is your sweet spot, PandaStack gives you the full picture — apps, databases, edge functions, and cronjobs — on a free tier you can explore immediately at [dashboard.pandastack.io](https://dashboard.pandastack.io).