IaaS vs PaaS vs SaaS

When you move to the cloud, you are really buying a service model: a deal about how much of the computer stack the provider manages and how much you manage yourself. The three classic models are IaaS, PaaS, and SaaS. Picking the right one decides how much work lands on you, how much control you keep, and how big your bill gets. This page explains all three in plain English so you can tell, at a glance, which one a given product is and where your DevOps work actually lives.

What “the stack” means

A running application sits on top of a tall stack of layers. From the bottom up: the physical building and power, the physical servers, the network, the storage, the hypervisor (the software that splits one physical machine into many virtual ones), the operating system (for example Ubuntu 24.04 LTS), the runtime (the language engine like Node.js or the Java Virtual Machine), the application code, and finally your data.

Someone has to manage every layer. The only question each cloud model answers is: how far up the stack does the provider’s responsibility reach, and where does yours begin?

The pizza-as-a-service analogy

The easiest way to remember the three models is to think about how you can get a pizza dinner. Each option hands more of the work to someone else.

You want pizza	Who does the work	Cloud equivalent
Made at home	You buy ingredients, dough, oven, electricity, and cook it all	On-premises (you own everything)
Take-and-bake	Shop makes the pizza; you bring it home and bake it in your oven	IaaS (you get the raw infrastructure, you run the rest)
Delivery	Shop makes and cooks it; you supply the table, plates, and drinks	PaaS (provider runs the platform; you just bring code)
Dining out	You just show up and eat; the restaurant does everything	SaaS (you just use the finished software)

The “oven” in this analogy is the server and operating system. With take-and-bake (IaaS) you still own the oven and have to switch it on, set the temperature, and clean it. With delivery (PaaS) you never touch an oven. With dining out (SaaS) you do not even own plates.

IaaS — Infrastructure as a Service

IaaS gives you raw building blocks: virtual machines, virtual networks, and storage. The provider manages the building, hardware, and hypervisor. Everything from the operating system upward is yours. When you rent a VPS (a Virtual Private Server, a virtual machine you rent by the month) and SSH into a fresh Ubuntu box, that is IaaS.

You install and patch the OS, configure the firewall, install your runtime, deploy your app, and watch the logs. Here is the kind of work IaaS hands you on day one:

sudo apt update && sudo apt upgrade -y
sudo apt install -y nginx
sudo ufw allow OpenSSH
sudo ufw allow 'Nginx Full'
sudo ufw enable
sudo systemctl enable --now nginx

Output:

Firewall is active and enabled on system startup
Synchronizing state of nginx.service with SysV service script...

Examples: AWS EC2, Google Compute Engine, Azure Virtual Machines, DigitalOcean Droplets, Linode, Hetzner Cloud.

When to use IaaS: when you need full control of the OS and software, have unusual requirements, want to avoid vendor lock-in, or are learning Linux server administration (this whole DevOps track lives mostly at the IaaS layer). When NOT to: when you do not want to own OS patching, scaling, and uptime — that is a real, ongoing job.

PaaS — Platform as a Service

PaaS goes one level higher. The provider manages the operating system, the runtime, and the scaling. You bring only your code (and maybe a small config file). You never SSH into a server or run apt; you git push and the platform builds, deploys, and runs it.

A typical PaaS deploy looks like this:

git remote add render https://git.render.com/your-app.git
git push render main

Output:

==> Building...
==> Deploying...
==> Your service is live at https://your-app.onrender.com

The trade-off is control. You cannot install arbitrary system packages or tune the kernel, because you do not own the OS.

Examples: Heroku, Render, Railway, Fly.io, Google App Engine, AWS Elastic Beanstalk, Vercel, and Netlify (for front-end and serverless apps).

When to use PaaS: when you want to ship features fast and not run servers — small teams, prototypes, standard web apps. When NOT to: when you need custom system software, very tight cost control at large scale, or strict data-location rules the platform cannot meet.

SaaS — Software as a Service

SaaS is the finished product. The provider manages the entire stack, all the way up to the application itself. You just log in through a browser and use it. You manage nothing technical — only your own users, settings, and data inside the app.

Examples: Gmail, Google Workspace, Microsoft 365, Slack, Notion, Dropbox, Salesforce, GitHub, and even Cloudflare’s dashboard.

When to use SaaS: when the software already exists and is not your core product — email, chat, CRM, ticketing. Building these yourself is a waste of time. When NOT to: when the tool is your product, or when you cannot accept your data living on someone else’s system.

The responsibility table

This is the one table to memorize. ✅ means the provider manages it; 🧑 means you do.

Layer	On-prem	IaaS	PaaS	SaaS
Application	🧑	🧑	🧑	✅
Data	🧑	🧑	🧑	✅*
Runtime	🧑	🧑	✅	✅
Operating system	🧑	🧑	✅	✅
Virtualization / hypervisor	🧑	✅	✅	✅
Servers (hardware)	🧑	✅	✅	✅
Storage	🧑	✅	✅	✅
Networking	🧑	✅	✅	✅
Building / power	🧑	✅	✅	✅

* In SaaS the provider stores your data, but you are still responsible for what is in it and who you grant access to.

Security gotcha — the shared responsibility line is exactly where breaches happen. The cloud provider securing the data centre does NOT mean your VM is secure. On IaaS, a misconfigured firewall, a weak SSH password, or an unpatched Ubuntu box is 100% your fault. Always read the provider’s “shared responsibility model” so you know which layers are yours.

Where DevOps work lives

DevOps work scales down as you move from IaaS to SaaS, because the provider absorbs more of the toil.

IaaS is where most classic DevOps and Linux administration lives: provisioning servers, hardening SSH, configuring Nginx, managing systemd services, setting up ufw, patching the OS, and writing Infrastructure as Code (for example Terraform) to create all of it repeatably.
PaaS shifts DevOps toward the application: writing build configs, wiring CI/CD pipelines, managing environment variables and secrets, and watching deploys. Far less server toil.
SaaS leaves only light “ops”: managing user accounts, single sign-on, integrations, and audit logs.

Most real companies mix all three: SaaS for email and chat, PaaS for a quick internal tool, and IaaS for the core product that needs control. Learning the IaaS layer well — which is what this DevOps track does — gives you the foundation to understand the higher layers too.

Best Practices

Identify the service model of every tool you adopt; it tells you instantly which security and patching duties are yours.
Default to the highest level that meets your needs — use SaaS over PaaS over IaaS — and only drop down a level when you have a concrete reason for the extra control.
On any IaaS server, treat OS patching (sudo apt update && sudo apt upgrade) and firewall config (ufw) as non-negotiable day-one tasks.
Always read the provider’s shared responsibility model before going to production so no security layer is silently neglected.
Avoid lock-in on PaaS by keeping your app portable (a Dockerfile and plain config) so you can move to IaaS if costs or limits force you to.
Use Infrastructure as Code on IaaS so your servers are reproducible and not hand-built snowflakes.