Skip to content
←

Split View: PaaS 비교 2026 — Vercel · Netlify · Render · Fly.io · Railway · Northflank · Heroku · Cloud Run · App Runner · Coolify 어디에 배포할 것인가 정면 비교

|

PaaS 비교 2026 — Vercel · Netlify · Render · Fly.io · Railway · Northflank · Heroku · Cloud Run · App Runner · Coolify 어디에 배포할 것인가 정면 비교

프롤로그 — Heroku 가 떠난 자리에 누가 들어왔는가

2022 년, Salesforce 가 Heroku 의 무료 티어를 죽였다. 그날 트위터에서 한 세대의 인디 해커가 동시에 비명을 질렀다. "Heroku 가 죽었다. 이제 우리는 어디에 배포해야 하는가." 그 비명에서 시작된 4 년의 PaaS 황금기가 2026 년 봄, 어느 정도 모양을 잡았다.

오해는 풀고 시작하자. Heroku 는 죽지 않았다. Salesforce 가 무료 티어를 죽이고 가격 정책을 한 번 정리했을 뿐, 2026 년 현재 Heroku 는 살아 있고 Heroku-24 스택과 Postgres 17 까지 지원한다. 다만 "기본값" 의 자리는 잃었다. 새 프로젝트의 기본값은 더 이상 Heroku 가 아니다.

그 빈 자리를 차지한 후보가 너무 많다. Vercel 은 Next.js 의 사실상 본가가 되어 v0 와 ai-sdk 까지 흡수하며 "프레임워크 우선 PaaS" 라는 카테고리를 만들었다. Render 는 "Heroku 가 그리워? 우리가 Heroku 다" 를 슬로건처럼 외치며 영속 디스크, 크론, 백그라운드 워커, Postgres 를 한 곳에 묶었다. Fly.io 는 Docker 우선 글로벌 PaaS 로 멀티 리전 배포를 사소한 일로 만들었다. Railway 는 분당 자원 단위 과금과 우아한 UX 로 새 세대를 데려갔다. Northflank 는 멀티 클라우드와 BYOC, 그리고 더 고급 프리미티브 — Job, Cron, Volume, Build Pipeline — 로 시리어스 팀의 눈을 끌었다. Netlify 는 Vercel 의 형이지만 동생에게 자리를 빼앗긴 후 JS 프레임워크 호스팅에 집중하며 살아남았다.

그리고 클라우드 사람들이 사랑하는 다크호스가 있다. Cloud Run — GCP 의 서버리스 컨테이너 — 은 100ms 단위 과금과 0 으로의 스케일 다운으로 일부 워크로드에서는 다른 모든 PaaS 를 가격으로 박살낸다. AWS App Runner 와 ECS Fargate 는 AWS 출구를 원하는 팀의 선택. Coolify 와 Dokku 는 "PaaS 비용이 미쳤다, 내가 직접 호스팅하겠다" 는 부류의 선택.

이 글은 이 PaaS 들을 같은 축으로 정면 비교한다. 비교 후, 네 시나리오 — Next.js 앱 배포, API + Postgres + Redis + 워커 스택, 글로벌 멀티 리전 SaaS, $5k/월 트래픽 풀스택 앱 — 에서 어느 도구를 골라야 하는지 묻는다. 가격은 빠르게 움직인다. 모든 숫자는 2026 년 5 월 기준 이고, 구조의 차이에 초점을 둔다. 6 개월 뒤 숫자가 바뀌어도 의사 결정 프레임은 유효해야 한다.

같은 카테고리의 PaaS 라도 과금 모델 과 런타임 모델 이 다르면 한 달 청구서는 10 배까지 벌어진다. 그리고 떠나는 비용은 들어오는 비용의 10 배다.

1장. PaaS 의 정의 — 무엇이 PaaS 이고 무엇이 아닌가

2026 년에 "PaaS" 라는 단어를 쓰려면 먼저 경계선을 그어야 한다. 좁은 의미의 PaaS — Platform as a Service — 는 Heroku 가 정의한 것이다. git push heroku main 한 줄로 코드가 빌드되고 배포되고 도메인이 붙는다. 인프라는 보이지 않는다. 데이터베이스, 캐시, 큐는 애드온으로 한 줄 추가된다.

이 정의에서 Vercel · Netlify · Render · Fly.io · Railway · Northflank · Heroku · Coolify · Dokku 는 모두 PaaS 다. 코드를 푸시하면 배포된다.

경계선에 있는 도구도 있다. Cloud Run 은 컨테이너를 푸시하면 자동으로 스케일링되는 서버리스 컨테이너 플랫폼이다. 좁은 의미의 PaaS 보다는 한 단계 낮은 추상화 — Postgres 도, 빌드 파이프라인도 별도로 붙여야 한다 — 지만, 사실상 PaaS 처럼 쓰인다. AWS App Runner 도 같은 카테고리다. ECS Fargate 와 Kubernetes 는 PaaS 보다 한 단계 낮은 CaaS — Container as a Service — 또는 IaaS 에 가깝다.

이 글은 좁은 PaaS 와 Cloud Run / App Runner 까지를 다룬다. ECS Fargate 와 EKS 는 비교 표에서 잠깐 등장하지만 본격적인 비교 대상은 아니다.

1.1 PaaS 의 다섯 축

같은 축에서 비교하지 않으면 비교가 아니다. 다섯 축을 먼저 정의한다.

  • 빌드 모델 — Buildpack? Dockerfile? 프레임워크 자동 감지? Nixpacks?
  • 런타임 모델 — 항상 켜져 있는 서버? 0 으로 스케일 다운? 요청당 인스턴스?
  • 영속성 — 영속 디스크? Postgres? Redis? Object Storage?
  • 과금 — 인스턴스 시간? CPU 초? 요청 수? 대역폭? 무료 티어?
  • 운영 — 로그? 메트릭? 시크릿? 미리보기 환경? 롤백? 멀티 리전?

이 다섯 축으로 각 PaaS 를 한 줄로 요약하면 다음과 같다.

PaaS빌드런타임영속 디스크과금멀티 리전
Vercel프레임워크 자동서버리스 + Active CPUX (Blob/KV 별도)요청 + Active CPU + 대역폭자동 엣지
Netlify프레임워크 자동Functions + EdgeX (Blobs 별도)빌드 분 + 요청 + 대역폭자동 엣지
RenderNative + Docker항상 켜짐 (서비스 단위)O (Disk)인스턴스 시간리전 선택
Fly.ioDockerfile + BuildpacksMachines (0 스케일 가능)O (Volumes)Machine 시간 + 대역폭멀티 리전 기본
RailwayNixpacks + Docker항상 켜짐O (Volume)분당 자원 사용리전 선택
NorthflankDockerfile + Buildpacks항상 켜짐 + JobO (Volume)인스턴스 시간멀티 클라우드
HerokuBuildpacks + DockerDyno (항상 켜짐)X (Add-on)Dyno 시간리전 선택
Cloud RunBuildpacks + Docker요청당 인스턴스X (GCS 별도)CPU/메모리 초자동 글로벌
App RunnerBuildpacks + Docker항상 켜짐X (S3 별도)인스턴스 시간 + 요청단일 리전
CoolifyDockerfile + Buildpacks본인 서버O (호스트 디스크)본인 서버 비용본인 결정

표만 봐도 패턴이 보인다. Vercel · Netlify · Cloud Run 은 "0 으로 스케일 다운, 영속 디스크 없음" 진영, Render · Fly.io · Railway · Northflank · Heroku 는 "항상 켜짐, 영속 디스크 있음" 진영. 이 한 줄의 차이가 모든 가격 계산과 워크로드 적합도를 결정한다.

2장. Vercel — Next.js 의 본가, 그리고 v0 까지

Vercel 은 2026 년 현재 가장 시끄러운 PaaS 다. Next.js 의 사실상 본가이고, ai-sdk 의 본가이고, v0 — UI 를 만들어 주는 AI — 의 본가이고, AI Gateway 라는 새 카테고리까지 만들었다.

좋은 점. Next.js 를 쓰면 다른 옵션을 고민할 필요가 거의 없다. git push 한 번으로 빌드되고, 미리보기 환경이 PR 마다 자동으로 생기고, 엣지에 자동 배포되고, 이미지 최적화와 분석이 기본으로 붙는다. 솔로 개발자 입장에서 "그냥 배포" 의 정의가 Vercel 이다.

문제. 가격이다. 2024 년 말 Vercel 은 과금 모델을 한 번 갈아엎었다. 기존의 "함수 호출 수 · GB-Hr · 대역폭" 모델에서 Active CPU 모델로 바꿨다. Active CPU 는 CPU 가 실제로 일을 한 시간만 과금하는 것이다 — 외부 API 응답을 기다리는 시간이나 DB I/O 대기 시간은 빠진다. 이론적으로는 더 싸다.

실제로는 어떤가. 가격 페이지의 숫자 — Active CPU 시간 $0.128, Provisioned Memory $0.0106 per GB-Hr, Edge Requests 100만 건당 $2 — 만 보면 합리적이다. 그러나 트래픽이 늘면 청구서가 빠르게 부푼다. 특히 큰 페이지를 Server Components 로 그리는 Next.js 앱은 페이지당 Active CPU 시간이 길어진다.

$5k/월 매출의 SaaS 가 Vercel 에서 얼마를 쓰는가. 커뮤니티 보고 — Reddit r/nextjs, Twitter 의 SaaS 빌더들 — 를 평균하면 트래픽 1–5 만 MAU 대에서 월 $150–$600 사이가 나온다. 그 위로는 Pro 의 $20/석 베이스와 사용량 초과분이 누적되어 빠르게 커진다.

Vercel 의 진짜 함정은 영속성이 없다 는 점이다. Postgres 는 Vercel Postgres — 사실은 Neon 의 OEM — 이고, Redis 는 Vercel KV — 사실은 Upstash 의 OEM — 다. 이들은 추가 비용이고, 트래픽에 따라 청구서가 따로 또 부푼다. Vercel 안에서 모든 것을 닫고 운영하면 결국 Neon 과 Upstash 의 직접 가격보다 비싸진다.

2.1 Vercel 에 Next.js + Postgres + Redis 배포

가장 간단한 워크플로우는 이렇다.

