Modern PaaS Platforms Cheat Sheet

Updated 2026-05-21

Next Topic: Multi-Cloud Strategies Cheat Sheet

🧠Study flashcards on this topic93 cards · spaced repetition→

Modern Platform as a Service (PaaS) lets teams deploy web applications, background workers, and managed databases without managing servers, clusters, or OS patches. Platforms like Fly.io, Render, Railway, Heroku, Koyeb, and DigitalOcean App Platform have redefined what "push to deploy" means, each with distinct philosophies — from Railway's usage-based simplicity to Fly.io's globally distributed Firecracker microVMs. The critical mental model: every platform trades operational control for convenience, so the right choice depends on whether your workload fits 12-factor patterns, how latency-sensitive your users are, and whether predictable billing or pay-per-use matters more. Heroku's shift to sustaining engineering in 2026 and Koyeb's acquisition by Mistral AI have made choosing the right modern PaaS more urgent than ever.

What This Cheat Sheet Covers

This topic spans 18 focused tables and 112 indexed concepts, 93 flashcards. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.

Table 1: Platform Overview and PositioningTable 2: Deployment Models (Dockerfile vs Buildpack vs Source)Table 3: Regional and Edge DeploymentTable 4: Autoscaling and Scale-to-ZeroTable 5: Pricing Models and Free TiersTable 6: Managed Databases OfferedTable 7: Secrets and Environment ManagementTable 8: Custom Domains and TLS AutomationTable 9: Preview Environments and PR-Based DeploymentsTable 10: Build Caching and Pipeline IntegrationsTable 11: Persistent Storage and VolumesTable 12: Networking and Private ServicesTable 13: Observability and Log StreamingTable 14: Background Workers, Cron Jobs, and WebSocketsTable 15: Heroku Migration PatternsTable 16: IDP vs PaaS PositioningTable 17: Cost Comparison vs Hyperscaler EquivalentsTable 18: Common Limitations and Use Case Fit

Quick IndexSubscribe to unlock

A jump-to index of every table row in this cheat sheet.

Mind MapSubscribe to unlock

An interactive map of every table and concept in this topic.

Table 1: Platform Overview and Positioning

Each platform occupies a distinct niche — understanding its philosophical positioning before reading feature lists prevents choosing the wrong tool. These six are the most commonly evaluated Heroku-era replacements in 2026.

Platform	Example	Description
Railway	`Connect GitHub repo → Railpack auto-detects runtime → push to deploy`	• Usage-based PaaS billed by the second • fastest path from repo to running URL • visual project canvas connects services • strong for prototyping and variable-traffic workloads
Render	`Connect GitHub → select runtime → get onrender.com URL with zero config`	• Closest philosophical Heroku replacement • flat-rate tiers with predictable billing • first-class background workers, cron jobs, and managed Postgres • eliminates per-seat fees as of 2026.
Fly.io	`fly launch → fly deploy → app runs in Firecracker microVMs across 30+ regions`	• Docker-first platform running apps in Firecracker microVMs on bare metal • best for global latency-sensitive and real-time apps • steeper learning curve than Railway or Render
Heroku	`git push heroku main → dyno runs Procfile web process`	• Pioneered git-push PaaS • shifted to sustaining engineering in early 2026 (no new enterprise contracts, no new features) • still valid for existing Salesforce-integrated enterprise deployments
DigitalOcean App Platform	`doctl apps create --spec app.yaml`	• Managed PaaS within the DigitalOcean ecosystem • integrates with Droplets, VPCs, and managed databases • predictable fixed pricing • good for teams already using DigitalOcean infrastructure
Koyeb	`koyeb app create --git github.com/user/repo --regions fra,was,sin`	• Serverless platform deploying in MicroVMs across 10 core + 250+ edge locations • acquired by Mistral AI in February 2026, shifting roadmap toward AI inference workloads

Table 2: Deployment Models (Dockerfile vs Buildpack vs Source)

How a platform transforms your code into a running container determines build reproducibility, debugging ease, and how much you own the artifact. Understanding which model a platform prefers — or requires — prevents build-time surprises.

