Cloud Service Model · 2 of 6

PaaS — Platform as a Service

Push code, get a running app. The platform handles the OS, runtime, scaling, load balancing, TLS, and most ops — you focus on the application itself.

Push-to-deployManaged RuntimeAuto-scalingBuilt-in TLSLess ops
← Back to Cloud
Quick Facts

At a Glance

Basic Concepts

  • You ship code; the platform runs it. No servers to patch, no load balancers to configure.
  • Buildpacks / Dockerfiles turn your repo into a runnable image automatically.
  • Auto-scaling based on CPU, requests/sec, queue depth, or schedule.
  • Built-in: TLS, custom domains, log streaming, environment vars, rolling deploys.
  • You give up some control (kernel, exotic networking) for huge ops simplification.
Landscape

The Major Platforms

PlatformProviderSweet spot
HerokuSalesforceOriginal PaaS; still beloved for simplicity.
Azure App ServiceMicrosoftEnterprise PaaS; .NET, Java, Node, Python.
Google Cloud RunGoogleContainers, scale-to-zero, pay-per-request.
AWS App Runner / Elastic BeanstalkAWSContainer or code → managed service on AWS.
Fly.ioFlyGlobal edge VMs from a Dockerfile + simple CLI.
RenderRenderHeroku-like DX, Git-driven, predictable pricing.
RailwayRailwayModern Heroku alternative; great for side projects.
Vercel / NetlifyFrontend-focused PaaS (Next, Nuxt, SvelteKit).
Cloudflare Workers / PagesCloudflareEdge runtime, V8 isolates, sub-ms cold starts.
DigitalOcean App PlatformDigitalOceanSimple pricing, simple DX.
Mechanics

How PaaS Works

The Build → Deploy Pipeline
  1. Push to Git (or push a container image).
  2. Platform builds your code via a buildpack or Dockerfile.
  3. It deploys the new image as new instances.
  4. Rolling deploy swaps traffic — old instances keep serving until new ones pass health checks.
  5. If health checks fail, automatic rollback.
The 12-Factor Discipline

PaaS works best when your app follows 12-factor:

  • Stateless processes — sessions in Redis, files in object storage.
  • Config via env vars, not files.
  • Logs to stdout — the platform streams them.
  • Port binding — app listens on $PORT.
  • Disposability — graceful shutdown on SIGTERM.
Auto-scaling Modes
  • Manual — you set N instances.
  • Metric-based — scale on CPU%, memory, custom metrics.
  • Concurrency-based — N concurrent requests per instance.
  • Scale-to-zero — drop to zero when idle (Cloud Run, Fly Machines, Vercel).
  • Scheduled — pre-warm before known peaks.
What's Bundled (and What's Not)
Usually includedUsually extra
HTTPS / TLS certsManaged databases (often DBaaS)
Custom domainsBackground workers / cron
Log aggregationObject storage
Health checks & restartsEmail / SMS
Rolling deploys + rollbackVector / search DBs
Env var management & secretsAuth / SSO
Trade-offs

Strengths & Weaknesses

Strengths
  • Fastest path from idea to production.
  • Drastically less ops — no kernel, no LB config.
  • Built-in best practices (TLS, rolling deploys, health checks).
  • Great for small teams without dedicated infra engineers.
Weaknesses
  • Less control — exotic runtimes, syscalls, kernels are off-limits.
  • Cost grows non-linearly at scale vs IaaS.
  • Vendor lock-in — moving off Heroku or Vercel takes work.
  • Cold starts on scale-to-zero offerings.
When to Use

Sweet Spots

Web Apps & APIs

The classic 12-factor target.

MVPs & Side Projects

Free tiers, instant deploys, no infra distraction.

Internal Tools

Low-traffic apps where ops cost > compute cost.

Frontend / Static + SSR

Vercel, Netlify, Cloudflare Pages.

Continue

Other Service Models