# 1. 로컬에서 Next.js 앱 만들기
npx create-next-app@latest my-saas

# 2. Vercel 에 연결
cd my-saas
vercel link

# 3. Vercel Postgres (= Neon) 와 Vercel KV (= Upstash) 추가
vercel storage create postgres
vercel storage create kv

# 4. 환경 변수 자동 주입 확인
vercel env pull .env.local

# 5. 푸시하면 끝
git push

vercel.json 도 거의 필요 없다. 미리보기 환경, 도메인, HTTPS, 이미지 최적화는 자동이다. 백그라운드 워커가 필요하면? Vercel Cron 또는 Vercel Queues — 베타 — 를 쓰거나, 외부 큐 — Inngest, Trigger.dev — 를 붙여야 한다. Vercel 안에서 "항상 켜진 워커" 를 돌릴 방법은 없다.

2.2 Vercel 의 적합 영역

Vercel 은 Next.js · React Router · SvelteKit · Astro 처럼 프레임워크 빌드가 정형화된 앱에 최적이다. SSG 중심 사이트 — 회사 블로그, 마케팅, 문서 — 도 무료 티어로 충분하다. AI 인터페이스 — 채팅, 코드 보조, 콘텐츠 생성 — 은 ai-sdk 와 AI Gateway 가 워크플로우를 짧게 만든다.

반면 항상 켜진 Express/Fastify 서버, Postgres + Redis + 워커가 같은 박스에서 도는 모놀리스, WebSocket 이 중심인 실시간 앱, gRPC 같은 워크로드는 Vercel 에 맞지 않는다. 굳이 우겨 넣을 수는 있지만 가격과 운영이 다 별로다.

3장. Netlify — Vercel 의 형, 살아남은 형

Netlify 는 Vercel 보다 먼저 시작했다. 2014 년 창업, "JAMstack" 이라는 단어를 만든 회사다. Vercel 이 2017 년에 시작해 Next.js 를 등에 업고 추월하기 전까지 Netlify 가 그 자리에 있었다.

2026 년 Netlify 는 작은 형의 자리다. Next.js 의 본가는 Vercel 에 빼앗겼고, 가격 모델도 비슷한 방향으로 따라갔다. 그래도 Netlify 가 살아남은 이유는 두 가지다.

첫째, Next.js 외 프레임워크에 더 친화적이다. Astro, Remix, SvelteKit, Hugo, Eleventy, Gatsby — 모두 Netlify 에서 잘 돌아간다. Vercel 도 다른 프레임워크를 지원하지만 "Next.js 가 1 등 시민, 그 외는 2 등" 의 분위기가 있다. Netlify 는 그 분위기가 덜하다.

둘째, 빌드 환경의 안정성이다. Netlify 의 빌드 시스템은 오래되었고 그만큼 깊이가 있다. 큰 모노레포의 SSG 빌드를 안정적으로 굴리는 데는 Netlify 가 여전히 우세하다는 보고가 많다.

가격은 Vercel 과 거의 평행하다. Free 티어 — 100GB 대역폭, 빌드 분 300 — , Pro $19/월/석. 함수 호출과 Edge Functions 도 비슷한 단위로 과금한다. Netlify Blobs — Object Storage — 와 Netlify Forms — 폼 제출 처리 — 는 Vercel 에 없는 작은 차별점이다.

문제는 같다. 영속 디스크가 없고, 워커가 약하고, Postgres 와 Redis 는 별도다. Netlify Postgres 는 2026 년 베타에 있지만 Neon 의 OEM 이라는 점에서 Vercel Postgres 와 같은 위치다.

언제 Netlify 를 고르는가. Next.js 가 아닌 프레임워크의 SSG/SSR 사이트, 모노레포 SSG, 이미 Netlify 에서 잘 돌고 있는 사이트의 마이그레이션 비용이 부담되는 경우. 새 Next.js 프로젝트라면 굳이 Netlify 를 고를 이유는 없다.

4장. Render — "Heroku 가 그리워? 우리가 Heroku 다"

Render 는 2019 년에 등장한 PaaS 다. 처음부터 "Heroku 의 후계자" 를 명시적으로 표방했다. 2022 년 Heroku 무료 티어 사망 이후 가장 큰 수혜자가 Render 였다.

Render 의 슬로건이 통하는 이유. Heroku 가 잘 했던 것 — Postgres, Redis, 백그라운드 워커, 크론, 영속 디스크, 단순한 가격 — 을 Render 가 모두 한 곳에서 제공한다. render.yaml 한 파일에 웹 서비스 + 워커 + 크론 + Postgres + Redis 를 선언하면 그대로 굴러간다.

2026 년 가격 모델은 단순하다. Web Service · Background Worker · Private Service 는 인스턴스 시간 과금이다. Starter $7/월, Standard $25/월, Pro $85/월 정도가 기본 라인이다. Postgres 는 Starter $7/월 (256MB RAM, 1GB storage), Standard $20/월 부터 시작한다. Redis 도 비슷한 라인. Persistent Disk 는 GB 당 월 $0.25. Cron Job 은 무료 — 실행 시간만 과금.

$5k/월 SaaS 의 Render 청구서를 추정하면, Web Service 한 대 ($25) + Worker 한 대 ($25) + Postgres Standard ($20) + Redis Starter ($10) + 디스크 10GB ($2.5) = 월 $82.5. 같은 워크로드를 Vercel + Neon + Upstash 로 짜면 $150–$300 사이가 일반적이다. Render 가 단순히 더 싸다.

Render 의 함정. 첫째, 콜드 스타트가 아니라 "슬립" 이 있다 — Free 티어에 한해. 무료 인스턴스는 15 분 비활성이면 잠들고, 다음 요청에서 20–30 초 정도 깨어나는 시간이 든다. 유료 티어는 항상 켜져 있다. 둘째, 글로벌 멀티 리전 배포는 약하다. Render 는 리전 — Oregon, Ohio, Virginia, Frankfurt, Singapore — 을 선택하지만 한 서비스를 여러 리전에 동시에 띄우는 것은 비교적 최근 기능이고 Fly.io 만큼 매끄럽지 않다.

4.1 Render 에 Next.js + Postgres + Redis + Worker 배포

# render.yaml
services:
  - type: web
    name: app
    runtime: node
    buildCommand: pnpm install && pnpm build
    startCommand: pnpm start
    envVars:
      - key: DATABASE_URL
        fromDatabase:
          name: app-db
          property: connectionString
      - key: REDIS_URL
        fromService:
          type: redis
          name: app-redis
          property: connectionString
  - type: worker
    name: worker
    runtime: node
    buildCommand: pnpm install && pnpm build:worker
    startCommand: pnpm start:worker
  - type: redis
    name: app-redis
    ipAllowList: []
    plan: starter

databases:
  - name: app-db
    plan: starter
    region: oregon

이 파일을 푸시하면 끝이다. Vercel 의 미니멀리즘과 Heroku 의 풀스택을 합친 느낌이다.

5장. Fly.io — Docker 우선, 글로벌 우선

Fly.io 는 다른 PaaS 와 출발이 다르다. 처음부터 Docker 와 멀티 리전 이 일급 시민이었다. 2026 년 현재 Fly.io 의 사용자 경험은 크게 두 번 갈아엎혔다 — 첫 번째는 Nomad 기반 Apps v1, 두 번째는 Firecracker MicroVM 기반 Machines / Apps v2.

Fly Machines 의 본질. Fly Machine 은 Firecracker MicroVM 하나다 — KVM 의 가벼운 가상 머신, AWS Lambda 가 쓰는 것과 같은 기술. 시작 시간은 250ms 수준, 정지·재개 — fly machine stop / start — 가 가능하고, 한 앱이 여러 리전에 여러 Machine 을 가질 수 있다. 가격은 Machine 의 CPU/메모리 시간으로 과금하되, 정지 상태에서는 거의 무료에 가깝다 (스토리지 비용만).

Fly Postgres 와 Volumes. Postgres 는 Fly 가 직접 운영하는 것이 아니라 — 정확히는 2024 년에 매니지드 운영을 종료하고 — Supabase Postgres on Fly 또는 직접 Postgres MicroVM 을 띄우는 모델로 갔다. Volume — 영속 디스크 — 은 살아 있고, Machine 에 직접 마운트한다.

fly.toml 한 파일이면 충분하다.

# fly.toml
app = "my-saas"
primary_region = "nrt"

[build]
  dockerfile = "Dockerfile"

[env]
  PORT = "8080"

[[services]]
  internal_port = 8080
  protocol = "tcp"
  auto_stop_machines = true
  auto_start_machines = true
  min_machines_running = 1

  [[services.ports]]
    handlers = ["http"]
    port = 80

  [[services.ports]]
    handlers = ["tls", "http"]
    port = 443

[mounts]
  source = "data"
  destination = "/app/data"

fly deploy 한 번이면 끝이다. 멀티 리전을 원하면 fly scale count 1 --region nrt,sin,fra 같은 명령어 한 줄.

Fly 의 가격. 가장 작은 Machine — shared-cpu-1x · 256MB — 은 월 $2 안쪽. 일반 워크로드 — shared-cpu-2x · 1GB — 는 월 $5–$10 정도. 대역폭은 북미 · 유럽에서 GB 당 $0.02. $5k/월 SaaS 의 Fly 청구서는 Render 와 비슷하거나 약간 싸게 나오는 경우가 많다 — 다만 운영 자동화 — Postgres 백업, Redis HA — 를 본인이 더 많이 해야 한다.

Fly 의 함정. 첫째, 운영 부담이 크다. Render 가 자동으로 해 주는 것 — Postgres 백업, 모니터링, 알람 — 을 Fly 에서는 본인이 짜야 한다. 둘째, 로컬 디버깅이 어렵다. Firecracker MicroVM 의 특성상 SSH 가 아니라 fly ssh console 로 들어가고, 실수로 영속 디스크를 날리면 복구가 어렵다.

5.1 Fly 의 진짜 강점 — 멀티 리전 사소함

다른 PaaS 에서 한 앱을 도쿄, 싱가포르, 프랑크푸르트 세 리전에 동시에 띄우는 것은 일 — Render 는 최근에야, Vercel 은 엣지로만, Cloud Run 은 리전마다 별도 배포. Fly 에서는 한 줄. 글로벌 SaaS 의 지연 시간을 50ms 이하로 잡고 싶다면 Fly 가 가장 적은 마찰로 그것을 한다.

