Platform as a Service buys you the boundary between your code and everything underneath it: you own the application, the vendor owns the operating system, the runtime, the build, the routing, and the machine.
The textbook definition puts PaaS in a three-tier diagram between IaaS and SaaS and leaves it there. That diagram is accurate and it does not help you decide anything. What helps is a specific list of responsibilities and which side of the line each one falls on.
Table of contents
- The responsibility split, item by item
- What good platforms give you beyond the split
- The genuine limitations
- Avoiding the lock-in that actually matters
- Choosing between the layers
- How this fits the rest of the stack
- FAQ
The responsibility split, item by item
This is the whole concept, and it is more useful as a table than as a definition.
- Physical hardware, hypervisor, network - vendor, on every model including IaaS.
- Operating system and security patching - vendor on PaaS, you on IaaS. This is the single biggest transfer.
- Language runtime and its version - vendor on PaaS, though you choose which.
- Build process - vendor, from your repository or Dockerfile.
- Web server, reverse proxy, TLS certificate - vendor. Certificates issue and renew without you.
- Process supervision and restarts - vendor. A crashed process comes back.
- Horizontal scaling - vendor mechanism, your policy. You set a floor and ceiling; it moves between them.
- Your application code and its dependencies - yours, entirely.
- Your data model, your schema, your migrations - yours.
- Your bill - yours, and worth watching.
Read the list and the value proposition is obvious: everything that is undifferentiated moves, and everything that is actually your product stays.
What good platforms give you beyond the split
The responsibility transfer is the definition. The reason teams actually stay is a handful of operational properties that are tedious to build yourself.
Build logs per deploy. When a release fails, you can see why, at the step it failed, without SSHing anywhere. This sounds minor until you have debugged a failing deploy without it.
Rollback. The previous version is still there and one action puts it back. This changes the emotional character of deploying, which changes how often people deploy, which is most of what continuous delivery is actually about.
Environment variables as first-class configuration. Secrets and config live in the platform rather than in files on a server, scoped per environment, changeable without a rebuild.
Runtime logs in the same place as build logs. The failing build and the failing request in one interface. Most incident time is spent correlating those two things across systems that do not know about each other.
Managed databases next door. A Postgres or MySQL instance with backups, connection limits, and private networking, provisioned in the same place as the service that uses it.
The genuine limitations
Three, and they are the same three on every platform in the category.
No system-level access. You cannot install an OS package outside the container image, tune kernel parameters, or run a sidecar daemon that is not part of the deployment model. For web applications this rarely matters. For anything with unusual system dependencies, it is decisive.
Ephemeral local disk. Containers are replaced on deploy and anything written locally is lost. Applications that assumed a writable directory need changing to use object storage or attached persistent storage. This is the most common migration surprise by a wide margin.
Unusual process shapes fit badly. One stateless web process scales beautifully. Singletons, leader election, fixed hostnames, and long-lived stateful connections between instances all fight the model.
Notice what is not on this list: application size. PaaS is not a beginner tier you graduate from. Large applications run on platforms permanently, and the reasons to drop to raw infrastructure are specific requirements rather than growth.
Avoiding the lock-in that actually matters
Platform lock-in is real but it is not evenly distributed, and knowing where it concentrates lets you avoid most of it for free.
The portable core is a container that reads its configuration from environment variables and keeps no state on local disk. That runs on any platform in this category and on a VM. If your application meets those two conditions, changing hosts is a weekend rather than a project.
The sticky parts are the proprietary extras: the vendor’s queue, its authentication service, its key-value store, its function runtime, its edge configuration language. Each one is convenient and each one is a thread stitching you to that vendor. Use them where the convenience is genuinely worth it, and know which ones you have adopted.
The database is worth calling out separately. A managed Postgres or MySQL instance is portable because the protocol is standard and a dump restores anywhere. A proprietary datastore with a bespoke API is not. Preferring standard databases is the single highest-leverage anti-lock-in decision available, and it costs nothing.
Choosing between the layers
Start at PaaS. Drop to IaaS when a specific requirement forces it - kernel access, a non-web workload, hardware needs, or scale where the managed-service margin is genuinely material. Move up to SaaS when the problem turns out to be one somebody has already solved as a product, which is more often than engineers like to admit.
The mistake is starting at IaaS because it seems more serious, and then spending the first year of a product becoming accidental system administrators. That year is not recoverable, and nothing in it was your product.
How this fits the rest of the stack
The platform layer is easy to price precisely because there are so few line items, which makes it a fair comparison against a VM plus the hours around it. The RunxBuild hosting calculator lays out the service, the database, the storage, and the bandwidth so the total is explicit before you commit. RunxBuild deploys from a GitHub repository in Node, Next.js, Python, Go, Ruby, Java, .NET, and Docker, with build logs, runtime logs, environment variables, custom domains, rollback, autoscaling, and managed MySQL and Postgres alongside.
Useful related references:
- Vercel Alternative: When the Hosted PaaS Stops Fitting and What to Move To
- Coolify vs Dokploy: What Self-Hosted PaaS Actually Costs You
- SQL Managed Instance: The PaaS Database, the Cost, the Migration Story, and When to Use One
- Services on RunxBuild
FAQ
What is PaaS in simple terms?
A service that runs your application without you managing the machine. You provide code; the vendor provides the operating system, the runtime, the build, the web server, the TLS certificate, process supervision, and scaling. You keep the application, the data model, and the bill.
What is the difference between PaaS and IaaS?
The operating system. On IaaS you get a virtual machine and everything above the hypervisor is yours to patch, configure, and operate. On PaaS the vendor owns the OS, runtime, and build, and you only own the application. The trade is control against operational work.
What are the limitations of PaaS?
No system-level access, so you cannot install OS packages outside the container or tune kernel parameters. Ephemeral local disk, so files must go to object storage. And poor fit for unusual process shapes like singletons or leader election. Application size is not a limitation.
Does using a PaaS mean vendor lock-in?
Only partly, and the sticky parts are avoidable. A container configured by environment variables with no local state runs anywhere. Lock-in accumulates through proprietary extras - bespoke queues, auth services, and datastores. Preferring standard Postgres or MySQL is the cheapest anti-lock-in decision available.
Do large applications outgrow PaaS?
Not as a rule. Plenty of substantial applications run on platforms permanently. Teams move to raw infrastructure for specific reasons - kernel access, non-web workloads, hardware requirements, or scale where managed-service margins become material - rather than because the application got big.