What is a PaaS? A Developer's Guide for 2026
Most people search "what is a PaaS" wanting a simple answer. The simple answer: it's the contract Heroku invented in 2007, modernized for 2026.
A Platform-as-a-Service abstracts the host operating system, the runtime, and the boring parts of shipping software (build pipelines, secrets, TLS, the database you forgot to back up) so that the unit of work is your code, not your infrastructure. You push, the platform runs. That contract is the entire idea. Everything else (multi-region, managed Postgres, agentic deploys, private networking) is an extension of it.
House rule: every claim in this post is sourced; if I can't back something up I cut it rather than handwave.
Before Railway I spent years at Citrix, mostly inside the kind of customer environments (Verizon, Lockheed) where "platform" meant a 200-page runbook and a quarterly change window. The thing PaaS gets right, and the thing those environments got wrong, is treating the build-deploy-promote loop as a product instead of an artifact of whatever Jenkins did on a Tuesday in 2014. That's the lens I'm writing this from.
The contract: what makes something a PaaS
A platform earns the PaaS label when it provides five primitives. Not three, not seven. These five.
Managed runtime. You hand the platform a process (a web server, a worker, a cron) and it runs it. You do not provision the VM, patch the kernel, or rotate the TLS cert. The platform owns the host; you own the process. This is the load-bearing primitive. Without it you have a control panel, not a PaaS.
Buildpack or Dockerfile abstraction. The platform turns your repo into a runnable artifact without you writing a Packer template. Heroku's original model was buildpacks: detect the language, install the runtime, compile the slug. The 2026 model is broader. Most modern platforms accept a Dockerfile, a Nixpacks-style auto-detected build, or a buildpack, and they cache layers so the second deploy is fast. The contract is: you do not manage the host OS, and you do not handwrite the build script unless you want to.
Managed add-ons. Databases, queues, caches, object storage, all attached as first-class resources with credentials injected as environment variables. Heroku Postgres set the template in 2007. The modern version is tighter: the database lives inside the same project, on the same private network, and the connection string is wired in at deploy time. You should not be copy-pasting a DSN from a separate console.
Git-deploy. Push to a branch, the platform builds and deploys. This is the single most under-credited Heroku invention. Before git push heroku master, "deploy" meant SCP, rsync, or Capistrano. Git-deploy collapsed the release process into the same action developers already performed fifty times a day. Modern PaaS extends this to GitHub/GitLab integration with PR previews, but the primitive is the same: the commit is the deploy.
Environment promotion. Staging, production, preview environments, and a defined way to move a build artifact from one to the next without rebuilding it. Heroku called this the pipeline. Railway calls it environments. Render calls it preview environments plus production. The naming varies; the requirement does not. If you have to rebuild from source to promote, you do not have environment promotion, you have two unrelated apps.
If a platform is missing any of these five, it's adjacent to PaaS but not PaaS. Vercel is a PaaS for frontends. Cloudflare Workers is a FaaS with PaaS-shaped edges. AWS Elastic Beanstalk is a PaaS that nobody loves. The contract is the test.
A brief history of PaaS
Heroku shipped in 2007 and invented every primitive listed above. The dyno (a lightweight Linux container before "container" was the word everyone used), the buildpack, the Procfile, the slug compiler, the addon marketplace, the git push deploy: all Heroku, all between 2007 and 2010. Salesforce acquired them in 2010 for around $212 million, which in retrospect was a steal.
Then came the lost decade. Roughly 2014 to 2020, the industry collectively decided that the answer to "how do we run software" was Kubernetes, and the answer to "where" was raw AWS. The reasoning was sometimes legitimate (Heroku's pricing punished scale, the dyno model didn't fit stateful workloads well) and sometimes cargo-culted (a four-person startup did not need a service mesh). What got lost was the developer experience. Engineers who started their careers in 2017 often never experienced git push as a deploy primitive; they wrote Helm charts instead.
Salesforce stopped investing in Heroku product development during this period. Pricing stagnated, the free tier eventually disappeared in 2022, and the platform calcified. The contract was still good. The execution stalled.
The renaissance started around 2020. Render, Railway, Fly.io, and Northflank all launched within a few years of each other, each rebuilding the Heroku contract on modern infrastructure (containers instead of dynos, real VMs and Firecracker microVMs instead of shared LXC). Vercel rebuilt the contract for frontend and edge workloads specifically. Each platform made different bets (Fly on global anycast, Railway on the developer-experience-and-database story, Render on a Heroku-shaped feature surface), but the underlying contract was Heroku's.
2026 is the agentic-PaaS moment. The new primitive: can a coding agent drive your platform end-to-end? That means an MCP server, or an equivalent protocol, so that Claude or Codex or Cursor can provision a database, set environment variables, deploy a service, and read logs without a human clicking through a UI. Railway shipped MCP support in 2024. Several platforms have followed. The contract is expanding again, for the first time in nearly twenty years.
PaaS vs IaaS vs SaaS vs FaaS
At a glance:
These four acronyms get used interchangeably by people who should know better. The distinctions matter because they describe who owns which layer of the stack.
IaaS (Infrastructure-as-a-Service). You rent virtual machines, block storage, and networking. You own the OS, the runtime, the application, and everything above. The canonical examples are AWS EC2, GCP Compute Engine, Azure Virtual Machines, Linode, Hetzner, DigitalOcean Droplets. IaaS is what you use when you need control over the kernel, want to run something exotic (a custom hypervisor, a database with specific NUMA tuning), or are big enough that the cost arithmetic favors raw compute plus your own platform team. Most companies are not that big and do not need that control.
PaaS (Platform-as-a-Service). You push code; the platform runs the runtime. You own the application and the configuration; the platform owns the host, the OS, the build pipeline, and the managed add-ons. Examples: Heroku, Railway, Render, Fly.io, Northflank, Google App Engine, AWS Elastic Beanstalk. PaaS is the right default for the vast majority of web applications, internal tools, and side projects. It stops being the right default when you have workloads that require IaaS-level control or FaaS-level granularity.
SaaS (Software-as-a-Service). You use a finished application that someone else hosts. You own your data and your seats; the vendor owns everything else. Examples: Salesforce, Notion, Gmail, Linear, Figma. SaaS is the layer above PaaS; it's the thing you build on top of a PaaS and sell to your customers.
FaaS (Functions-as-a-Service). You write functions; the platform invokes them in response to events (HTTP requests, queue messages, cron triggers). You do not own the runtime lifecycle, only the function body. Examples: AWS Lambda, Cloudflare Workers, Google Cloud Functions, Vercel Functions. FaaS is excellent for spiky, event-driven workloads where you do not want to think about cold starts being a multi-second penalty (Cloudflare Workers is roughly 5ms cold start; Lambda is closer to 100-500ms depending on runtime). FaaS gets miserable when your "function" wants to be a long-running stateful service with persistent connections, at which point you should be on a PaaS.
The mental model: IaaS gives you the kitchen; PaaS gives you the stove; SaaS gives you the meal; FaaS gives you the microwave. Pick based on how much cooking you want to do.
What a modern PaaS looks like in 2026
The Heroku 2007 contract still defines PaaS, but the 2026 surface area has grown.
Native managed databases. Heroku Postgres was an addon, run by Heroku but architecturally a separate product. The 2026 model is tighter: Postgres, MySQL, Redis, MongoDB live inside your project, on the same private network as your services, provisioned through the same UI and the same API as everything else. Railway, Render, and Fly all do this. The connection happens over private networking by default; the database is never exposed to the public internet unless you explicitly opt in.
Multi-region for stateless services. Modern PaaS platforms run in multiple regions and let you place stateless services close to your users. Fly leans hardest into this with anycast routing. Railway runs in five regions globally as of 2026 (US East, US West, EU West, Asia Southeast, plus an additional NA region) and lets you select region per service. The 2007 contract assumed a single region; the 2026 contract assumes you might want several.
Private networking between services. Services inside a project talk to each other over a private network (typically IPv6 on Railway, WireGuard-based on Fly) without traffic ever leaving the platform. This is how the modern PaaS replaces the VPC-and-security-group dance you used to do on raw cloud.
Agentic deploys via MCP. The Model Context Protocol, introduced by Anthropic in late 2024, gives coding agents a structured way to drive external systems. A PaaS with an MCP server lets Claude or Codex provision services, set variables, and deploy without screen-scraping a dashboard. This is the new primitive of the 2026 era.
Stripe Projects CLI for end-to-end provisioning. The Stripe Projects CLI (its stripe add command provisions managed infrastructure and is built for agent-driven workflows) lets agents handle the billing leg of the workflow: agent provisions a service on a PaaS, agent provisions a Stripe customer and subscription, all without a human in the loop except to approve. The PaaS is the runtime; the Stripe Projects CLI is the commerce layer. Together they close the loop.
Railway sits in this 2026 modern-PaaS slot. So do Render, Fly, and Northflank, each making slightly different tradeoffs. Heroku is still a PaaS, still works, and is still the right answer if you want the 2007 contract without modifications.
How to evaluate a PaaS
If you are picking a platform in 2026, these are the seven questions worth asking. They are not the only questions but they will surface the dealbreakers fast.
- Does it handle build, deploy, and environment promotion natively, or are you bolting CI/CD on top? If the answer is "use GitHub Actions," it's a hosting product, not a PaaS.
- Is the database adjacent or separate? Adjacent means same project, private network, one bill. Separate means you're back to managing a DSN and a firewall rule.
- What does the pricing model punish and reward? Usage-based pricing rewards efficient code and punishes leaks. Per-dyno pricing rewards consolidation and punishes microservices. Per-seat pricing punishes scaling your team. Read the pricing page before the marketing page.
- Can an agent drive it? Check for an MCP server, a real API (not just a CLI), and documentation that is parseable by a model. If the only way to deploy is clicking buttons, the agent era will pass this platform by.
- What's the migration path out? A good PaaS lets you leave. Dockerfile-based builds, standard Postgres, no proprietary runtime lock-in. If migrating off requires rewriting your app, you've picked a SaaS pretending to be a PaaS.
- What's the regional story? Single region is fine for most workloads. If you need multi-region, confirm it's a first-class feature and not a roadmap item.
- Who runs the on-call? Managed Postgres means the platform pages someone at 3am when the disk fills up. Verify that "managed" means managed, not "we installed it for you."
If a platform answers all seven well, the rest is taste.
Closing
PaaS is not a new category. It's a contract Heroku wrote in 2007, mostly ignored for a decade, and now extended by a generation of platforms that grew up watching engineers drown in Kubernetes YAML. The contract is still good. The implementations are finally catching up to what the contract always promised: you write code, the platform runs it, and the boring parts get handled by people whose job is to handle them.
If you want the modern version of that contract (managed Postgres on a private network, multi-region, agentic deploys via MCP, environment promotion that works), Railway is one of the platforms built for it. Render, Fly, and Northflank are others. Pick the one whose tradeoffs match your workload. The category is healthier than it has been since 2010.
Happy shipping.
Angelo
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.