6장. Railway — 분당 자원 단위, 우아한 UX

Railway 는 2020 년에 시작했다. 처음부터 "Heroku 가 그리워? 우리도 그렇다" 진영이었고, 2026 년 현재 가장 우아한 UX 를 가진 PaaS 다. 대시보드를 보는 것만으로도 다른 PaaS 와 차이가 느껴진다.

Railway 의 차별점. 첫째, 자원 단위 분당 과금. Vercel 의 Active CPU 와 유사하지만, Railway 는 Web 서비스에도 동일하게 적용된다. CPU 분당 $0.000463, 메모리 GB 분당 $0.000231 정도. 한 서비스가 유휴 상태일 때 — 트래픽이 없을 때 — 청구가 거의 0 으로 떨어진다. 단, Railway 는 0 으로 완전히 스케일 다운하지는 않는다 — 인스턴스가 살아 있다.

둘째, Hobby Plan vs Pro Plan. Hobby 는 $5/월 베이스 — $5 만큼의 자원 크레딧이 포함되어 있다. Pro 는 $20/월 베이스 + 팀 협업 + 더 큰 인스턴스. 솔로 개발자는 Hobby 로 시작해 충분한 경우가 많다.

셋째, Postgres, Redis, MySQL, MongoDB 가 한 번의 클릭. 데이터베이스 인스턴스도 자원 단위 과금이라 작은 DB 는 월 $3–$5 수준.

$5k/월 SaaS 의 Railway 청구서. 트래픽 패턴에 따라 다르지만, 가벼운 SaaS — Web + Worker + Postgres + Redis — 는 월 $30–$80 사이가 흔하다. 무거운 SaaS — 큰 Postgres, 항상 켜진 워커 — 는 $150–$300. Render 와 비슷하거나 약간 싸다.

Railway 의 함정. 첫째, 분당 과금이 무거운 워크로드에서 비싸진다. 항상 켜진 큰 인스턴스를 굴리면 Render 의 평탄한 인스턴스 시간 과금이 더 예측 가능하다. 둘째, 백업과 멀티 리전이 약하다 — Render 보다도. 셋째, Free 티어가 사실상 없다 — $5 베이스가 진입 장벽이다.

6.1 Railway 의 매력 — Code-Free 인프라

Railway 의 진짜 매력은 대시보드다. Postgres 추가, Redis 추가, 환경 변수 공유, 사설 네트워크, 도메인 — 모두 클릭 몇 번. render.yaml 이나 fly.toml 같은 설정 파일을 쓰지 않아도 된다. 이것이 솔로 개발자에게 큰 차이다.

# Railway CLI 만으로도 가능
npm i -g @railway/cli
railway login
railway init my-saas
railway add postgresql
railway add redis
railway up

7장. Northflank — 멀티 클라우드, 시리어스 팀의 PaaS

Northflank 는 2020 년 런던에서 시작했다. 다른 PaaS 보다 한 단계 위의 추상화를 노렸다. 한 마디로 "PaaS 인데 Kubernetes 처럼 강력한".

Northflank 의 차별점. 첫째, 멀티 클라우드 / BYOC. 본인의 AWS · GCP · Azure 계정에 Northflank 를 띄울 수 있다. 데이터 주권이 중요하거나 기존 클라우드 크레딧을 쓰고 싶은 팀의 선택. 둘째, Job 과 Cron 의 일급 지원. Render 의 Cron 보다 더 풍부한 스케줄러. 셋째, Build Pipeline. Docker 빌드를 Northflank 안에서 실행하고 결과물을 다른 Northflank 서비스에 자동 배포.

가격은 Render 와 비슷한 라인이다. 작은 인스턴스 $5–$10/월, 표준 $25–$50/월. Postgres · Redis · MySQL · MongoDB 도 매니지드로 제공된다.

Northflank 의 함정. 첫째, 러닝 커브가 PaaS 중 가장 높다. UI 가 강력한 만큼 복잡하다. 둘째, 커뮤니티가 작다 — Render, Fly, Railway 보다 사용자가 적어서 검색해 나오는 답이 적다. 셋째, 솔로 개발자의 첫 선택으로는 과하다 — 보통은 시리어스 팀의 두 번째 PaaS.

언제 Northflank 를 고르는가. 본인 클라우드 계정에 배포하고 싶을 때, 데이터 주권 — GDPR, 한국 개인정보보호법, 의료/금융 규제 — 때문에 위치를 통제하고 싶을 때, Kubernetes 까지는 가지 않으면서도 PaaS 보다 더 많은 통제권이 필요할 때.

8장. Heroku — 죽었다는 소문은 과장이었다

Heroku 는 2007 년에 시작해, 2010 년 Salesforce 에 인수되어, 2022 년 무료 티어를 죽이며 많은 적을 만들었다. 그러나 죽지는 않았다. 2026 년 현재 Heroku 는 살아 있고, Heroku-24 스택 (Ubuntu 24.04 LTS 기반), Postgres 17, PCI · HIPAA 컴플라이언스, Salesforce 통합 까지 갖춘 엔터프라이즈 PaaS 다.

Heroku 가 살아 있는 이유. 첫째, 이미 Heroku 에서 잘 굴러가는 앱이 너무 많다. 큰 회사가 Heroku 에 5–10 년 운영한 모놀리스를 떠나는 비용이 들어오는 비용의 10 배다. 둘째, Salesforce 생태계와의 통합. SFDC 와 Heroku Connect 로 양방향 동기화하는 워크플로우는 Heroku 만 가능. 셋째, Eco · Basic Dyno 가 무료 티어 자리를 일부 복원했다 — Eco Dyno $5/월 에 1,000 시간, 슬립 가능. Basic Dyno $7/월 항상 켜짐.

가격. Eco $5, Basic $7, Standard-1X $25, Standard-2X $50, Performance-M $250. Postgres 는 Mini $5, Basic $9, Standard-0 $50, Standard-2 $200 ... . Redis 는 Mini $3, Premium $15 부터. 같은 워크로드를 Render · Railway · Fly 에서 짜면 보통 20–40% 싸다.

Heroku 를 새로 고를 이유. 한 가지뿐이다 — Salesforce 와의 통합. 그 외 새 프로젝트가 굳이 Heroku 를 고를 이유는 약하다.

9장. Cloud Run — GCP 의 숨겨진 챔피언

Cloud Run 은 PaaS 비교 글에서 자주 빠진다. 이유는 단순하다 — GCP 콘솔의 UX 가 다른 PaaS 보다 복잡하고, GCP 의 무료 크레딧을 다 쓴 사람만 진심으로 청구서를 본다. 그러나 청구서를 본 사람 중 다수가 Cloud Run 의 팬이 된다.

Cloud Run 의 본질. 컨테이너를 푸시하면 요청당 인스턴스 로 자동 스케일링된다. 요청이 없으면 0 으로 떨어진다. 요청이 들어오면 100ms 안에 깨어난다. 인스턴스가 한 번에 동시 처리할 수 있는 요청 수 — concurrency — 를 본인이 정할 수 있고, 기본값은 80 이다.

가격이 미친 이유. 100ms 단위 과금 + 0 으로 스케일 다운 + 매달 첫 240,000 vCPU-초 와 450,000 GiB-초 무료. 작은 SaaS — $5k/월 매출, 트래픽 일 1–5 만 — 의 Cloud Run 청구서는 종종 월 $5–$50 수준이다. 같은 워크로드의 Vercel 청구서는 $150–$600, Render 는 $80–$150.

Cloud Run 의 함정. 첫째, GCP 의 다른 서비스를 같이 써야 한다. Cloud SQL — Postgres — 은 별도 청구, Cloud Memorystore — Redis — 은 비싸다, Cloud Storage — Object — 은 별도. GCP 안에서 전부 닫으면 결국 다른 PaaS 와 비슷한 가격이 될 수 있다. 둘째, 요청당 인스턴스 모델은 WebSocket · gRPC streaming 에 부적합 — Cloud Run 2 세대가 일부 지원하지만 제약이 있다. 셋째, 콜드 스타트가 0 은 아니다 — 첫 요청은 100ms–수 초 사이 (이미지 크기와 의존성에 따라).

9.1 Cloud Run 에 Next.js 배포

# 1. Dockerfile 작성
# (Next.js 공식 Dockerfile 예시 사용)

# 2. Cloud Build + Cloud Run 동시 배포
gcloud run deploy my-saas \
  --source . \
  --region asia-northeast1 \
  --allow-unauthenticated \
  --memory 512Mi \
  --cpu 1 \
  --concurrency 80 \
  --min-instances 0 \
  --max-instances 100

# 3. Cloud SQL Postgres 연결
gcloud run services update my-saas \
  --add-cloudsql-instances PROJECT:REGION:INSTANCE \
  --set-env-vars DATABASE_URL=postgres://...

--min-instances 1 로 두면 콜드 스타트가 사라지지만, 항상 켜진 인스턴스 한 대의 시간 과금이 들어간다. 그래도 다른 PaaS 의 항상 켜진 인스턴스보다는 보통 싸다.

10장. AWS App Runner / ECS Fargate — AWS 출구

이미 AWS 안에 모든 것이 있는 팀이라면 다른 PaaS 를 추가로 도입하는 비용이 부담스러울 수 있다. 그 팀의 PaaS 출구가 App Runner 와 ECS Fargate 다.

App Runner. 컨테이너 또는 GitHub 저장소를 푸시하면 자동 빌드 · 배포. Cloud Run 과 비슷하지만 항상 켜진 모델이다 — 0 으로 스케일 다운하지 않는다. 가격은 vCPU 분당 $0.064, 메모리 GB 분당 $0.007 정도. $5k/월 SaaS 의 App Runner 청구서는 보통 $80–$200.

App Runner 의 위치. AWS 콘솔 안에서 다른 AWS 서비스 — RDS, ElastiCache, S3, SQS — 와 매끄럽게 통합된다. AWS 가 1 등 시민인 팀에서는 가치가 있다. 그러나 AWS 밖의 PaaS — Render, Railway, Fly — 가 같은 워크로드를 더 싸고 더 쉽게 한다.