Model	Example	Description
Railpack (auto-detect)	`# No config needed — Railway detects Node/Python/Go/Ruby from repo`	• Railway's Go-based BuildKit builder (launched March 2026, successor to Nixpacks) • zero-config runtime detection • produces images 38% smaller (Node) to 77% smaller (Python) than Nixpacks

The rest of this section is part of the full cheat sheet

Table 3: Regional and Edge Deployment

Where your app runs determines latency for global users. These platforms span a spectrum from single-region deployments to true 250+ edge location networks — the choice affects both architecture complexity and cost.

Platform	Example	Description
Fly.io multi-region	`fly scale count 2 --region lax,fra,sin`	• Deploy Machines to 30+ regions simultaneously • BGP anycast routes users to nearest datacenter • ideal for real-time apps, games, and globally distributed APIs

The rest of this section is part of the full cheat sheet

Table 4: Autoscaling and Scale-to-Zero

How a platform handles traffic spikes and idle periods directly impacts both reliability and cost. Scale-to-zero is powerful but introduces cold-start latency — the trade-off is different for each platform and use case.

Behavior	Example	Description
Fly.io autostop/autostart	`auto_stop_machines = "stop"` `auto_start_machines = true` `min_machines_running = 0`	• Fly Proxy stops and starts Machines (never destroys them) based on incoming traffic • cold starts typically 300ms–2s • set `"suspend"` instead of `"stop"` for faster wake-up with some limitations

The rest of this section is part of the full cheat sheet

Table 1: Platform Overview and Positioning

Platform	Example	Description
Railway	`Connect GitHub repo → Railpack auto-detects runtime → push to deploy`	• Usage-based PaaS billed by the second • fastest path from repo to running URL • visual project canvas connects services • strong for prototyping and variable-traffic workloads
Render	`Connect GitHub → select runtime → get onrender.com URL with zero config`	• Closest philosophical Heroku replacement • flat-rate tiers with predictable billing • first-class background workers, cron jobs, and managed Postgres • eliminates per-seat fees as of 2026.
Fly.io	`fly launch → fly deploy → app runs in Firecracker microVMs across 30+ regions`	• Docker-first platform running apps in Firecracker microVMs on bare metal • best for global latency-sensitive and real-time apps • steeper learning curve than Railway or Render
Heroku	`git push heroku main → dyno runs Procfile web process`	• Pioneered git-push PaaS • shifted to sustaining engineering in early 2026 (no new enterprise contracts, no new features) • still valid for existing Salesforce-integrated enterprise deployments
DigitalOcean App Platform	`doctl apps create --spec app.yaml`	• Managed PaaS within the DigitalOcean ecosystem • integrates with Droplets, VPCs, and managed databases • predictable fixed pricing • good for teams already using DigitalOcean infrastructure
Koyeb	`koyeb app create --git github.com/user/repo --regions fra,was,sin`	• Serverless platform deploying in MicroVMs across 10 core + 250+ edge locations • acquired by Mistral AI in February 2026, shifting roadmap toward AI inference workloads

Table 2: Deployment Models (Dockerfile vs Buildpack vs Source)

Model	Example	Description
Railpack (auto-detect)	`# No config needed — Railway detects Node/Python/Go/Ruby from repo`	• Railway's Go-based BuildKit builder (launched March 2026, successor to Nixpacks) • zero-config runtime detection • produces images 38% smaller (Node) to 77% smaller (Python) than Nixpacks

Table 3: Regional and Edge Deployment

Platform	Example	Description
Fly.io multi-region	`fly scale count 2 --region lax,fra,sin`	• Deploy Machines to 30+ regions simultaneously • BGP anycast routes users to nearest datacenter • ideal for real-time apps, games, and globally distributed APIs

Table 4: Autoscaling and Scale-to-Zero

Behavior	Example	Description
Fly.io autostop/autostart	`auto_stop_machines = "stop"` `auto_start_machines = true` `min_machines_running = 0`	• Fly Proxy stops and starts Machines (never destroys them) based on incoming traffic • cold starts typically 300ms–2s • set `"suspend"` instead of `"stop"` for faster wake-up with some limitations