Angelo Saraceno
Most engineers learn "PaaS vs IaaS vs SaaS" from a single slide in a 2014 textbook.
The slide that was right in 2014 is incomplete in 2026.
The industry built the three-tier model (IaaS, PaaS, SaaS) to explain cloud computing to people who had only ever bought servers, and it worked. Two new tiers have arrived since then: FaaS (Functions-as-a-Service) and what I call agentic-PaaS, where the platform exposes itself to LLM agents as a first-class consumer. If you are choosing where your workload should live in 2026, you are working with five tiers now, and that old slide only drew three.
You should know my bias before you weigh any of this.
I work at Railway, and Railway is a PaaS. The thesis here, that most teams belong on PaaS, is a conclusion I get paid to like, so hold it to a higher bar than if a neutral party had written it. I've tried to earn it anyway. Every tier gets a straight definition. Every category lists Railway's competitors by name, right next to it. The decision framework names the cases where the honest answer is some other tier, and some other vendor. Railway appears as a real example, in the PaaS lineup and as one of the few agentic-PaaS implementations that ship today, not as a sales pitch. Swap in Render, Fly, or whatever fits your constraints, and the argument should hold. I won't spend the next couple thousand words selling you. If the argument fails without the brand attached, I haven't earned your time.
The three classic tiers, defined
NIST defined cloud computing in Special Publication 800-145, which it published in 2011, and named three service models: Infrastructure as a Service, Platform as a Service, and Software as a Service. NIST still hosts the document and has never updated the definitions.
Infrastructure as a Service (IaaS) means the vendor gives you virtualized hardware. Before Railway I was at Citrix, in Verizon and Lockheed customer environments, which is where I learned what enterprise IaaS looks like once the slides come down and someone has to provision a VLAN.
You get a VM, a block device, a network interface, and a bill. Everything from the kernel up is your problem. The vendor handles power, cooling, the hypervisor, and the physical network. You handle the operating system, patching, the runtime, the application, identity, observability, and the on-call rotation. AWS EC2 is the canonical example. So is a Hetzner cloud VM, a DigitalOcean droplet, or a Linode instance. Managed Kubernetes (EKS, GKE, AKS) sits a half-step above pure IaaS: the vendor runs the control plane, and you still own every node, every workload manifest, every IAM binding, and every upgrade. I think of it as IaaS++ rather than PaaS, because the operational surface area sits closer to "fleet of VMs" than "I pushed code and it ran."
Platform as a Service (PaaS) means the vendor abstracts away the machine. You bring code (or a container image, or a Git repository) and the platform handles the runtime, the OS, the scaling, the networking, the TLS, and often the database. Heroku invented the category in 2007 with git push heroku master. The category survived Heroku's stagnation under Salesforce and now includes Railway, Render, Fly, Vercel, Netlify, and a long tail of regional players. Google App Engine and AWS Elastic Beanstalk count as PaaS too. (though most engineers I talk to forget Beanstalk exists
Software as a Service (SaaS) means the vendor runs the entire application and you are a user rather than an operator. Salesforce, Notion, Linear, Figma, Gmail, and Stripe Dashboard are all SaaS. You do not deploy code; you log in. The vendor owns the database, the uptime, the feature roadmap, and the security posture. Your only "ops" work is user provisioning, SSO configuration, and data export.
IaaS gives you a machine, PaaS gives you a runtime, SaaS gives you an outcome.
Two tiers the classic model misses
Functions as a Service (FaaS) emerged with AWS Lambda in 2014. It is more abstract than PaaS. You do not deploy an application; you deploy a function. The vendor handles cold starts, scaling to zero, request routing, and concurrency. You pay per invocation and per millisecond of execution. Cloudflare Workers, Vercel Functions, Deno Deploy, and AWS Lambda are the obvious examples. FaaS shines for event-driven glue (webhooks, image resizing, scheduled jobs) and grows more viable for full applications each year through edge runtimes, though the long-running-process model still does not fit (classic Lambda has no WebSockets-as-a-server, for instance, though you can route around that with API Gateway).
Agentic-PaaS is the tier that did not exist in 2014 or 2018 or even 2023. It describes a PaaS that exposes itself to LLM agents as a first-class consumer, most often through the Model Context Protocol (MCP, which Anthropic published in November 2024). The platform's API serves more than humans clicking buttons or CI pipelines running deploy. It exposes structured calls for an agent to read project state, deploy code, query logs, and reason about infrastructure. The category is small and forming. Railway ships an MCP server. A few other PaaS vendors have started, and more will fill out the category over the next 18 months. It earns a tier rather than a feature footnote because "the operator is an agent" changes platform design all the way down: idempotency guarantees, structured errors, declarative config over imperative scripting, and observability an LLM can parse.
You can call agentic-PaaS "only PaaS with an MCP server." I would answer that "PaaS" was "only IaaS with a buildpack" in 2008, and we still gave it a tier because the consumption model changed.
All five tiers, side by side:
Where should your workload live? IaaS, PaaS, FaaS, SaaS, and agentic-PaaS compared by what you manage and what each is best for.
The abstraction ladder
Here is one way to visualize it.
At the bottom rung is bare metal: you own the box. One rung up is IaaS: you own the OS and everything above. Then managed Kubernetes (IaaS+): you own the workloads. Then PaaS: you own the code. Then FaaS: you own the function. Then SaaS: you own nothing except your data and your login.
The abstraction ladder: bare metal, IaaS, managed Kubernetes, PaaS, FaaS, and SaaS, climbing from more control and more ops at the bottom to less ops and vendor-defined limits at the top, with agentic-PaaS branching off PaaS.
Each rung up trades flexibility for less ops work. At the bottom you can do anything: run a custom kernel, attach a GPU, put a database on raw NVMe. At the top you can do only what the vendor allows, and you do zero infrastructure work. Most production workloads in 2026 live on the middle rungs, because bottom-rung freedom costs headcount and top-rung lock-in costs flexibility.
Agentic-PaaS sits at the same rung as PaaS in abstraction; what changes is the consumer. Think of it as a horizontal axis on top of the vertical ladder. The ladder measures how much of the stack you own; the new axis measures whether a human or an agent drives.
A higher rung is not always the better one. The right rung depends on workload shape, team shape, and how much variance you must absorb at the infrastructure layer.
Concrete examples in each tier
IaaS.
AWS EC2 (the original, which AWS launched in 2006). Google Compute Engine. Azure Virtual Machines. Hetzner Cloud (cheaper, EU-based, popular with cost-sensitive teams). Linode (now Akamai Cloud). DigitalOcean Droplets. OVHcloud. For bare metal: Equinix Metal (formerly Packet), Hetzner dedicated, OVH dedicated. Managed Kubernetes layered on top: EKS, GKE, AKS, DigitalOcean Kubernetes. Railway can be used in this way with our new VMs that shipped.
PaaS.
Railway, Render, Fly.io, Vercel, Netlify, Heroku, Google App Engine, AWS Elastic Beanstalk, Platform.sh, DigitalOcean App Platform. Vercel and Netlify optimize for frontend and edge; Railway and Render serve general-purpose workloads; Fly targets globally distributed apps; Heroku still exists and still has paying customers, though active product investment has stayed thin since the Salesforce acquisition.
SaaS. Salesforce, Notion, Linear, Figma, Slack, GitHub, GitLab (as a hosted product), Atlassian Cloud, Stripe Dashboard, Datadog, Sentry, Vercel's own dashboard if you squint. SaaS is the largest category by revenue and the least interesting to anyone choosing infrastructure, because by definition you are not choosing infrastructure when you pick SaaS. You can deploy SaaS on Railway with Railway Templates.
FaaS. AWS Lambda, Google Cloud Functions, Azure Functions, Cloudflare Workers, Vercel Functions (which run on AWS Lambda and Cloudflare under the hood depending on runtime), Deno Deploy, Netlify Functions, Fastly Compute@Edge.
Agentic-PaaS. Railway with its MCP server is one example. The category is small in May 2026, and I would rather undersell it than overclaim. Expect it to grow as more PaaS vendors ship MCP integrations and as agent-driven deployment becomes a standard pattern rather than a novelty demo.
How to decide which tier you should be on
Treat this as a decision framework, since real decisions run messier than a flowchart's clean branches.
Team shape. If you have more than two full-time platform engineers and a strong opinion about kernel parameters, IaaS or managed Kubernetes makes sense. If you have one full-stack engineer who has to ship a product this quarter, you belong on PaaS. If you have zero engineers and you need a CRM, you belong on SaaS. The rough dividing line: does someone's job description include the word "infrastructure"? If no, do not run your own infrastructure.
Workload shape. Long-running stateful workloads (Postgres, Redis, queue workers, persistent WebSocket servers) want PaaS or IaaS, because FaaS still penalizes long-lived processes through pricing or hard timeouts. Bursty event-driven workloads (webhook receivers, scheduled jobs, image transforms) thrive on FaaS. Workloads with hard latency requirements at the edge (sub-50ms global) want edge FaaS or a globally distributed PaaS. Workloads with regulatory requirements (specific region, specific hardware, audit trail of every kernel patch) sometimes push you back to IaaS or bare metal, though the cleanest PaaS vendors now offer compliance certifications (SOC 2, HIPAA on request) that cover most of what teams need.
Control needs. If you need a custom kernel module, a specific GPU SKU, or guaranteed physical isolation, you belong on IaaS or bare metal. If you need "my app, with a database, on a URL, with TLS," you belong on PaaS. The middle case runs trickiest: teams that want PaaS ergonomics plus a custom networking detail (a VPN peering, a specific egress IP). The strong PaaS vendors now expose enough networking primitives to handle most of these cases, and the ones that fall short lose those customers to IaaS.
Ops capacity. Run the honest math here. Every hour your team spends patching nodes, debugging Kubernetes, or rotating certificates is an hour you do not spend on product. The "IaaS is cheaper" calculation often omits this opportunity cost. At a fully loaded engineer cost of $200K a year, an engineer who spends 30% of their time on infrastructure plumbing adds $60K of hidden cost on top of your AWS bill.
Variance you need to absorb. If your traffic pattern runs "10x on launch day, 0.1x on Tuesday night," PaaS or FaaS with autoscaling absorbs the variance for you. If your traffic stays flat (most B2B internal tools), autoscaling counts for less, and unit economics counts for more.
Closing
Most teams in 2026 belong on PaaS, even though IaaS looks cheaper on paper.
The 2014-textbook framing, where IaaS was the serious choice and PaaS was for prototypes, was wrong by 2020 and runs more wrong now. Modern PaaS vendors offer enough networking, compliance, and runtime control that the sound reasons to run on raw IaaS have narrowed to three: you have specific hardware requirements, you run a platform engineering org that is itself your product, or you operate at a scale where the unit economics flip. Most other teams pay an ops tax for tradition.
Railway is one example of modern PaaS, with an MCP server for the agentic-PaaS extension. Others exist. Pick the one whose tradeoffs match your team's. Do not default to raw IaaS because a 2014 slide called it the serious choice.
Happy shipping.
Angelo Saraceno is a Solutions Engineer at Railway. Before Railway he was at Citrix, working inside Verizon and Lockheed environments, so he has seen what "enterprise IaaS" looks like after the slides come down. He writes about infrastructure, deployment, and the gap between how cloud is sold and how it runs in practice.