ECS Fargate. Container as a Service. ECS 의 Task Definition 을 정의하고 Fargate 로 띄운다. PaaS 보다 한 단계 낮은 추상화 — VPC, ALB, IAM, Task Role 을 본인이 짜야 한다. 그러나 통제권은 그만큼 크다. 큰 팀의 메인 워크로드는 ECS Fargate 또는 EKS 에 있는 경우가 많고, App Runner 와 PaaS 는 보조 워크로드용이다.

가격 비교. 같은 1 vCPU + 2GB 메모리를 한 달 항상 켜진 상태로 굴리면, ECS Fargate 는 약 $36/월, App Runner 는 약 $40–$50/월. Render 의 Standard 가 $25/월, Fly 의 dedicated-cpu-1x 가 $30/월. AWS 가 약간 더 비싸지만 다른 AWS 서비스와의 통합 가치가 그 차이를 채울 수 있다.

11장. Coolify · Dokku — "PaaS 비용이 미쳤다, 내가 호스팅한다"

PaaS 비용이 거슬리는 부류는 항상 있다. "Hetzner VPS 가 월 $5 에 4 vCPU + 8GB 메모리를 주는데, Render 에서 같은 사양이 $85 인 것이 말이 되는가?" 그 부류의 도구가 Coolify 와 Dokku 다.

Coolify. 2022 년에 등장해 2025 년경 폭발적으로 성장한 오픈소스 셀프 호스팅 PaaS. 본인의 VPS — Hetzner, DigitalOcean, OVH — 에 Coolify 를 설치하면 그 위에서 Heroku 같은 경험이 가능하다. GitHub 연동, 자동 배포, 도메인, HTTPS — Let's Encrypt 자동 — , Postgres · Redis · MySQL · MongoDB 매니지드, 모니터링까지.

Coolify 의 진짜 가격. Coolify 자체는 무료다 (Pro $5/월 은 클라우드 호스팅된 Coolify 인스턴스의 가격). VPS 비용 — Hetzner CX31 (2 vCPU, 8GB) 가 월 $13 — 만 든다. 한 VPS 에 10 개 앱을 굴리면 앱당 월 $1.3 이다. Render 의 1/20 가격이다.

Coolify 의 함정. 첫째, 본인이 운영해야 한다. OS 업데이트, 보안 패치, 백업, 모니터링 — 모두 본인 일이다. 둘째, HA 가 약하다. 단일 VPS 에 모든 것이 있으면 그 VPS 가 죽을 때 모든 앱이 죽는다. Coolify 의 클러스터 기능 — 멀티 노드 — 은 베타. 셋째, 러닝 커브가 의외로 있다. PaaS 의 단순함을 기대하면 처음 두 주가 힘들다.

Dokku. 2013 년부터 살아 있는 오픈소스 미니 Heroku. Coolify 보다 더 단순하고, GUI 가 없고 (커뮤니티 GUI 는 있다), CLI 로만 동작한다. dokku apps:create my-app, git push dokku main — Heroku 의 CLI 와 거의 같다. 솔로 개발자가 자기 VPS 에 Dokku 를 깔고 5 개의 작은 앱을 굴리는 것은 2026 년에도 합리적인 선택이다.

언제 Coolify / Dokku 를 고르는가. 돈을 아끼고 싶고, 운영을 배우고 싶고, HA 가 절대적이지 않은 사이드 프로젝트. 본 업무 SaaS 에는 보통 부적합 — 한 번 다운되면 비즈니스 임팩트가 VPS 비용 절약을 압도한다.

12장. 비용 매트릭스 — $5k/월 SaaS 의 실제 청구서

다음은 같은 워크로드 — Next.js 14 앱 + Postgres (10GB, 약간의 워크로드) + Redis (256MB) + 백그라운드 워커 1 대 — 를 각 PaaS 에 배포했을 때의 추정 월 청구서다. 트래픽은 월 100만 페이지뷰, 일 평균 3 만 요청을 가정한다.

PaaSWebWorkerPostgresRedis디스크/스토리지대역폭합계
Vercel + Neon + Upstash$20 Pro + $50–$200 사용량(외부 큐) $20+Neon $19+Upstash $10+별도포함$120–$300
Netlify + Supabase$19 Pro + $30–$150 사용량(외부)Supabase $25+(Supabase)별도포함$80–$250
Render$25 Standard$25 Standard$20 Standard$10 Starter$2.5 10GB$0 100GB 무료$82.5
Fly.io$10 Machine$10 Machine$15 Postgres MicroVM$5 Redis MicroVM$2.5 10GB$2 100GB$44.5
Railway$15 분당$10 분당$10 분당$5 분당포함포함$40–$60
Northflank$25$25$20$10$2.5포함$82.5
Heroku$25 Standard-1X$25 Standard-1X$50 Standard-0$15 Premium(Add-on)포함$115
Cloud Run + Cloud SQL$5–$30 100ms$5–$20 100msCloud SQL $30Memorystore $50+GCS $1$10$100–$140
App Runner + RDS$50–$100$50–$100RDS $30ElastiCache $30S3 $1$10$170–$270
Coolify on Hetzner(전부 한 VPS)(포함)(포함)(포함)(포함)(포함)$13 VPS
Dokku on Hetzner(전부 한 VPS)(포함)(포함)(포함)(포함)(포함)$13 VPS

해석. 가격만 보면 Coolify · Dokku 가 압도적으로 싸다. 그러나 그것은 본인이 운영하는 비용 — 시간 + 위험 — 을 빼고 본 수치다. 매니지드 PaaS 중에서는 Railway 와 Fly.io 가 가장 싸고, Render 가 그 다음, Vercel · Heroku · App Runner 가 가장 비싸다.

가격은 한 축일 뿐이다. 다른 축 — 운영의 단순함, 워크로드 적합도, 마이그레이션 비용, 팀 합의 — 을 함께 보지 않으면 결정이 틀린다.

13장. 콜드 스타트의 진실

"콜드 스타트" 라는 단어가 2026 년에도 PaaS 논쟁의 중심에 있다. 진실은 이렇다.

0 으로 스케일 다운하는 플랫폼만 콜드 스타트가 있다. 항상 켜진 PaaS — Render, Railway, Heroku, Northflank — 에는 콜드 스타트가 없다. 다만 인스턴스가 죽고 재시작될 때의 시간이 있는데, 이것은 콜드 스타트보다는 짧다.

Vercel · Netlify · Cloud Run · Fly Machines (auto_stop) 는 콜드 스타트가 있다. 일반적인 콜드 스타트 시간:

  • Vercel Functions — Node.js 작은 함수 100–500ms, 큰 SSR 1–3 초
  • Netlify Functions — 비슷한 라인
  • Cloud Run — 100ms–2 초, 이미지 크기에 큰 영향
  • Fly Machines (auto_stop) — 250–500ms, Firecracker 의 강점
  • AWS Lambda — Node 100–500ms, Java/Python 더 길다

콜드 스타트가 문제가 되는 워크로드. 실시간 채팅, 게임, 트레이딩, 결제 처리. 사용자가 첫 요청에서 2 초를 기다리는 것이 사업적으로 손해인 경우.

해법 세 가지. (1) Min instances ≥ 1 — Cloud Run 과 Fly Machines 모두 지원. 항상 켜진 인스턴스 한 대를 두어 첫 요청을 받게 한다. (2) Provisioned Concurrency — AWS Lambda 의 기능. (3) 항상 켜진 PaaS 로 옮긴다.

14장. 영속 디스크의 황혼과 부활

2018–2022 년 사이 PaaS 의 큰 추세는 "영속 디스크는 안티 패턴" 이었다. 모든 상태는 외부 — Postgres, Redis, S3 — 로 보내고 컴퓨트는 stateless 로 두는 것이 모범이었다. Vercel · Netlify 가 그 방향을 극단으로 밀었다.

2023–2026 년 추세는 일부 되돌아왔다. 영속 디스크가 필요한 워크로드가 다시 보였다.

  • SQLite + Litestream — SaaS 의 가장 단순한 데이터 계층. 한 VM 안에 SQLite 와 앱이 같이 살고, Litestream 이 S3 로 비동기 백업. Fly.io 와 Render 는 이 패턴을 잘 지원한다.
  • 벡터 DB self-hosted — pgvector, Qdrant, Weaviate 를 본인 인스턴스에 띄울 때 영속 디스크가 필요하다.
  • 파일 처리 워크플로우 — 이미지 변환, 비디오 트랜스코드, 큰 파일 임시 저장.
  • 로컬 캐시 — Redis 를 안 쓰는 경우의 디스크 캐시.

영속 디스크가 필요한가? Render, Fly.io, Railway, Northflank, Coolify · Dokku 를 본다. Vercel, Netlify, Cloud Run, App Runner 는 후보에서 빠진다.

15장. 백그라운드 워커의 현실

"백그라운드 워커" 는 SaaS 의 숨은 절반이다. 이메일 발송, 결제 웹훅 처리, 비디오 변환, 리포트 생성, 정기 데이터 동기화 — 모두 워커가 한다. PaaS 의 워커 지원 수준은 크게 갈린다.

일급 지원 — Render, Railway, Fly.io, Northflank, Heroku, Coolify. 워커 = 항상 켜진 프로세스. worker.js 를 시작하고 큐를 폴링하거나 메시지를 받으면 된다.

부분 지원 — Cloud Run Jobs, App Runner. Cloud Run Jobs 는 실행 가능한 워커지만 항상 켜진 워커는 아니다 — 호출되면 실행되고 끝난다. 큐 폴링 워커는 Cloud Run 에서는 어색하다.

약함 — Vercel, Netlify. Vercel Queues 가 베타에 있지만, 항상 켜진 워커 모델은 없다. 외부 워커 인프라 — Inngest, Trigger.dev, Defer, Hatchet — 를 붙이는 것이 일반적인 해법이다. 이것이 Vercel 의 진짜 비용 증가 요인이다.

워커가 무거운 SaaS — 이미지/비디오 처리, AI 추론, ETL — 라면 Vercel 보다는 Render · Fly · Railway 가 거의 항상 더 적합하다.

16장. 멀티 리전 — 글로벌 SaaS 의 현실

글로벌 사용자를 가진 SaaS 의 지연 시간을 50ms 이하로 잡고 싶다면 멀티 리전이 필요하다. 멀티 리전 지원의 현실은 이렇다.

가장 매끄러움 — Fly.io. fly scale count 1 --region nrt,sin,fra,iad 한 줄. 멀티 리전 Postgres 도 Fly 가 한때 잘 했고 (현재는 Supabase 와 협력 모델).

자동 엣지 — Vercel, Netlify. Edge Functions 와 정적 자산은 전 세계 엣지에 자동 배포. 그러나 데이터베이스는 엣지에 없다 — Neon, PlanetScale, Supabase 등이 멀티 리전 읽기 복제본을 제공.

리전 선택 가능 — Render, Railway, Northflank, Heroku. 한 서비스를 한 리전에 배포하지만 같은 서비스를 여러 리전에 동시 배포는 비교적 최근 기능이거나 베타. 글로벌 SaaS 의 첫 후보는 아니다.

자동 글로벌 — Cloud Run. --region 을 여러 개 지정하면 여러 리전에 같은 서비스를 띄울 수 있다. 단, Load Balancer 와 Cloud Run multi-region 설정을 본인이 짜야 한다.

글로벌 멀티 리전이 필수라면 Fly.io 가 가장 적은 마찰, Cloud Run 이 그 다음, Vercel + 글로벌 DB 가 그 다음이다.

17장. 결정 프레임 — 어느 PaaS 를 골라야 하는가

PaaS 선택의 단순한 결정 트리는 이렇다.

시작점: 어떤 앱인가?

  1. Next.js · React Router · SvelteKit 위주의 SSG/SSR + 가벼운 API → Vercel (또는 Netlify). 다른 옵션은 가격이 비슷하거나 더 비싸고, Vercel 의 통합 가치가 크다.
  2. 모놀리스 — Web + 워커 + DB + Redis 가 한 박스에서 도는 앱 → Render (또는 Railway). Heroku 같은 경험을 가장 잘 제공한다.
  3. 글로벌 사용자, 멀티 리전 필수 → Fly.io. 가장 적은 마찰.
  4. AWS 안에 모든 것이 있는 팀 → App Runner 또는 ECS Fargate. AWS 출구.
  5. 본인 클라우드 / 데이터 주권 → Northflank.
  6. 돈을 극단적으로 아끼고 운영 학습에 시간이 있는 솔로 → Coolify on Hetzner 또는 Dokku.
  7. 이미 GCP → Cloud Run + Cloud SQL.
  8. Salesforce 통합 → Heroku.

팀 규모로 다시 보면:

  • 솔로 / 사이드 프로젝트 — Vercel (Hobby) · Fly · Railway · Coolify
  • 2–5 명 작은 팀 — Vercel Pro · Render · Railway · Fly
  • 5–20 명 시리어스 SaaS — Render · Railway · Northflank · Fly
  • 20+ 명 / 컴플라이언스 필요 — Northflank · Heroku · App Runner · Cloud Run

시간으로 보면 (러닝 커브 짧은 순):

Vercel > Railway > Render > Heroku > Netlify > Fly > Cloud Run > Coolify > Northflank > App Runner > ECS Fargate.

18장. 안티 패턴 모음

PaaS 선택을 망치는 흔한 패턴을 정리한다.

1. 가격만 보고 결정 — Coolify on VPS 가 $13/월 이라고 본업 SaaS 를 거기에 올렸다가 한 번 다운에 비즈니스가 멈춘다. 매니지드 PaaS 의 $80 은 비싼 것이 아니라 보험료다.

2. "Vercel 이 다 한다" 가정 — Next.js 만 잘 하는 것이지 모든 워크로드를 잘 하는 것이 아니다. 항상 켜진 워커, 큰 모놀리스, WebSocket 중심 앱은 Vercel 밖이 더 낫다.

3. PaaS 안의 매니지드 DB 사용으로 시작 — Vercel Postgres, Render Postgres, Railway Postgres 는 시작하기 쉽지만 이전 비용이 크다. 처음부터 Neon / Supabase / PlanetScale 같은 독립 매니지드 DB 를 쓰면 PaaS 만 갈아끼울 수 있다.

4. 멀티 리전을 너무 일찍 도입 — 사용자가 한 대륙에 있는데 멀티 리전을 굳이 한다. 단일 리전 + CDN 으로 충분한 경우가 많다.

5. Free 티어를 본업에 사용 — Free 의 콜드 스타트, 슬립, 작은 리소스가 사용자 경험을 망친다. 본업은 유료 티어로 시작한다.

6. 콜드 스타트 무시 — Vercel · Cloud Run 의 콜드 스타트를 모르고 들어갔다가 첫 요청 1–3 초에 사용자가 떠난다. min instances ≥ 1 또는 항상 켜진 PaaS 로 옮긴다.

7. 백업과 모니터링을 PaaS 가 다 해 줄 것으로 가정 — Render · Railway 의 자동 백업은 일정 보관 기간만 보장한다. 본인이 추가 백업을 가져가지 않으면 사고 시 복구가 안 된다.

8. "PaaS 비용이 미쳤다" 라고 Kubernetes 로 이전 — PaaS 의 월 $200 이 미쳤다고 EKS 로 가면 EKS 의 $73/월 컨트롤 플레인 + 노드 비용 + 운영 시간 (= 주당 5 시간) 으로 결국 더 비싸진다. PaaS 가격이 거슬리면 먼저 같은 PaaS 카테고리 안에서 더 싼 곳 — Railway, Fly — 으로 옮기는 것을 시도한다.

에필로그 — 도구가 아니라 워크로드를 보라

PaaS 비교 글의 함정은 도구 중심 사고다. "Vercel vs Render" 가 아니라 "내 워크로드에 무엇이 맞는가" 가 질문이다. 같은 SaaS 라도 사용자 분포, 트래픽 패턴, 워커 부담, 데이터 크기, 컴플라이언스 요구가 다르면 답이 다르다.

2026 년의 풍경을 한 줄로 요약하면: Next.js = Vercel, 모놀리스 = Render, 글로벌 = Fly, 분당 과금 = Railway, 시리어스 멀티 클라우드 = Northflank, GCP = Cloud Run, AWS = App Runner, 셀프 호스팅 = Coolify. 이 8 개를 알면 새 프로젝트의 PaaS 결정은 거의 항상 5 분 안에 끝난다.

PaaS 선택 체크리스트

  • 내 앱이 0 으로 스케일 다운 가능한 워크로드인가? (콜드 스타트 허용?)
  • 영속 디스크가 필요한가?
  • 항상 켜진 워커가 필요한가? 워커가 무거운가?
  • 글로벌 사용자가 있는가? 50ms 이하 지연이 필수인가?
  • 매니지드 Postgres / Redis 를 PaaS 안에서 받을 것인가, 외부 (Neon / Supabase / Upstash) 로 분리할 것인가?
  • 컴플라이언스 — HIPAA, PCI, GDPR, 데이터 주권 — 가 필요한가?
  • 팀 규모와 운영 가용 시간은 얼마인가?
  • 떠나는 비용 — 다른 PaaS 로 이전 — 을 미리 계산했는가?
  • 청구서가 트래픽 10 배 늘 때 어떻게 변하는가?
  • 미리보기 환경, 롤백, 백업, 로그가 충분한가?

다음 글 예고

다음 글에서는 PaaS 위에 올라가는 매니지드 데이터베이스 — Neon · Supabase · PlanetScale · Turso · Cloudflare D1 · CockroachDB Serverless 를 같은 깊이로 비교한다. PaaS 결정의 절반은 DB 결정이다 — 그것을 분리해 보면 PaaS 결정이 더 자유로워진다.

참고 / References

PaaS Comparison 2026 — Vercel · Netlify · Render · Fly.io · Railway · Northflank · Heroku · Cloud Run · App Runner · Coolify: Where to Deploy in 2026

Prologue — Who Moved In When Heroku Moved Out

In 2022, Salesforce killed Heroku's free tier. That day, a generation of indie hackers screamed in unison on Twitter. "Heroku is dead. Where do we deploy now?" Out of that scream came four years of PaaS golden age, and by spring 2026 the landscape has finally taken shape.

Let's clear a myth first. Heroku is not dead. Salesforce killed the free tier and reorganized pricing — but as of 2026 Heroku is alive, supports the Heroku-24 stack, and runs Postgres 17. What it lost was the "default" slot. New projects no longer default to Heroku.

The empty slot has too many candidates. Vercel has become the de facto home of Next.js, absorbing v0 and the ai-sdk along the way, inventing the category "framework-first PaaS". Render has shouted "miss Heroku? we are Heroku" as a slogan and bundled persistent disks, cron, background workers, and Postgres in one place. Fly.io turned multi-region deploys into a trivial concern with its Docker-first global PaaS. Railway captured a new generation with per-minute resource billing and beautiful UX. Northflank caught serious teams' eye with multi-cloud / BYOC and richer primitives — Job, Cron, Volume, Build Pipeline. Netlify is Vercel's older sibling that lost the throne but survived by leaning into JS framework hosting.

There are dark horses cloud people love. Cloud Run — GCP's serverless container — destroys other PaaS on price for certain workloads with 100ms billing and scale-to-zero. AWS App Runner and ECS Fargate are the AWS-exit for teams that already live inside AWS. Coolify and Dokku are for the "PaaS pricing is insane, I'll host it myself" crowd.

This article compares these PaaS head-to-head on the same axes. After the comparison we ask the actual question — which tool for which scenario — across four cases: deploying a Next.js app, API + Postgres + Redis + worker stack, a global multi-region SaaS, and a $5k/mo full-stack app. Prices move fast. Every number is May 2026, and we focus on the structural differences. The decision framework must outlive the numbers.

Even within the same PaaS category, different billing models and runtime models can stretch a month's bill 10x. And the cost of leaving is 10x the cost of joining.

1. What Counts as a PaaS — Drawing the Boundary

To use the word "PaaS" in 2026 we need to draw the line first. The narrow definition — Platform as a Service — is what Heroku defined. One git push heroku main and the code is built, deployed, and a domain is attached. Infrastructure is invisible. Databases, caches, and queues are add-ons added with one line.

By that definition, Vercel · Netlify · Render · Fly.io · Railway · Northflank · Heroku · Coolify · Dokku are all PaaS. Push code, get a deploy.

There are borderline tools. Cloud Run is a serverless container platform — push a container and it autoscales. It sits one abstraction below the narrow PaaS — you bring Postgres and your build pipeline yourself — but in practice people use it like a PaaS. AWS App Runner sits in the same bucket. ECS Fargate and Kubernetes sit even lower — CaaS, Container as a Service, or IaaS.

This article covers the narrow PaaS plus Cloud Run and App Runner. ECS Fargate and EKS make cameo appearances in the comparison table but aren't main characters.

1.1 The Five Axes of a PaaS

If we don't compare on the same axes it isn't a comparison. Five axes first.

  • Build model — Buildpack? Dockerfile? Framework auto-detect? Nixpacks?
  • Runtime model — Always-on server? Scale-to-zero? Per-request instance?
  • Persistence — Persistent disk? Postgres? Redis? Object Storage?
  • Billing — Instance hours? CPU seconds? Request count? Bandwidth? Free tier?
  • Operations — Logs? Metrics? Secrets? Preview environments? Rollback? Multi-region?

A one-line summary of each PaaS on these axes:

PaaSBuildRuntimePersistent DiskBillingMulti-Region
VercelFramework autoServerless + Active CPUNo (Blob/KV add-on)Requests + Active CPU + bandwidthAuto edge
NetlifyFramework autoFunctions + EdgeNo (Blobs add-on)Build min + requests + bandwidthAuto edge
RenderNative + DockerAlways-on (per service)Yes (Disk)Instance hoursRegion pick
Fly.ioDockerfile + BuildpacksMachines (can scale to 0)Yes (Volumes)Machine hours + bandwidthMulti-region native
RailwayNixpacks + DockerAlways-onYes (Volume)Per-minute resourceRegion pick
NorthflankDockerfile + BuildpacksAlways-on + JobsYes (Volume)Instance hoursMulti-cloud
HerokuBuildpacks + DockerDyno (always-on)No (add-on)Dyno hoursRegion pick
Cloud RunBuildpacks + DockerPer-request instanceNo (GCS separate)CPU/memory secondsAuto global
App RunnerBuildpacks + DockerAlways-onNo (S3 separate)Instance hours + requestsSingle region
CoolifyDockerfile + BuildpacksYour serverYes (host disk)Your VPS costYour call

A pattern emerges already. Vercel · Netlify · Cloud Run are "scale-to-zero, no persistent disk", while Render · Fly.io · Railway · Northflank · Heroku are "always-on, persistent disk". That one line determines every price calculation and workload fit downstream.

2. Vercel — The Home of Next.js, and v0 Too

Vercel is the loudest PaaS in 2026. It's the de facto home of Next.js, the home of ai-sdk, the home of v0 — the AI that builds UI — and inventor of the AI Gateway category.

The good. If you use Next.js, you barely need to consider other options. One git push builds and deploys, every PR gets an auto preview environment, edge deploys are automatic, and image optimization and analytics come bundled. For a solo developer, "just deploy" is the Vercel definition.

The problem. Pricing. In late 2024 Vercel overhauled its billing model. The old "function invocation count + GB-Hr + bandwidth" became Active CPU. Active CPU bills only the time the CPU actually worked — waiting on an external API or DB I/O doesn't count. In theory, cheaper.

In practice. The pricing-page numbers — Active CPU $0.128 per hour, Provisioned Memory $0.0106 per GB-Hr, Edge Requests $2 per million — look reasonable. But the bill inflates fast as traffic grows. Especially Next.js apps drawing big pages through Server Components, where per-page Active CPU stretches.

What does a $5k/month SaaS spend on Vercel? Community reports — Reddit r/nextjs, the SaaS builders on Twitter — average somewhere between $150–$600 per month at the 10k–50k MAU traffic band. Above that, Pro at $20/seat plus usage overage stacks fast.

The real trap with Vercel is the absence of persistence. Postgres on Vercel is Vercel Postgres — actually a Neon OEM — and Redis is Vercel KV — actually an Upstash OEM. Both are extra cost and inflate separately with traffic. If you close everything inside Vercel and operate, you end up paying more than going to Neon and Upstash directly.

2.1 Deploying Next.js + Postgres + Redis on Vercel

Simplest workflow:

# 1. Create a Next.js app locally
npx create-next-app@latest my-saas

# 2. Link to Vercel
cd my-saas
vercel link

# 3. Add Vercel Postgres (= Neon) and Vercel KV (= Upstash)
vercel storage create postgres
vercel storage create kv

# 4. Pull env vars locally
vercel env pull .env.local

# 5. Push and you're done
git push

vercel.json is barely needed. Preview environments, domains, HTTPS, image optimization are automatic. Background worker? Vercel Cron, the beta Vercel Queues, or an external queue — Inngest, Trigger.dev. There is no way to run an always-on worker inside Vercel.

2.2 Where Vercel Fits

Vercel is optimal for Next.js · React Router · SvelteKit · Astro — apps whose framework build is standardized. SSG-centric sites — company blogs, marketing, docs — fit the free tier easily. AI interfaces — chat, code assistants, content generation — get a shorter workflow with ai-sdk and AI Gateway.

In contrast, always-on Express/Fastify servers, monoliths where Postgres + Redis + workers live in one box, WebSocket-heavy real-time apps, and gRPC are not a Vercel fit. You can force them in, but pricing and operations both suffer.

3. Netlify — The Older Sibling Who Survived

Netlify started before Vercel. Founded 2014, coined the word "JAMstack". Until Vercel started in 2017 and overtook by riding Next.js, Netlify held that throne.

In 2026 Netlify holds the younger-sibling seat. Next.js's primary residence moved to Vercel, and Netlify's pricing model has followed similar lines. Two reasons Netlify still matters.

First, better neutrality across frameworks. Astro, Remix, SvelteKit, Hugo, Eleventy, Gatsby — all run well on Netlify. Vercel supports other frameworks too, but with the air of "Next.js is first-class, everything else is second". Netlify has less of that air.

Second, stable build infrastructure. Netlify's build system is mature and deep. For big monorepo SSG builds, Netlify still has the edge in stability — many reports back this up.

Pricing largely parallels Vercel. Free tier — 100GB bandwidth, 300 build minutes — and Pro at $19/month/seat. Function invocations and Edge Functions bill similarly. Netlify Blobs — Object Storage — and Netlify Forms — form submission handling — are small differentiators Vercel lacks.

The problem is the same. No persistent disk, weak worker story, Postgres and Redis live elsewhere. Netlify Postgres is in beta in 2026 but as a Neon OEM it sits in the same seat as Vercel Postgres.

When to pick Netlify. Non-Next.js SSG/SSR sites, monorepo SSG builds, sites already running well on Netlify where migration cost is not worth it. For a new Next.js project there's not much reason to pick Netlify.

4. Render — "Miss Heroku? We Are Heroku"

Render arrived in 2019, explicitly positioning itself as "Heroku's successor". After Heroku's 2022 free-tier death, the biggest beneficiary was Render.

Why the slogan lands. What Heroku did well — Postgres, Redis, background workers, cron, persistent disk, simple pricing — Render offers in one place. One render.yaml declares web service + worker + cron + Postgres + Redis and it just runs.

The 2026 pricing model is simple. Web Service · Background Worker · Private Service bill on instance hours. Starter $7/month, Standard $25/month, Pro $85/month are the base lines. Postgres starts at Starter $7/month (256MB RAM, 1GB storage) and Standard $20/month. Redis has a similar line. Persistent Disk is $0.25 per GB-month. Cron Jobs are free — billed only for execution time.

Estimating the Render bill for a $5k/month SaaS: one Web Service ($25) + one Worker ($25) + Postgres Standard ($20) + Redis Starter ($10) + 10GB disk ($2.5) = $82.5/month. The same workload on Vercel + Neon + Upstash typically lands at $150–$300. Render is just cheaper.

The traps with Render. First, it's not a cold start but "sleep" — only on the free tier. Free instances go to sleep after 15 minutes of inactivity and take 20–30 seconds to wake on the next request. Paid tiers are always-on. Second, global multi-region deployment is weak. Render lets you pick a region — Oregon, Ohio, Virginia, Frankfurt, Singapore — but deploying the same service across multiple regions simultaneously is a relatively recent feature and not as smooth as Fly.io.

4.1 Deploying Next.js + Postgres + Redis + Worker on Render

# render.yaml
services:
  - type: web
    name: app
    runtime: node
    buildCommand: pnpm install && pnpm build
    startCommand: pnpm start
    envVars:
      - key: DATABASE_URL
        fromDatabase:
          name: app-db
          property: connectionString
      - key: REDIS_URL
        fromService:
          type: redis
          name: app-redis
          property: connectionString
  - type: worker
    name: worker
    runtime: node
    buildCommand: pnpm install && pnpm build:worker
    startCommand: pnpm start:worker
  - type: redis
    name: app-redis
    ipAllowList: []
    plan: starter

databases:
  - name: app-db
    plan: starter
    region: oregon

Push this file and you're done. It feels like Vercel minimalism plus Heroku's full-stack story combined.

5. Fly.io — Docker-First, Global-First

Fly.io starts differently from other PaaS. From day one, Docker and multi-region were first-class citizens. By 2026 Fly's user experience has been rebuilt twice — first as Nomad-based Apps v1, then as Firecracker-MicroVM-based Machines / Apps v2.

The essence of Fly Machines. A Fly Machine is one Firecracker MicroVM — KVM's lightweight VM, the same tech AWS Lambda uses. Boot time around 250ms, stop/resume — fly machine stop / start — is built in, and one app can hold multiple Machines across multiple regions. Pricing is CPU/memory-hours per Machine, but a stopped Machine costs near-zero (only storage).

Fly Postgres and Volumes. Fly doesn't operate managed Postgres directly anymore — actually, in 2024 it ended the managed offering — and now leans on Supabase Postgres on Fly or running a Postgres MicroVM yourself. Volumes — persistent disks — are alive and mount directly to a Machine.

One fly.toml is enough.

# fly.toml
app = "my-saas"
primary_region = "nrt"

[build]
  dockerfile = "Dockerfile"

[env]
  PORT = "8080"

[[services]]
  internal_port = 8080
  protocol = "tcp"
  auto_stop_machines = true
  auto_start_machines = true
  min_machines_running = 1

  [[services.ports]]
    handlers = ["http"]
    port = 80

  [[services.ports]]
    handlers = ["tls", "http"]
    port = 443

[mounts]
  source = "data"
  destination = "/app/data"

One fly deploy and you're done. Multi-region? fly scale count 1 --region nrt,sin,fra — one line.

Fly pricing. The smallest Machine — shared-cpu-1x · 256MB — runs under $2/month. Typical workloads — shared-cpu-2x · 1GB — run $5–$10/month. Bandwidth is $0.02 per GB in NA/EU. A $5k/month SaaS often comes in similar to or slightly cheaper than Render — though you do more operational work yourself (Postgres backups, Redis HA).

Fly's traps. First, operational burden is higher. Things Render does automatically — Postgres backups, monitoring, alarms — you write yourself on Fly. Second, local debugging is harder. Firecracker MicroVM means SSH-style entry is fly ssh console, and accidentally nuking a Volume is hard to undo.

5.1 Fly's Real Strength — Multi-Region Trivial

Deploying one app to Tokyo, Singapore, and Frankfurt simultaneously is a project on other PaaS — Render added it only recently, Vercel only at the edge, Cloud Run requires per-region deploys. On Fly it's one line. If you need to keep global SaaS latency under 50ms, Fly does that with the least friction.

6. Railway — Per-Minute Resources, Beautiful UX

Railway started in 2020. It belonged to the "miss Heroku? we do too" camp from day one, and by 2026 it has the most beautiful UX of any PaaS. Just looking at the dashboard you feel the difference.

Railway's differentiators. First, per-minute resource billing. Similar to Vercel's Active CPU, but Railway applies it uniformly to Web services too. CPU at roughly $0.000463 per minute, Memory at $0.000231 per GB-minute. When a service idles — no traffic — billing drops to near-zero. Note: Railway does not fully scale to zero — instances stay alive.

Second, Hobby Plan vs Pro Plan. Hobby at $5/month base — includes $5 of resource credits. Pro at $20/month base + team collaboration + larger instances. Solo developers often start fine on Hobby.

Third, Postgres, Redis, MySQL, MongoDB in one click. Database instances also bill on resources, so small DBs land at $3–$5/month.

The Railway bill for a $5k/month SaaS. Depends on traffic pattern, but a light SaaS — Web + Worker + Postgres + Redis — often lands at $30–$80/month. A heavy SaaS — large Postgres, always-on worker — at $150–$300. Similar to Render, sometimes a hair cheaper.

Railway's traps. First, per-minute billing gets expensive on heavy workloads. For always-on big instances, Render's flat instance-hours pricing is more predictable. Second, backups and multi-region are weaker — even more so than Render. Third, no real free tier — the $5 base is a barrier to entry.

6.1 The Railway Appeal — Code-Free Infrastructure

Railway's real appeal is the dashboard. Add Postgres, add Redis, share env vars, private networking, domains — all a few clicks. No render.yaml or fly.toml to write. For a solo developer this is a real difference.

# Railway CLI alone is enough
npm i -g @railway/cli
railway login
railway init my-saas
railway add postgresql
railway add redis
railway up

7. Northflank — Multi-Cloud, Serious Teams' PaaS

Northflank started in London in 2020. It aimed for one level of abstraction above other PaaS. In short, "a PaaS as powerful as Kubernetes".

Northflank's differentiators. First, multi-cloud / BYOC. You can run Northflank inside your own AWS · GCP · Azure account. The choice for teams with data sovereignty needs or existing cloud credit balances. Second, first-class Jobs and Cron. A richer scheduler than Render's Cron. Third, Build Pipelines. Run Docker builds inside Northflank and auto-deploy outputs to other Northflank services.

Pricing parallels Render. Small instances $5–$10/month, standard $25–$50/month. Postgres · Redis · MySQL · MongoDB are also offered as managed.

Northflank's traps. First, the steepest learning curve among PaaS. The UI is powerful and that means complex. Second, smaller community — fewer users than Render, Fly, Railway means fewer search results. Third, overkill as a solo developer's first pick — usually a serious team's second PaaS.

When to pick Northflank. Deploying inside your own cloud account, controlling location for data sovereignty — GDPR, Korea's PIPA, healthcare/finance regulation, needing more control than a PaaS without going all the way to Kubernetes.

8. Heroku — Rumors of Its Death Were Exaggerated

Heroku started in 2007, was acquired by Salesforce in 2010, and killed its free tier in 2022 — making many enemies. But it didn't die. As of 2026, Heroku is alive, with the Heroku-24 stack (Ubuntu 24.04 LTS base), Postgres 17, PCI / HIPAA compliance, and Salesforce integrations — an enterprise PaaS.

Why Heroku is still alive. First, too many apps already run well on Heroku. The cost for a big company to leave a Heroku monolith they've run for 5–10 years is 10x the cost of staying. Second, Salesforce ecosystem integration. Bidirectional sync with SFDC via Heroku Connect is uniquely a Heroku capability. Third, Eco · Basic Dyno partly restore the free-tier seat — Eco Dyno $5/month with 1,000 hours and sleep allowed, Basic Dyno $7/month always-on.

Pricing. Eco $5, Basic $7, Standard-1X $25, Standard-2X $50, Performance-M $250. Postgres Mini $5, Basic $9, Standard-0 $50, Standard-2 $200. Redis Mini $3, Premium from $15. The same workload on Render · Railway · Fly is usually 20–40% cheaper.

Reason to pick Heroku for a new project. One reason — Salesforce integration. Beyond that, a new project has weak reason to choose Heroku.

9. Cloud Run — GCP's Hidden Champion

Cloud Run often goes missing from PaaS comparison articles. The reason is simple — GCP's console UX is more complex than other PaaS, and only people who burned through GCP's free credits look at the real bill. But many who do become Cloud Run fans.

The essence of Cloud Run. Push a container and it autoscales per request. No requests, scale to zero. Requests come in, wakes up within 100ms. The concurrent requests one instance can handle — concurrency — is your choice, default 80.

Why pricing is insane. 100ms billing increments + scale-to-zero + first 240,000 vCPU-seconds and 450,000 GiB-seconds free per month. A small SaaS — $5k/month revenue, 10k–50k MAU traffic — often lands at $5–$50/month on Cloud Run. The same workload on Vercel is $150–$600, on Render $80–$150.

Cloud Run's traps. First, you need other GCP services around it. Cloud SQL — Postgres — bills separately, Cloud Memorystore — Redis — is expensive, Cloud Storage — Object — is separate. Close everything inside GCP and you end up similar to other PaaS pricing. Second, per-request instance is poor for WebSocket / gRPC streaming — Cloud Run 2nd gen helps but with limits. Third, cold start is not zero — first request takes 100ms–several seconds (depends on image size and dependencies).

9.1 Deploying Next.js on Cloud Run

# 1. Write a Dockerfile
# (use the standard Next.js Dockerfile example)

# 2. Cloud Build + Cloud Run in one shot
gcloud run deploy my-saas \
  --source . \
  --region asia-northeast1 \
  --allow-unauthenticated \
  --memory 512Mi \
  --cpu 1 \
  --concurrency 80 \
  --min-instances 0 \
  --max-instances 100

# 3. Connect Cloud SQL Postgres
gcloud run services update my-saas \
  --add-cloudsql-instances PROJECT:REGION:INSTANCE \
  --set-env-vars DATABASE_URL=postgres://...

Setting --min-instances 1 removes cold start at the cost of one always-on instance. Still usually cheaper than an always-on instance on other PaaS.

10. AWS App Runner / ECS Fargate — The AWS Exit

For teams that already have everything inside AWS, adding another PaaS feels like extra cost. App Runner and ECS Fargate are that team's PaaS exit.

App Runner. Push a container or a GitHub repo, get auto build · deploy. Similar to Cloud Run but always-on — does not scale to zero. Pricing: vCPU per minute $0.064, Memory GB per minute $0.007. A $5k/month SaaS bill usually lands at $80–$200.

Where App Runner sits. Integrates smoothly inside the AWS console with other AWS services — RDS, ElastiCache, S3, SQS. There's real value if AWS is first-class to your team. But PaaS outside AWS — Render, Railway, Fly — does the same workload cheaper and easier.

ECS Fargate. Container as a Service. You define an ECS Task Definition and run it on Fargate. One level of abstraction below a PaaS — you write VPC, ALB, IAM, Task Role yourself. But the control is correspondingly large. Large teams often have their main workload on ECS Fargate or EKS, with App Runner and PaaS reserved for ancillary workloads.

Price comparison. The same 1 vCPU + 2GB memory always-on for a month: ECS Fargate around $36/month, App Runner $40–$50/month. Render Standard $25/month, Fly dedicated-cpu-1x $30/month. AWS is slightly more expensive but the integration value with other AWS services can close that gap.

11. Coolify · Dokku — "PaaS Pricing Is Insane, I'll Host It"

There's always a crowd that hates PaaS pricing. "Hetzner VPS gives 4 vCPU + 8GB memory for $5/month, why would the same spec cost $85 on Render?" That crowd's tools are Coolify and Dokku.

Coolify. Open-source self-hosted PaaS that appeared in 2022 and exploded around 2025. Install Coolify on your VPS — Hetzner, DigitalOcean, OVH — and get Heroku-like experience on top. GitHub integration, auto-deploy, domains, HTTPS — auto via Let's Encrypt — managed Postgres · Redis · MySQL · MongoDB, monitoring, all included.

The real Coolify price. Coolify itself is free (Pro $5/month is the price of cloud-hosted Coolify, an instance you don't manage). VPS cost — Hetzner CX31 (2 vCPU, 8GB) at $13/month — is all you pay. Run 10 apps on one VPS and that's $1.3 per app. 1/20th the Render price.

Coolify's traps. First, you operate it. OS updates, security patches, backups, monitoring — all yours. Second, HA is weak. Everything on one VPS means when the VPS dies, every app dies. Coolify's cluster — multi-node — feature is beta. Third, the learning curve sneaks up. Expecting PaaS simplicity makes the first two weeks rough.

Dokku. Open-source mini-Heroku alive since 2013. Simpler than Coolify, no GUI (community GUIs exist), CLI only. dokku apps:create my-app, git push dokku main — almost identical to Heroku's CLI. A solo developer installing Dokku on their own VPS and running 5 small apps is still a sensible 2026 choice.

When to pick Coolify / Dokku. Save money, want to learn ops, side projects where HA isn't absolute. Usually unsuitable for primary business SaaS — one outage's business impact dominates the VPS savings.

12. The Cost Matrix — A Real Bill for a $5k/mo SaaS

Below is an estimated monthly bill for the same workload — Next.js 14 app + Postgres (10GB, light workload) + Redis (256MB) + one background worker — on each PaaS. Traffic assumption: 1M page views per month, 30k daily requests.

PaaSWebWorkerPostgresRedisDisk/StorageBandwidthTotal
Vercel + Neon + Upstash$20 Pro + $50–$200 usage(external queue) $20+Neon $19+Upstash $10+separateincluded$120–$300
Netlify + Supabase$19 Pro + $30–$150 usage(external)Supabase $25+(Supabase)separateincluded$80–$250
Render$25 Standard$25 Standard$20 Standard$10 Starter$2.5 10GB$0 100GB free$82.5
Fly.io$10 Machine$10 Machine$15 Postgres MicroVM$5 Redis MicroVM$2.5 10GB$2 100GB$44.5
Railway$15 per-min$10 per-min$10 per-min$5 per-minincludedincluded$40–$60
Northflank$25$25$20$10$2.5included$82.5
Heroku$25 Standard-1X$25 Standard-1X$50 Standard-0$15 Premium(add-on)included$115
Cloud Run + Cloud SQL$5–$30 100ms$5–$20 100msCloud SQL $30Memorystore $50+GCS $1$10$100–$140
App Runner + RDS$50–$100$50–$100RDS $30ElastiCache $30S3 $1$10$170–$270
Coolify on Hetzner(all on one VPS)(included)(included)(included)(included)(included)$13 VPS
Dokku on Hetzner(all on one VPS)(included)(included)(included)(included)(included)$13 VPS

Reading. On price alone, Coolify · Dokku dominate. But that's a number that ignores your operational cost — time + risk. Managed PaaS at $80 is not expensive, it's insurance premium. Among managed PaaS, Railway and Fly.io are cheapest, Render next, Vercel · Heroku · App Runner most expensive.

Price is one axis. Without other axes — operational simplicity, workload fit, migration cost, team consensus — the decision goes wrong.

13. The Truth About Cold Starts

The phrase "cold start" still sits at the heart of PaaS debates in 2026. The truth is this.

Only scale-to-zero platforms have cold starts. Always-on PaaS — Render, Railway, Heroku, Northflank — have no cold start. They do have instance restart time, but it's shorter than a cold start.

Vercel · Netlify · Cloud Run · Fly Machines (auto_stop) have cold starts. Typical times:

  • Vercel Functions — small Node.js function 100–500ms, big SSR 1–3 seconds
  • Netlify Functions — similar
  • Cloud Run — 100ms–2 seconds, image size matters a lot
  • Fly Machines (auto_stop) — 250–500ms, Firecracker's strength
  • AWS Lambda — Node 100–500ms, Java/Python longer

Workloads where cold start hurts. Real-time chat, games, trading, payment processing. Anywhere a 2-second first-request latency translates to user loss.

Three fixes. (1) Min instances >= 1 — both Cloud Run and Fly Machines support it. One always-on instance handles the first request. (2) Provisioned Concurrency — AWS Lambda's feature. (3) Move to an always-on PaaS.

14. The Dusk and Revival of Persistent Disks

Between 2018–2022 the big PaaS trend was "persistent disks are an anti-pattern". Push every state to external — Postgres, Redis, S3 — and keep compute stateless. Vercel · Netlify pushed that direction to the extreme.

The 2023–2026 trend partly reversed. Workloads that need persistent disks reappeared.

  • SQLite + Litestream — the simplest data layer for a SaaS. SQLite and the app live inside one VM, and Litestream async-replicates to S3. Fly.io and Render support this pattern well.
  • Self-hosted vector DBs — pgvector, Qdrant, Weaviate need disks on your instance.
  • File-processing workflows — image transforms, video transcode, large temp file storage.
  • Local caches — disk caches when Redis isn't used.

Do you need persistent disks? Look at Render, Fly.io, Railway, Northflank, Coolify · Dokku. Vercel, Netlify, Cloud Run, App Runner drop out.

15. The Reality of Background Workers

Background workers are the hidden half of a SaaS. Sending emails, processing payment webhooks, video transcoding, report generation, scheduled data sync — workers do all of it. PaaS support for workers varies sharply.

First-class — Render, Railway, Fly.io, Northflank, Heroku, Coolify. A worker is an always-on process. Start worker.js, poll a queue or receive messages, done.

Partial — Cloud Run Jobs, App Runner. Cloud Run Jobs is an executable worker but not always-on — it runs when invoked and exits. A queue-polling worker feels awkward on Cloud Run.

Weak — Vercel, Netlify. Vercel Queues is in beta, but there is no always-on worker model. Attaching external worker infrastructure — Inngest, Trigger.dev, Defer, Hatchet — is the common workaround. That's the real cost amplifier on Vercel.

For worker-heavy SaaS — image/video processing, AI inference, ETL — Render · Fly · Railway is almost always a better fit than Vercel.

16. Multi-Region — The Reality for Global SaaS

If you want a global SaaS with under-50ms latency, multi-region is required. The reality of multi-region support:

Smoothest — Fly.io. fly scale count 1 --region nrt,sin,fra,iad in one line. Multi-region Postgres was once Fly's strong card (now collaborative with Supabase).

Auto edge — Vercel, Netlify. Edge Functions and static assets auto-deploy to global edges. But databases don't live at the edge — Neon, PlanetScale, Supabase provide multi-region read replicas.

Region pick — Render, Railway, Northflank, Heroku. Deploy a service to one region; same service across multiple regions is a recent feature or beta. Not the first pick for global SaaS.

Auto global — Cloud Run. Pass multiple --region flags and the same service runs in multiple regions, but you wire up Load Balancer and Cloud Run multi-region config yourself.

If global multi-region is a hard requirement: Fly.io has the least friction, Cloud Run next, Vercel + a global DB after that.

17. The Decision Framework — Which PaaS Should You Pick

A simple decision tree for PaaS choice:

Starting point: what kind of app is it?

  1. Next.js · React Router · SvelteKit centric SSG/SSR + light API → Vercel (or Netlify). Other options are similar price or higher, and Vercel's integration value is large.
  2. Monolith — Web + worker + DB + Redis in one box → Render (or Railway). Heroku-like experience, delivered best.
  3. Global users, multi-region required → Fly.io. Least friction.
  4. Team already inside AWS → App Runner or ECS Fargate. AWS exit.
  5. Your own cloud / data sovereignty → Northflank.
  6. Extreme cost saving, solo with ops learning time → Coolify on Hetzner or Dokku.
  7. Already on GCP → Cloud Run + Cloud SQL.
  8. Salesforce integration → Heroku.

By team size:

  • Solo / side project — Vercel (Hobby) · Fly · Railway · Coolify
  • 2–5 small team — Vercel Pro · Render · Railway · Fly
  • 5–20 serious SaaS — Render · Railway · Northflank · Fly
  • 20+ / compliance — Northflank · Heroku · App Runner · Cloud Run

By learning curve (shortest first):

Vercel > Railway > Render > Heroku > Netlify > Fly > Cloud Run > Coolify > Northflank > App Runner > ECS Fargate.

18. Anti-Patterns Collection

Common patterns that wreck a PaaS choice:

1. Deciding on price alone. Coolify on a VPS at $13/month looks great, until your business SaaS sits there and one outage stops business. The $80 for managed PaaS isn't expensive — it's insurance premium.

2. Assuming "Vercel does it all". It's good at Next.js, not at every workload. Always-on workers, big monoliths, WebSocket-centric apps live better outside Vercel.

3. Starting on the PaaS's managed DB. Vercel Postgres, Render Postgres, Railway Postgres are easy to start but costly to migrate. Start with an independent managed DB — Neon, Supabase, PlanetScale — and you can swap PaaS later.

4. Adopting multi-region too early. Users are all on one continent and you went multi-region anyway. Single region + CDN is enough for many cases.

5. Running production on the free tier. Free tier cold start, sleep, and small resources damage user experience. Start production on paid.

6. Ignoring cold start. Go into Vercel · Cloud Run unaware and the first request taking 1–3 seconds bleeds users. Use min instances >= 1, or move to an always-on PaaS.

7. Assuming the PaaS handles all backups and monitoring. Render · Railway's automatic backup only retains a fixed window. Without your own additional backup, recovery during an incident fails.

8. "PaaS pricing is insane" then jumping to Kubernetes. The PaaS $200/month you hated becomes EKS's $73/month control plane + node cost + ops time (= 5 hours/week) and ends up more expensive. If PaaS pricing bugs you, first move within the same PaaS category to a cheaper option — Railway, Fly — before going to K8s.

Epilogue — Look at the Workload, Not the Tool

The trap of PaaS comparison writing is tool-first thinking. The question is not "Vercel vs Render" but "what fits my workload". The same SaaS can have different answers depending on user distribution, traffic pattern, worker load, data size, and compliance needs.

The 2026 landscape in one line: Next.js = Vercel, monolith = Render, global = Fly, per-minute billing = Railway, serious multi-cloud = Northflank, GCP = Cloud Run, AWS = App Runner, self-host = Coolify. Know these eight and a new project's PaaS decision typically takes 5 minutes.

PaaS Choice Checklist

  • Is my app a scale-to-zero workload? (Is cold start acceptable?)
  • Do I need persistent disks?
  • Do I need always-on workers? Are workers heavy?
  • Do I have global users? Is sub-50ms latency required?
  • Will I take managed Postgres / Redis inside the PaaS or split it out (Neon / Supabase / Upstash)?
  • Do I need compliance — HIPAA, PCI, GDPR, data sovereignty?
  • What is the team size and operational availability?
  • Have I calculated the cost of leaving — migration to another PaaS — in advance?
  • How does my bill change when traffic grows 10x?
  • Are preview environments, rollback, backups, and logs sufficient?

Next Article Teaser

The next article will compare the managed databases that sit on top of a PaaS — Neon · Supabase · PlanetScale · Turso · Cloudflare D1 · CockroachDB Serverless with the same depth. Half of a PaaS decision is a DB decision — separating that out frees the PaaS decision.

References