DEV Community: Parag Agrawal

Docker for Web Developers - The Only Guide You Actually Need (2026)

Parag Agrawal — Thu, 23 Apr 2026 07:58:17 +0000

If you've ever said "it works on my machine," Docker is the fix.

If you've ever spent hours debugging why your staging server behaves differently from your laptop, Docker is the fix.

If you've ever deployed to a PaaS like Vercel or Railway and wondered "what's actually happening under the hood". Docker is what's happening.

Yet the vast majority of Docker tutorials are written by and for DevOps engineers. They dive into container orchestration, overlay networks, and volume drivers before you've even containerized a "Hello World." That's backwards.

This guide is different. It's written for web developers, for the people building Next.js apps, Express APIs, Django backends, and Flask services. We'll cover exactly what you need to know, skip what you don't, and build up to production-ready skills in a single post.

By the end, you'll be able to:

✅ Containerize any web application
✅ Write efficient, cache-optimized Dockerfiles
✅ Use Docker Compose for local development with databases
✅ Apply production best practices (security, size, speed)
✅ Push images to a registry and deploy anywhere

Let's go.

Part 1: The Mental Model (2 Minutes)

Before touching any commands, let's build the right mental model.

What Docker Actually Does

Docker packages your application, its dependencies, its runtime, and its configuration into a single, portable unit called a container. That container runs identically everywhere may it be your laptop, your coworker's laptop, CI/CD, staging, production.

Think of it like this:

Without Docker	With Docker
"Install Node 20, then npm install, then set these env vars, then..."	"Run `docker run my-app`"
"It works on my machine"	"It works on every machine"
Different OS, different dependencies per environment	Same environment everywhere
"We need to match the production Node version"	Node version is locked in the Dockerfile

The Four Core Concepts

Dockerfile : A recipe (text file) that describes how to build your container image. Like a package.json for your entire environment.
Image : The built result of a Dockerfile. A read-only snapshot containing your code, dependencies, runtime, and OS. Like a .zip of your entire application stack.
Container : A running instance of an image. You can run multiple containers from the same image. Like processes spawned from the same binary.
Registry : A place to store and share images. Docker Hub is the public one. Amazon ECR is AWS's private one. Like npm for container images.

The flow: You write a Dockerfile → build it into an Image → run the image as a Container → push the image to a Registry for deployment.

Part 2: Your First Dockerfile (5 Minutes)

Let's containerize a real Node.js web application in under 5 minutes.

The Application

Here's a minimal Express API. Create a project folder with these files:

package.json

{
  "name": "my-web-app",
  "version": "1.0.0",
  "scripts": {
    "start": "node server.js",
    "dev": "node --watch server.js"
  },
  "dependencies": {
    "express": "^4.21.0"
  }
}

server.js

const express = require('express');
const app = express();
const PORT = process.env.PORT || 3000;

app.get('/', (req, res) => {
  res.json({
    message: 'Hello from Docker! 🐳',
    environment: process.env.NODE_ENV || 'development',
    timestamp: new Date().toISOString()
  });
});

app.get('/health', (req, res) => {
  res.status(200).json({ status: 'healthy' });
});

app.listen(PORT, () => {
  console.log(`Server running on port ${PORT}`);
});

The Dockerfile

Create a file called Dockerfile (no extension) in your project root:

# 1. Start from the official Node.js 20 Alpine image
FROM node:20-alpine

# 2. Set the working directory inside the container
WORKDIR /app

# 3. Copy dependency files first (for cache optimization)
COPY package*.json ./

# 4. Install dependencies
RUN npm ci --only=production

# 5. Copy everything else
COPY . .

# 6. Tell Docker which port your app uses
EXPOSE 3000

# 7. Define the command to run your app
CMD ["node", "server.js"]

That's it. Seven lines. Let's break down what each line does:

Line	What It Does	Why
`FROM node:20-alpine`	Uses Node.js 20 on Alpine Linux as the base	Alpine is ~180MB vs ~1.1GB for the default image
`WORKDIR /app`	Creates `/app` and sets it as the working directory	Keeps things organized; avoids polluting the root
`COPY package*.json ./`	Copies `package.json` and `package-lock.json`	Copied separately for layer caching (explained below)
`RUN npm ci --only=production`	Installs exact versions from lockfile, prod-only	`npm ci` is faster and more reliable than `npm install`
`COPY . .`	Copies the rest of your application code	Done after `npm ci` so code changes don't re-trigger install
`EXPOSE 3000`	Documents the port (doesn't actually open it)	Informational; required by some platforms for auto-detection
`CMD ["node", "server.js"]`	Defines the default command when the container starts	Use exec form (JSON array) for proper signal handling

Build It

# Build the image and tag it as "my-web-app"
docker build -t my-web-app .

# Output:
# [+] Building 12.3s (10/10) FINISHED
# => [1/5] FROM node:20-alpine
# => [2/5] WORKDIR /app
# => [3/5] COPY package*.json ./
# => [4/5] RUN npm ci --only=production
# => [5/5] COPY . .
# => naming to docker.io/library/my-web-app

Run It

# Run the container
docker run -p 3000:3000 my-web-app

# -p 3000:3000 = map port 3000 on your machine to port 3000 in the container

Open http://localhost:3000 - your app is running inside a container. 🎉

Essential Run Variants

# Run in the background (detached mode)
docker run -d -p 3000:3000 --name my-app my-web-app

# Run with environment variables
docker run -d -p 3000:3000 -e NODE_ENV=production -e API_KEY=secret my-web-app

# Run with a volume (live code changes, for development)
docker run -p 3000:3000 -v $(pwd):/app my-web-app npm run dev

# See running containers
docker ps

# View logs
docker logs my-app

# Stop and remove
docker stop my-app && docker rm my-app

Part 3: The .dockerignore File (Don't Skip This)

Just like .gitignore prevents files from entering your repo, .dockerignore prevents files from entering your image. Without it, COPY . . copies everything including node_modules, .git, test files, and local secrets.

.dockerignore

node_modules
npm-debug.log
.git
.gitignore
.env
.env.*
Dockerfile
docker-compose.yml
.dockerignore
README.md
.vscode
.idea
coverage
tests
__tests__
*.test.js
*.spec.js

Why this matters:

With .dockerignore	Without .dockerignore
Image: ~180 MB	Image: ~400+ MB
Build time: ~12 sec	Build time: ~30+ sec
No secrets in image ✅	`.env` leaked into image ❌
Faster CI/CD deploys	Slower deploys

⚠️ Critical: Never include .env files in your Docker image. Use environment variables passed at runtime (docker run -e) or Docker secrets instead.

Part 4: Understanding Layer Caching (The Key to Fast Builds)

Docker builds images in layers. Each instruction in your Dockerfile creates a layer. Docker caches these layers and reuses them when nothing has changed.

Why the Order Matters

Look at our Dockerfile again:

COPY package*.json ./     # Layer 3: Changes rarely
RUN npm ci                # Layer 4: Changes rarely (cached if package.json unchanged)
COPY . .                  # Layer 5: Changes on every code edit

If we had done it the "obvious" way:

# ❌ BAD: Every code change re-runs npm install
COPY . .
RUN npm ci

Every time you change a single line of code, Docker would re-install all dependencies from scratch. By copying package.json first, Docker caches the npm ci layer and only re-runs it when your dependencies change.

The golden rule: Order Dockerfile instructions from least-frequently-changed to most-frequently-changed.

Build Time Comparison

Scenario	With Cache Optimization	Without
First build	45 seconds	45 seconds
Code change (no dependency change)	3 seconds ✅	45 seconds ❌
Dependency change	40 seconds	45 seconds

Over 50 builds/day (common in active development), cache optimization saves ~35 minutes daily.

Part 5: Dockerfiles for Every Stack

Node.js / Express / Next.js

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]

Python / Flask / Django

FROM python:3.12-slim

WORKDIR /app

# Install dependencies first for caching
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .

EXPOSE 5000

# Flask
CMD ["python", "-m", "flask", "run", "--host=0.0.0.0"]

# Django (use this instead):
# CMD ["gunicorn", "myproject.wsgi:application", "--bind", "0.0.0.0:8000"]

Go

# Build stage
FROM golang:1.22-alpine AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build -o main .

# Run stage
FROM alpine:3.19
WORKDIR /app
COPY --from=builder /app/main .
EXPOSE 8080
CMD ["./main"]

Note: The Go example uses a multi-stage build which we'll cover in detail in the next section. This is the pattern for compiled languages.

Part 6: Multi-Stage Builds (Smaller, Faster, Safer)

Multi-stage builds let you use one Dockerfile with multiple FROM instructions. The first stage builds your app; the final stage contains only the production output.

Why? Your build tools (TypeScript compiler, webpack, dev dependencies) don't need to be in your production image. Multi-stage builds strip them out automatically.

Example: Next.js Multi-Stage Build

# Stage 1: Install dependencies
FROM node:20-alpine AS deps
WORKDIR /app
COPY package*.json ./
RUN npm ci

# Stage 2: Build the application
FROM node:20-alpine AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN npm run build

# Stage 3: Production image (only compiled output)
FROM node:20-alpine AS runner
WORKDIR /app

# Create non-root user
RUN addgroup --system --gid 1001 nodejs
RUN adduser --system --uid 1001 nextjs

# Copy only what's needed
COPY --from=builder /app/public ./public
COPY --from=builder /app/.next/standalone ./
COPY --from=builder /app/.next/static ./.next/static

USER nextjs
EXPOSE 3000
CMD ["node", "server.js"]

Size Impact

Approach	Image Size	Contents
Single stage	~800 MB	Source + node_modules + devDeps + build output
Multi-stage	~180 MB	Alpine + production node_modules + build output
Multi-stage + standalone	~120 MB	Alpine + minimal Node.js + compiled output only

The multi-stage version is 6x smaller which means faster pulls, faster deploys, faster auto-scaling, and cheaper ECR storage.

Part 7: Choosing a Base Image

Your choice of base image is the single biggest factor in final image size.

Node.js Base Images

Image	Size	Use Case	Trade-offs
`node:20`	~1,100 MB	Never use for production	Full Debian; massive; includes compilers
`node:20-slim`	~250 MB	Good default for production	Debian-slim; most native modules work
`node:20-bookworm-slim`	~220 MB	Explicit Debian version	Reproducible; predictable
`node:20-alpine`	~180 MB	Best for most web apps	Small; uses musl (rare compat issues with native modules)
`gcr.io/distroless/nodejs20`	~130 MB	Ultra-minimal production	No shell, no package manager; hard to debug

Python Base Images

Image	Size	Use Case
`python:3.12`	~1,000 MB	Development only
`python:3.12-slim`	~150 MB	Best default for production
`python:3.12-alpine`	~60 MB	Smallest, but pip compilations can be slow

Our Recommendation

Use -alpine for most web applications. It's the best balance of size, security, and compatibility. If you hit issues with native modules (like bcrypt or sharp), switch to -slim.

Part 8: Docker Compose (Local Development with Databases)

Docker Compose lets you define and run multi-container applications. Instead of manually running your app, database, and cache as separate containers, you define them in a single file.

Example: Node.js + PostgreSQL + Redis

docker-compose.yml (or compose.yml both work)

services:
  app:
    build: .
    ports:
      - "3000:3000"
    environment:
      - NODE_ENV=development
      - DATABASE_URL=postgresql://postgres:postgres@db:5432/myapp
      - REDIS_URL=redis://cache:6379
    volumes:
      - .:/app           # Live code reload
      - /app/node_modules # Don't override container's node_modules
    depends_on:
      db:
        condition: service_healthy
      cache:
        condition: service_started
    command: npm run dev

  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
      POSTGRES_DB: myapp
    ports:
      - "5432:5432"
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 5s
      retries: 5

  cache:
    image: redis:7-alpine
    ports:
      - "6379:6379"

volumes:
  pgdata:

Run Everything

# Start all services
docker compose up

# Start in background
docker compose up -d

# View logs
docker compose logs -f app

# Stop everything
docker compose down

# Stop and remove data (fresh database)
docker compose down -v

What This Gives You

One command to spin up your entire development stack
Consistent database version across all team members
No local PostgreSQL/Redis installation needed
Data persistence via Docker volumes (survives docker compose down)
Automatic service discovery : your app reaches Postgres at db:5432 and Redis at cache:6379
Health checks : the app waits for the database to be ready before starting

Python Equivalent

services:
  app:
    build: .
    ports:
      - "8000:8000"
    environment:
      - DJANGO_SETTINGS_MODULE=myproject.settings
      - DATABASE_URL=postgresql://postgres:postgres@db:5432/myapp
    volumes:
      - .:/app
    depends_on:
      db:
        condition: service_healthy
    command: python manage.py runserver 0.0.0.0:8000

  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
      POSTGRES_DB: myapp
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 5s
      retries: 5

volumes:
  pgdata:

Part 9: Docker Compose Watch (Hot Reload in 2026)

Docker Compose Watch (docker compose watch) is the modern way to develop with Docker. Instead of brittle bind mounts, Compose Watch syncs file changes into the container automatically and can trigger rebuilds when needed.

compose.yml with Watch enabled:

services:
  app:
    build: .
    ports:
      - "3000:3000"
    develop:
      watch:
        # Sync code changes instantly (no rebuild)
        - action: sync
          path: ./src
          target: /app/src

        # Rebuild when dependencies change
        - action: rebuild
          path: ./package.json

        # Sync and restart when config changes
        - action: sync+restart
          path: ./config
          target: /app/config

# Start with watch mode
docker compose watch

Why Watch is better than bind mounts:

Feature	Bind Mounts (`volumes`)	Compose Watch
macOS performance	Slow (file system translation)	Fast (direct sync)
Selective sync	No (mounts entire directory)	Yes (specify paths)
Auto rebuild on deps change	No	Yes (`action: rebuild`)
Works with Docker Build	No (bypasses build)	Yes (respects Dockerfile)

Part 10: Production Best Practices Checklist

Before you deploy your Docker image to production (whether on ECS, Railway, or anywhere else), apply these practices:

✅ Security

# 1. Run as non-root user
RUN addgroup --system --gid 1001 appuser && \
    adduser --system --uid 1001 appuser
USER appuser

# 2. Don't store secrets in the image
# ❌ BAD
ENV API_KEY=sk-secret-123
# ✅ GOOD - pass at runtime
# docker run -e API_KEY=sk-secret-123 my-app

# 3. Use specific image tags (not :latest)
# ❌ BAD
FROM node:latest
# ✅ GOOD
FROM node:20.11.1-alpine3.19

# 4. Add a health check
HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \
  CMD wget --no-verbose --tries=1 --spider http://localhost:3000/health || exit 1

✅ Size Optimization

# 1. Use multi-stage builds (covered above)

# 2. Combine RUN commands to reduce layers
# ❌ BAD: 3 layers
RUN apt-get update
RUN apt-get install -y curl
RUN rm -rf /var/lib/apt/lists/*
# ✅ GOOD: 1 layer
RUN apt-get update && \
    apt-get install -y --no-install-recommends curl && \
    rm -rf /var/lib/apt/lists/*

# 3. Use --no-cache-dir for pip
RUN pip install --no-cache-dir -r requirements.txt

# 4. Use npm ci instead of npm install
RUN npm ci --only=production

✅ Performance

# 1. Use .dockerignore (covered above)

# 2. Order layers from stable to volatile (covered above)

# 3. Pin versions for reproducibility
FROM node:20.11.1-alpine3.19
# NOT: FROM node:20-alpine (could change underneath you)

✅ The Complete Production Dockerfile (Node.js)

Here's a production-ready Dockerfile that combines everything we've covered:

# syntax=docker/dockerfile:1

# ----- Stage 1: Dependencies -----
FROM node:20.11.1-alpine3.19 AS deps
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --only=production && npm cache clean --force

# ----- Stage 2: Build -----
FROM node:20.11.1-alpine3.19 AS builder
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npm run build

# ----- Stage 3: Production -----
FROM node:20.11.1-alpine3.19 AS runner
WORKDIR /app

# Non-root user
RUN addgroup --system --gid 1001 nodejs && \
    adduser --system --uid 1001 appuser

# Copy production node_modules + built files
COPY --from=deps --chown=appuser:nodejs /app/node_modules ./node_modules
COPY --from=builder --chown=appuser:nodejs /app/dist ./dist
COPY --from=builder --chown=appuser:nodejs /app/package.json ./

USER appuser
EXPOSE 3000

HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \
  CMD wget --no-verbose --tries=1 --spider http://localhost:3000/health || exit 1

CMD ["node", "dist/server.js"]

Part 11: Essential Docker Commands Cheat Sheet

# === BUILD ===
docker build -t my-app .                    # Build an image
docker build -t my-app:v1.2.3 .             # Build with a specific tag
docker build --no-cache -t my-app .         # Build without cache
docker build --platform linux/amd64 -t my-app .  # Build for x86 (on Apple Silicon)

# === RUN ===
docker run -p 3000:3000 my-app              # Run (foreground)
docker run -d -p 3000:3000 --name app my-app  # Run (background)
docker run -e NODE_ENV=prod my-app          # Run with env var
docker run --rm my-app                      # Auto-remove when stopped
docker exec -it app sh                      # Shell into running container

# === INSPECT ===
docker ps                                   # List running containers
docker ps -a                                # List all containers
docker images                               # List images
docker logs app                             # View logs
docker logs -f app                          # Follow logs
docker stats                                # Resource usage (CPU/memory)

# === CLEANUP ===
docker stop app                             # Stop a container
docker rm app                               # Remove a container
docker rmi my-app                           # Remove an image
docker system prune                         # Remove all unused data
docker system prune -a                      # Remove everything unused (⚠️ aggressive)

# === COMPOSE ===
docker compose up                           # Start all services
docker compose up -d                        # Start in background
docker compose down                         # Stop and remove
docker compose down -v                      # Stop + remove volumes (fresh DB)
docker compose logs -f app                  # Follow app logs
docker compose exec app sh                  # Shell into a service
docker compose build                        # Rebuild images
docker compose watch                        # Start with file watching

Part 12: Pushing to a Registry (Deploy Anywhere)

Once your image is built, you need to push it to a registry so deployment platforms can pull it.

Push to Docker Hub (Public)

# Login
docker login

# Tag
docker tag my-app yourusername/my-app:latest

# Push
docker push yourusername/my-app:latest

Push to Amazon ECR (Private - What TurboDeploy Uses)

# Authenticate with ECR
aws ecr get-login-password --region us-east-1 | \
  docker login --username AWS --password-stdin \
  <your-account-id>.dkr.ecr.us-east-1.amazonaws.com

# Create repository (first time only)
aws ecr create-repository --repository-name my-app

# Tag
docker tag my-app:latest \
  <your-account-id>.dkr.ecr.us-east-1.amazonaws.com/my-app:latest

# Push
docker push \
  <your-account-id>.dkr.ecr.us-east-1.amazonaws.com/my-app:latest

Once your image is in ECR, you can deploy it to ECS Express Mode in about 5 minutes.

Where Docker Fits in the TurboDeploy World

Every container deployment platform like Vercel, Railway, Render, ECS and TurboDeploy runs Docker containers under the hood. Knowing Docker means:

You understand what your PaaS is doing : no more black box
You can switch platforms without rewriting : your Dockerfile works everywhere
You can optimize costs : smaller images = faster deploys = lower bills
You're ready for AWS : ECS Fargate runs Docker containers natively

With TurboDeploy, you write a Dockerfile, push to Git and we handle the rest. Building the image, pushing to ECR, deploying to ECS, provisioning the ALB and setting up monitoring. All in your AWS account, at AWS pricing.

→ Already comfortable with Docker? Check out How to Deploy a Docker Container on AWS ECS Fargate our step-by-step deployment guide.

TL;DR

Concept	What You Need to Know
Dockerfile	Recipe for building your image. Order matters for caching.
Images	Use `-alpine` or `-slim`. Never `:latest` in production.
.dockerignore	Always create one. Never ship `node_modules` or `.env`.
Layer caching	Copy dependencies before code. Saves 80%+ build time.
Multi-stage builds	Use for compiled/built apps. Reduces image size by 4–6x.
Docker Compose	Use for local dev with databases. One command, full stack.
Compose Watch	Replace bind mounts for development. Faster on macOS.
Security	Non-root user, specific tags, no secrets in image, health checks.
Registries	Docker Hub (public), ECR (private). Push before deploy.

Skip the Docker learning curve entirely? TurboDeploy detects your framework, generates an optimized Dockerfile,and deploys to your AWS account with no Docker knowledge required. But if you want to understand the engine under the hood, this guide has you covered.

Join the waitlist →

The "Platform Tax" Is Real - Why Developers Are Moving Back to AWS (2026)

Parag Agrawal — Tue, 21 Apr 2026 12:56:25 +0000

There's a phrase we keep hearing in founder Slack groups, Reddit threads, and Twitter conversations about infrastructure costs. It comes up when someone posts their monthly Vercel bill, or when a seed-stage startup realizes they're spending $400/month on Railway for a workload that would cost $120 on AWS.

The phrase is: "The Platform Tax."

It's not an official term. No pricing page calls it that. But every developer who's outgrown a PaaS platform knows exactly what it means — the premium you pay, on top of actual infrastructure costs, for the convenience of not dealing with AWS directly.

And in 2026, a growing number of developers are deciding that tax isn't worth it anymore.

What Exactly Is the "Platform Tax"?

The platform tax is the delta between what you pay a PaaS provider and what the same workload costs on the underlying cloud infrastructure.

Let's make it concrete. In our real-world pricing breakdown, we compared identical workloads across Vercel, Railway, Render, and AWS ECS Fargate:

Workload (Growth Tier: 3 services, 1 vCPU each)	Monthly Cost	Platform Tax
AWS ECS Fargate (direct)	~$125	$0 (baseline)
Railway Pro	~$140	~$15/mo (12%)
Render Professional	~$165	~$40/mo (32%)
Vercel Pro	~$175	~$50/mo (40%)

At scale (8 services, 1.5 vCPU each):

Workload (Scale Tier)	Monthly Cost	Platform Tax
AWS ECS Fargate (direct)	~$390	$0 (baseline)
Railway Pro	~$430	~$40/mo (10%)
Render Organization	~$480	~$90/mo (23%)
Vercel Pro	~$620	~$230/mo (59%)

The platform tax is real. It's measurable. And it compounds over time.

Over 12 months at the Scale tier, the difference between Vercel and direct AWS is ~$2,760 — enough to fund a contractor, extend runway, or invest in product features. And that's before AWS optimization strategies like Savings Plans or Graviton ARM processors, which can widen the gap to 40–65%.

This Isn't Just About Money

Here's the thing people miss when they frame PaaS-vs-AWS as purely a cost decision. The platform tax has three components:

1. The Financial Tax (Direct Markup)

This is the straightforward part — you're paying more per vCPU, per GB of memory, and per GB of bandwidth than the underlying cloud charges. We covered this in detail in this post.

2. The Lock-In Tax (Switching Costs)

Every month you stay on a PaaS platform, your switching costs increase:

Your deployment configs are in vercel.json, railway.toml, or render.yaml — none of which work anywhere else
Your team builds muscle memory around the platform's CLI and dashboard
Your environment variables, secrets, and configurations live in their UI
If you're using their managed databases, migration means downtime and risk

The lock-in tax isn't on your monthly bill, but it's on your balance sheet. It's the engineering time you'll eventually spend migrating — and the longer you wait, the more expensive it gets.

Estimated lock-in migration cost: 1–4 weeks of senior engineer time = $5,000–$20,000+ in opportunity cost, depending on complexity.

3. The Ceiling Tax (Capability Limits)

PaaS platforms are designed for the 80% use case. They work brilliantly for the first 80% of your journey. But eventually, you run into limits:

Need SOC 2 compliance? Enterprise tier, custom pricing
Need SAML SSO? Enterprise tier
Need HIPAA compliance? "Contact us"
Need multi-region deployment? Not available on most PaaS
Need VPC peering for a managed database? Not supported or limited
Need custom networking for security? You can't customize what you don't own

Every time you hit one of these ceilings, you face a choice: pay the enterprise upgrade tax, or migrate to infrastructure you control. And by then, the lock-in tax makes migration painful.

The Timeline: How We Got Here

The developer community's relationship with PaaS has evolved significantly over the past six years.

2020–2021: The Golden Age of PaaS

Heroku's free tier was running half the startup ecosystem. Vercel launched and made Next.js deployment magic. Railway emerged as the hip Heroku alternative. Render promised to be "the modern Heroku."

Developer experience was the #1 priority. Nobody cared about costs because usage was small and VC money was flowing.

2022: The Wake-Up Call

Two things happened simultaneously:

Heroku killed its free tier (November 2022). Millions of developers were suddenly paying for something that used to be free. Many migrated to Railway and Render.
Interest rates rose. VC funding tightened. Startups started caring about unit economics and burn rate for the first time in years.

Developers who moved from Heroku to Railway/Render solved the immediate problem but didn't question the underlying model: someone else owns your infrastructure.

2023–2024: The Repatriation Wave Begins

The biggest signal came from DHH and 37signals (makers of Basecamp and HEY):

They famously left the cloud entirely in 2023–2024
They purchased their own servers and moved off AWS
They reported saving over $1 million per year in cloud costs
DHH wrote extensively about "cloud repatriation" — the trend of companies bringing workloads back from managed services to owned infrastructure

Was their approach right for everyone? No — most startups don't need to buy physical servers. But the sentiment it unleashed was massive. Developers started asking: "Wait, how much am I actually paying in platform markup?"

2025: The Self-Hosted PaaS Boom

Open-source self-hosted PaaS tools exploded:

Coolify — self-hosted Vercel/Netlify/Heroku alternative (26K+ GitHub stars)
Dokku — the original "mini-Heroku" (29K+ GitHub stars)
Kamal — DHH's own Docker deployment tool (11K+ GitHub stars)
CapRover — another self-hosted PaaS option

The message was clear: developers wanted PaaS simplicity but didn't want to pay the platform tax. They'd rather run deployment tools on their own servers.

2026: AWS Responds

AWS caught the signal:

ECS Express Mode launched — making ECS nearly as simple as App Runner
App Runner was sunset — AWS consolidated into one simplified path
Docker's tooling matured — multi-stage builds, compose watch, buildx
GitHub Actions reached maturity — free CI/CD pipelines removed another PaaS advantage

The gap between "PaaS simple" and "AWS simple" is the narrowest it's ever been. And the cost gap remains enormous.

The Five Signs You've Outgrown Your PaaS

How do you know when the platform tax is no longer worth paying? Here are the signals:

1. Your Monthly Bill Has a Significant Platform Component

If your PaaS bill is 30%+ higher than equivalent AWS pricing, the convenience premium is getting expensive. At $50+/month in platform tax, that's $600/year you could put toward product.

2. You're Working Around Platform Limitations

If you find yourself:

Splitting one service into two because of memory limits
Caching aggressively to avoid bandwidth overages
Avoiding certain architectures because your PaaS doesn't support them
Running some services on the PaaS and others on AWS already

...you've outgrown the platform.

3. Security or Compliance Comes Calling

The moment a customer asks "Where is our data hosted?" or "Can we see your SOC 2 report?", PaaS platforms become a liability. You can't answer those questions definitively when you don't own the infrastructure.

4. Your Team Has Grown Beyond 3 Engineers

Per-seat pricing ($20–29/user/month) becomes a real line item. With 5 developers, you're paying $100–145/month just for the right to deploy — before any compute costs.

5. You're Thinking About Fundraising

Investors increasingly ask about infrastructure costs and margins. "We're paying 40% more than we need to because we're on [PaaS]" is not a great answer. "We run on AWS in our own account at direct rates" signals maturity.

The Infrastructure Ownership Spectrum

The real question isn't "PaaS vs AWS." It's where you want to sit on the ownership spectrum:

Approach	Control	Complexity	Cost	Best For
Full PaaS (Vercel, Railway, Render)	❌ Low	✅ Low	❌ Highest	MVPs, side projects, tiny teams
Bring Your Own Cloud (TurboDeploy, Coolify)	✅ High	✅ Low	✅ Low (AWS direct)	Growth-stage startups, cost-conscious teams
Full DIY AWS (Terraform, CDK, manual ECS)	✅ Highest	❌ Highest	✅ Lowest (with expertise)	Mature teams with dedicated DevOps

The gap in the middle — "I want to own my infrastructure but I don't want to learn 47 AWS services" — is exactly where the industry is moving. And it's exactly where we're building TurboDeploy.

What the Community Is Saying

We're not the only ones noticing this trend. Across developer communities, the sentiment is shifting:

On Reddit r/devops and r/aws:

"Started on Railway, loved it, then realized I was paying 3x what the same Fargate setup costs. Migrated in a weekend."

"Vercel is great for frontend. For backend? Just use ECS. The DX gap isn't big enough anymore to justify the cost."

"The move from 'I don't want to deal with AWS' to 'actually, AWS isn't that bad' happened faster than I expected."

On Twitter/X (paraphrased, common sentiment):

"Hot take: managed PaaS is the new 'premium IDE license' — nice to have when you're not paying, painful when you scale."

"Every dollar I spend on Render that I don't need to is a dollar I can't spend on marketing."

On HackerNews (a recurring theme):

"The PaaS value proposition was always 'pay us more so you don't have to learn AWS.' But now ECS is simple enough that the premium isn't justified."

The pattern is consistent: developers who start on PaaS eventually leave PaaS. The only question is when — and how painful the migration will be.

The Counterargument (And Why It's Partially Valid)

Let's be honest about the other side.

"Developer time is more expensive than PaaS markup"

This is true — at small scale. If you're a solo founder and your total infra cost is $50/month, the $20/month platform tax is genuinely worth it if it saves you 4 hours of AWS setup. Your time is more valuable.

The math stops working when:

The platform tax exceeds ~$100/month
You have team members paying per-seat fees
The time savings decrease (ECS Express Mode, GitHub Actions, etc. have closed the DX gap)

"PaaS platforms provide more than just compute"

True. They provide:

Preview environments
Rollback with one click
Built-in CI/CD
Domain management
Team access control

But these aren't unique to PaaS anymore. GitHub Actions provides CI/CD. ECS provides rollback. Route 53 handles domains. IAM handles access control. The feature gap has narrowed dramatically.

"Migration is risky"

Also true. Any migration carries risk. But the risk increases the longer you wait:

More services = more to migrate
More data = longer downtime
More team knowledge = harder to relearn
Longer lock-in = higher switching costs

If you're going to migrate eventually (and most scaling startups do), doing it earlier is cheaper.

The Third Path: Don't Choose

Here's our thesis at TurboDeploy: the "PaaS vs AWS" framing is a false dichotomy.

You shouldn't have to choose between:

Simple but expensive (PaaS) and
Cheap but painful (raw AWS)

The third path is simple AND cheap AND yours:

Deploy with a git push — no AWS console required ✅
Runs in YOUR AWS account — you own everything ✅
Pay AWS pricing — no platform markup ✅
Full access to underlying resources — no black box ✅
No vendor lock-in — your infra survives if TurboDeploy disappeared tomorrow ✅

This is what we're building. And based on the trend lines we've outlined in this post — the DHH repatriation wave, the self-hosted PaaS boom, ECS Express Mode, App Runner's sunset — we believe this "Bring Your Own Cloud" model is where the entire market is heading.

The platform tax had its era. That era is ending.

→ Read more about our approach: Why We're Building TurboDeploy

Action Items: What You Should Do Now

Whether or not you use TurboDeploy, here's what we'd recommend based on where you are:

🟢 If You're Happy on PaaS (< $50/mo total)

Stay. The platform tax at this scale is genuinely worth it. Focus on building product.

But: Know your numbers. Run the math from our pricing breakdown quarterly. Set a threshold (e.g., "when we hit $200/mo, we migrate") and stick to it.

🟡 If You're Feeling the Squeeze ($100–300/mo PaaS bill)

Start planning. You're in the zone where the platform tax is eating real money — $30–100/month — without proportional value.

Audit your bill. Break down compute, bandwidth, build minutes, per-seat costs
Calculate the AWS equivalent. Use our growth-tier calculator
Try ECS Express Mode on a non-critical service. See our complete guide
Set a migration date. Even tentatively — having a deadline prevents drift

🔴 If You're Paying > $300/mo in Platform Tax

Stop reading and start migrating. At $300+/month in platform tax, you're spending $3,600+/year on convenience that ECS Express Mode or TurboDeploy can replicate for free.

The longer you wait, the more expensive migration becomes. The code isn't getting simpler, the data isn't getting smaller, and the lock-in isn't loosening.

TL;DR

The Platform Tax...	Details
What it is	The markup PaaS platforms charge above actual cloud infrastructure costs
How much it costs	10–59% depending on platform and scale
Three components	Financial (direct markup) + Lock-in (switching costs) + Ceiling (capability limits)
Why it's growing	Per-seat pricing, bandwidth overages, enterprise feature gates
Why developers are leaving	DHH effect, self-hosted PaaS boom, ECS Express Mode, tighter startup budgets
The alternative	"Bring Your Own Cloud" — PaaS simplicity, AWS pricing, your infrastructure

The platform tax was an acceptable cost when AWS was impossibly complex. In 2026, that's no longer the case.

👉 Join the TurboDeploy waitlist → — Deploy to AWS without the AWS headache. Your code, your AWS, no platform tax.

AWS ECS Express Mode: The Complete Getting Started Guide (2026)

Parag Agrawal — Fri, 17 Apr 2026 09:24:29 +0000

In the last post, we broke the news: AWS App Runner is sunsetting. No new customers after April 30, 2026. If you were one of the developers who loved App Runner's simplicity, you probably felt a pang of dread. Where do you go now?

The answer is ECS Express Mode and after using it, we think it's actually better than App Runner ever was.

This guide walks you through deploying your first containerized web application with ECS Express Mode from scratch. By the end, you'll have a running service with an auto-provisioned load balancer, auto-scaling, HTTPS, and monitoring — all in under 10 minutes.

What Is ECS Express Mode?

ECS Express Mode is a new capability within Amazon ECS (Elastic Container Service) that dramatically simplifies container deployment. Think of it as the spiritual successor to AWS App Runner — but built directly into ECS, giving you both simplicity and the full power of the ECS ecosystem.

Here's what Express Mode does automatically when you deploy:

What It Provisions	What You'd Otherwise Need to Do
ECS Cluster	Create a cluster with Fargate capacity providers
ECS Service	Define service configuration, deployment strategy
Application Load Balancer	Create ALB, listener, target group, health check
Security Groups	Configure inbound/outbound rules for ALB and tasks
Auto-Scaling	Set up Application Auto Scaling targets and policies
CloudWatch Monitoring	Configure log groups, metrics, alarms
Networking	Set up VPC subnets, route tables, internet gateway

That's 6–8 AWS console pages reduced to a single form. This is not a wrapper with limited features — Express Mode creates real, standard ECS resources that you can inspect, modify, and extend at any time.

The Key Differentiator: Shared ALBs

One of the most impactful features is shared Application Load Balancers. In standard ECS, every service typically needs its own ALB — that's ~$16/month per service, just for the load balancer.

ECS Express Mode can share a single ALB across up to 25 services using path-based or host-based routing. For a startup running 5 services, that's a savings of ~$64/month just in ALB costs.

ECS Express Mode vs Standard ECS: When to Use What

Feature	Express Mode	Standard ECS
Setup time	5–10 minutes	30–60 minutes
ALB provisioning	Automatic (shared)	Manual (dedicated)
Security groups	Auto-configured	Manual configuration
Auto-scaling	Pre-configured policies	Manual setup
CloudWatch	Auto-enabled	Manual log groups/metrics
VPC networking	Uses defaults or existing	Full manual control
Customizability	Moderate (can modify after creation)	Full
Pricing	Same Fargate + ALB pricing	Same Fargate + ALB pricing
Best for	Most web services, APIs, backends	Custom networking, multi-AZ, advanced configs

Our recommendation: Start with Express Mode for everything. If you hit a limitation, you can always "eject" to standard ECS by modifying the underlying resources directly. You're not locked in.

Prerequisites

Before you start, make sure you have:

1. An AWS Account

If you don't have one, create a free account. New accounts get 12 months of free tier, which includes enough ECS/Fargate credits to run this tutorial at zero cost.

2. AWS CLI Installed (Optional, for CLI Path)

# macOS
brew install awscli

# Verify
aws --version
# aws-cli/2.x.x ...

3. Docker Installed (for Building Images)

# macOS
brew install --cask docker

# Verify
docker --version
# Docker version 27.x.x ...

4. A Container Image

You need a Docker image to deploy. You can either:

Use a public image for testing (we'll use public.ecr.aws/docker/library/nginx:latest)
Build your own from your app's Dockerfile

For this guide, we'll show both paths.

The Deployment Flow

Here's the complete path from code to running service:

Step 1: Prepare Your Container Image

Option A: Use a Public Image (Quickest)

Skip ahead to Step 2 and use public.ecr.aws/docker/library/nginx:latest as your image URI. This is the fastest way to test Express Mode.

Option B: Build and Push Your Own Image

Let's say you have a simple Node.js API. First, create a Dockerfile:

# Use official Node.js LTS image
FROM node:20-alpine

# Set working directory
WORKDIR /app

# Copy package files
COPY package*.json ./

# Install dependencies (production only)
RUN npm ci --only=production

# Copy application code
COPY . .

# Expose the port your app runs on
EXPOSE 3000

# Health check (Express Mode uses this)
HEALTHCHECK --interval=30s --timeout=3s \
  CMD wget --no-verbose --tries=1 --spider http://localhost:3000/health || exit 1

# Start the application
CMD ["node", "server.js"]

Now build and push to Amazon ECR:

# Set your variables
AWS_REGION=us-east-1
AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
REPO_NAME=my-web-app

# Create ECR repository (if it doesn't exist)
aws ecr create-repository \
  --repository-name $REPO_NAME \
  --region $AWS_REGION \
  --image-scanning-configuration scanOnPush=true

# Authenticate Docker with ECR
aws ecr get-login-password --region $AWS_REGION | \
  docker login --username AWS --password-stdin \
  $AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com

# Build the image
docker build -t $REPO_NAME .

# Tag the image
docker tag $REPO_NAME:latest \
  $AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/$REPO_NAME:latest

# Push to ECR
docker push \
  $AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/$REPO_NAME:latest

💡 Tip: If you're on an Apple Silicon Mac (M1/M2/M3), add --platform linux/amd64 to your docker build command to ensure compatibility with Fargate's x86 environment. Or use linux/arm64 and select ARM/Graviton in Express Mode for 20% cost savings.

Save the full image URI — you'll need it in the next step:

<your-account-id>.dkr.ecr.us-east-1.amazonaws.com/my-web-app:latest

Step 2: Open the ECS Console and Select Express Mode

Go to the Amazon ECS Console
In the left navigation panel, click Express mode
Click Create

You'll see a simplified form — much less intimidating than the standard ECS service creation page. This is by design.

Step 3: Configure Your Service

Fill in the Express Mode creation form:

Basic Configuration:

Field	Value	Notes
Service name	`my-web-app`	Lowercase, hyphens allowed
Container image URI	Your ECR URI or a public image	e.g., `public.ecr.aws/docker/library/nginx:latest`
Port	`3000` (or `80` for nginx)	The port your app listens on
CPU	`0.25 vCPU`	Start small; you can scale later
Memory	`0.5 GB`	Start with 512 MB for most web apps

Environment Variables (optional):

Click "Add environment variable" to add any your app needs:

NODE_ENV=production
DATABASE_URL=your-connection-string
API_KEY=your-key

⚠️ Security note: For sensitive values like database credentials and API keys, use AWS Secrets Manager or SSM Parameter Store instead of plain-text environment variables. Express Mode supports both through the "valueFrom" syntax.

Scaling Configuration:

Field	Value	Notes
Desired count	`1`	Start with 1 task for testing
Min tasks	`1`	Minimum for auto-scaling
Max tasks	`4`	Maximum for auto-scaling

Step 4: Create and Wait

Click Create. Express Mode will now:

✅ Create an ECS cluster (if one doesn't exist)
✅ Register a task definition with your image and configuration
✅ Provision (or reuse) an Application Load Balancer
✅ Create a target group and listener rules
✅ Configure security groups for both ALB and tasks
✅ Set up CloudWatch log group and Container Insights
✅ Launch your Fargate task(s)
✅ Configure auto-scaling policies

This takes about 5–6 minutes. You'll see the status go from "Provisioning" → "Running."

Step 5: Access Your Application

Once the status shows Running:

In the ECS console, click on your service
Go to the Networking tab
Find the Load balancer DNS name — it'll look like:

   my-web-app-alb-123456789.us-east-1.elb.amazonaws.com

Open that URL in your browser — your app is live! 🎉

To add a custom domain: Create a CNAME record in your DNS provider pointing your domain to the ALB DNS name. For HTTPS, attach an AWS Certificate Manager (ACM) certificate to the ALB listener.

What Just Happened Under the Hood?

Express Mode created real, standard AWS resources. Let's peek behind the curtain:

Your AWS Account
├── ECS Cluster: "default" (or new)
│   └── Service: "my-web-app"
│       └── Task: running on Fargate
│           └── Container: your image
├── Application Load Balancer (shared)
│   ├── Listener (port 80/443)
│   └── Target Group → your tasks
├── Security Groups
│   ├── ALB SG (allows 80/443 inbound)
│   └── Task SG (allows traffic from ALB SG only)
├── CloudWatch
│   ├── Log Group: /ecs/my-web-app
│   └── Container Insights: enabled
├── IAM Roles
│   ├── Task Execution Role (pulls images, writes logs)
│   └── Task Role (your app's AWS permissions)
└── Auto Scaling
    ├── Target: ECS service
    └── Policy: target tracking (CPU/memory-based)

Every one of these resources is visible in your AWS console. You can modify, extend, or even detach them from Express Mode if you need full control. This is the fundamental difference from App Runner — you're not using a black box.

Deploying Updates

After your initial deployment, updating your app is straightforward:

Via Console

Build and push a new image to ECR with a new tag (or :latest)
Go to your ECS service in the console
Click Update
Select the new task definition revision (or force a new deployment if using :latest)
ECS performs a rolling update — no downtime

Via CLI (Faster)

# Force a new deployment (re-pulls :latest image)
aws ecs update-service \
  --cluster default \
  --service my-web-app \
  --force-new-deployment

Via GitHub Actions (Best for Production)

Here's a minimal GitHub Actions workflow that deploys on every push to main:

name: Deploy to ECS Express

on:
  push:
    branches: [main]

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::${{ secrets.AWS_ACCOUNT_ID }}:role/github-actions-deploy
          aws-region: us-east-1

      - name: Login to Amazon ECR
        id: login-ecr
        uses: aws-actions/amazon-ecr-login@v2

      - name: Build, tag, and push image
        env:
          ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
          IMAGE_TAG: ${{ github.sha }}
        run: |
          docker build -t $ECR_REGISTRY/my-web-app:$IMAGE_TAG .
          docker push $ECR_REGISTRY/my-web-app:$IMAGE_TAG

      - name: Update ECS service
        run: |
          aws ecs update-service \
            --cluster default \
            --service my-web-app \
            --force-new-deployment

💡 Pro tip: Use OIDC (OpenID Connect) instead of storing AWS access keys in GitHub Secrets. It's more secure and is the recommended approach in 2026. The role-to-assume parameter above uses OIDC.

Cost Breakdown: What You'll Actually Pay

ECS Express Mode doesn't add any surcharge — you pay standard AWS pricing:

For the Setup in This Tutorial (0.25 vCPU, 0.5 GB, 1 Task)

Fargate Compute:
  vCPU:   0.25 × $0.000011244/sec × 2,592,000 sec/month = $7.29/mo
  Memory: 0.5  × $0.000001235/sec × 2,592,000 sec/month = $1.60/mo
  Subtotal: $8.89/mo

Application Load Balancer:
  Hourly:  $0.0225/hr × 720 hrs = $16.20/mo
  LCU:     ~$1–3/mo (minimal traffic)
  Subtotal: ~$17–19/mo

CloudWatch Logs: ~$0.50–1/mo

Total: ~$27–29/month

Compare That To...

Platform	Same Workload (0.25 vCPU, 0.5 GB)	Notes
ECS Express Mode	~$27–29/mo	Full AWS ownership
Railway	~$16–21/mo	Usage-based, no ALB cost
Render	~$7–15/mo	Hobby tier, limited
Vercel	~$25–35/mo	Pro plan + usage

At this scale, PaaS platforms are competitive. But as we showed in last post, the economics flip dramatically at growth stage. Express Mode's shared ALB feature (splitting that $16/mo across 5+ services) is what makes it cost-competitive even at small scale.

Common Issues and Troubleshooting

❌ "Service is in DRAINING state"

Your container is failing health checks. Check:

CloudWatch Logs → Look for crash errors in /ecs/my-web-app
Health check path → Ensure your app responds on the configured health check endpoint
Port mapping → The port in Express Mode must match what your app actually listens on

❌ "Unable to pull image"

Usually an ECR permissions issue:

# Verify the image exists
aws ecr describe-images \
  --repository-name my-web-app \
  --region us-east-1

# Verify the task execution role has ECR pull permissions
aws iam get-role --role-name ecsTaskExecutionRole

❌ "Service stuck at 0 running tasks"

Check:

Subnet configuration — Fargate tasks need subnets with internet access (public subnet with IGW, or private subnet with NAT Gateway)
Security group — Ensure the task security group allows outbound traffic to pull the container image
Resource limits — You might have hit Fargate limits in your region. Request a limit increase.

Advanced: Migrating from Express Mode to Standard ECS

If you outgrow Express Mode's defaults, you can "eject" to full control:

Note all the resources Express Mode created (cluster, service, task def, ALB)
Modify them individually through the standard ECS console or CLI
Express Mode doesn't prevent you from customizing — it just provides defaults

Common reasons to eject:

Need multi-AZ load balancer configuration
Need VPC peering or PrivateLink
Need EFS volumes or GPU instances
Need blue/green deployments with CodeDeploy
Need custom placement strategies (e.g., spread across AZs)

What's Next?

You've successfully deployed a containerized app with ECS Express Mode. Here's what to tackle next:

Add a custom domain and HTTPS — Use Route 53 + ACM to add SSL
Set up CI/CD — We'll cover this in detail in How to Set Up a CI/CD Pipeline with GitHub Actions and AWS ECS
Add a database — Connect to RDS or DynamoDB
Configure auto-scaling — Fine-tune your scaling policies based on actual traffic

TL;DR

What	Details
What it is	Simplified ECS deployment that auto-provisions ALB, security groups, scaling, and monitoring
Who it's for	Developers who want App Runner simplicity with ECS power
Setup time	5–10 minutes
Cost	Standard Fargate + ALB pricing (~$27/mo for smallest config)
Key advantage	Shared ALBs (save ~$16/mo per additional service)
Lock-in risk	Zero — creates standard AWS resources you fully own
Production-ready?	Yes, with CI/CD and proper monitoring

Even simpler? If you want to skip the ECR push, CLI commands, and console clicking entirely — TurboDeploy handles all of this in a single git push. Same ECS Fargate infrastructure, same AWS pricing, zero AWS console required.

Join the waitlist →

AWS App Runner Is Dead — Here's What You Should Use Instead (2026)

Parag Agrawal — Mon, 13 Apr 2026 12:24:24 +0000

If you're running apps on AWS App Runner — or were thinking about using it — you need to read this.

AWS has announced that App Runner will no longer accept new customers starting April 30, 2026.

This isn't speculation. It's in the official AWS documentation. Existing customers can still use the service and create new resources, but AWS has confirmed they won't be introducing new features. The service is entering maintenance mode — which, in AWS language, is one step before eventual deprecation.

If you're currently on App Runner, you need a migration plan. If you were evaluating it for a new project, you need a new direction.

This post covers everything: what happened, why AWS made this call, and exactly what you should use instead — with specific migration steps.

What Was AWS App Runner?

For those unfamiliar, App Runner was AWS's answer to Heroku/Render/Railway. Launched in 2021, it was designed to be the simplest way to deploy containerized web applications on AWS.

The pitch was compelling:

✅ Point to a container image or source code repository
✅ App Runner handles build, deploy, HTTPS, scaling, and load balancing
✅ No need to configure VPCs, ECS clusters, task definitions, or ALBs
✅ Runs on Fargate under the hood
✅ Auto-scales to zero (you only pay when your app gets traffic)

It was genuinely good for simple use cases. If you wanted to deploy a single API or web app without learning ECS, App Runner got you there in under 5 minutes.

So why is AWS killing it?

Why AWS Is Sunsetting App Runner

AWS hasn't published an official "here's why" blog post, but the reasoning becomes clear when you look at the timeline:

The Real Reason: ECS Express Mode

In late 2025 / early 2026, AWS launched ECS Express Mode — a new feature within Amazon ECS that provides almost everything App Runner offered, but within the ECS ecosystem.

ECS Express Mode automates:

Cluster creation on Fargate
Application Load Balancer provisioning
HTTPS/TLS configuration
Security groups and networking
Auto-scaling policies
CloudWatch monitoring and logging

In other words, ECS Express Mode makes ECS nearly as simple as App Runner — but with full access to the ECS feature set. It's App Runner's simplicity, with ECS's power.

Having two services that do essentially the same thing creates confusion and maintenance overhead for AWS. App Runner was always a thin wrapper around ECS Fargate anyway. Rather than maintaining two products, AWS chose to consolidate into one — and ECS Express Mode is the survivor.

What This Means for the Broader Market

This is actually a positive signal for the industry. It means:

AWS is investing heavily in making ECS simpler — which validates the core thesis that container deployment needs to be easier
The "App Runner" approach of simplicity-first is the right direction — AWS just decided to build it into ECS rather than maintain a separate service
ECS Fargate is the long-term bet — if you're building on ECS Fargate today, you're on the right side of AWS's strategy

This is also exactly the thesis behind TurboDeploy. More on that later.

The Timeline: What's Happening When

Here's what you need to know:

Date	What Happens
Now (April 2026)	App Runner is fully functional for existing customers
April 30, 2026	App Runner stops accepting new customers. If you haven't created an App Runner service before this date, you won't be able to.
Post April 30	Existing customers can continue using App Runner, create new services, and manage workloads. AWS will maintain security and availability.
Future (date TBD)	No new features will be added. Eventually, AWS will likely announce a full sunset date.

The writing is on the wall. Even if you're an existing customer, starting a migration now — while there's no time pressure — is the smart move.

What Should You Use Instead?

You have three main options, depending on your needs. Let's break down each one.

Option 1: Amazon ECS Express Mode (AWS's Official Recommendation)

This is the most direct replacement. AWS explicitly recommends ECS Express Mode for App Runner users.

What you get:

Nearly identical simplicity to App Runner
Provide a container image → get a running service with ALB, HTTPS, auto-scaling
Full access to underlying ECS resources (you can customize later)
No additional cost beyond standard Fargate + ALB pricing
Shares ALBs across up to 25 services to reduce costs

How to get started with ECS Express Mode:

Go to the Amazon ECS console
In the left nav, select Express mode
Click Create
Enter your container image URI (from ECR or any public registry)
(Optional) Configure CPU, memory, environment variables
Click Create — done

That's it. ECS Express Mode provisions the cluster, service, ALB, security groups, auto-scaling, and CloudWatch monitoring automatically.

Key difference from App Runner: Express Mode requires a pre-built container image. App Runner could build from source code. So you'll need a CI/CD step (like GitHub Actions) to build and push your Docker image to ECR before Express Mode can deploy it.

→ We'll cover this end-to-end in our upcoming post: How to Set Up a CI/CD Pipeline with GitHub Actions and AWS ECS

Who this is best for: Developers who are comfortable with Docker and want to stay 100% within the AWS ecosystem with minimal setup.

Option 2: Amazon ECS Fargate (Standard Mode)

If you need more control than Express Mode provides — or you want to understand what's happening under the hood — standard ECS Fargate gives you full power.

What you get:

Complete control over networking, IAM roles, task definitions, and deployment strategies
Blue-green and rolling deployments
Custom health check configurations
Integration with any CI/CD system
Multi-container task definitions (sidecars, logging agents, etc.)

The trade-off: You're back to configuring VPCs, ALBs, target groups, security groups, and IAM roles manually. This is significantly more complex than Express Mode.

→ We'll publish a full step-by-step guide: How to Deploy a Docker Container on AWS ECS Fargate

Who this is best for: Teams with DevOps experience who need fine-grained control over their infrastructure.

Option 3: A Deployment Platform That Handles the Complexity for You

Both ECS Express Mode and standard Fargate still require you to:

Build and push Docker images yourself (or set up CI/CD)
Manage your own ECR repositories
Configure environment variables through AWS interfaces
Deal with AWS IAM role setup
Monitor deployments through the AWS console

If you want the App Runner experience — "point to my code and deploy" — but don't want to lose the benefits of running in your own AWS account, this is where tools like TurboDeploy come in.

TurboDeploy sits in the gap between "PaaS simplicity" and "AWS control":

You connect your AWS account via a secure IAM role
You point to your GitHub repo
TurboDeploy handles the Docker build, ECR push, ECS service creation, ALB setup, and monitoring
Everything runs in your AWS account — you're not moving to someone else's cloud

This is essentially what App Runner was supposed to be, but with the added benefit that TurboDeploy doesn't need to be an AWS service to keep working. If TurboDeploy disappears tomorrow, your ECS services keep running in your account, unchanged.

Who this is best for: Developers and startup founders who want the App Runner "just deploy it" experience without vendor dependency.

→ Learn more: Why We're Building TurboDeploy — The Problem with Cloud Deployment in 2026

Comparison Table: Your Migration Options at a Glance

Feature	App Runner (dying)	ECS Express Mode	ECS Fargate (Standard)	TurboDeploy
Setup complexity	Very Low	Low	High	Very Low
Build from source code	✅ Yes	❌ Need CI/CD	❌ Need CI/CD	✅ Yes
HTTPS/TLS	✅ Automatic	✅ Automatic	⚙️ Manual (ACM + ALB)	✅ Automatic
Auto-scaling	✅ Built-in	✅ Built-in	⚙️ Manual config	✅ Built-in
Custom domains	✅	✅ (via Route53)	⚙️ Manual	🔜 Roadmap
Full AWS resource access	❌ Limited	✅ Full	✅ Full	✅ Full
Scale-to-zero	✅	❌	❌	❌
Long-term viability	❌ Sunsetting	✅ AWS investment	✅ Stable	✅ Active development
Runs in your account	✅	✅	✅	✅
Additional cost	App Runner pricing	Fargate + ALB only	Fargate + ALB only	Fargate + ALB + TurboDeploy

Step-by-Step: Migrating from App Runner to ECS Express Mode

If you have an existing App Runner service and want to migrate to ECS Express Mode, here's the recommended approach:

Step 1: Inventory Your App Runner Services

List all your App Runner services and document:

Container image source (ECR or source code)
Environment variables
CPU and memory configuration
Custom domain mappings
Auto-scaling configuration

aws apprunner list-services --region us-east-1

Step 2: Ensure Your Container Image is in ECR

If your App Runner service builds from source code, you'll need to set up a container build pipeline first. The simplest approach:

Add a Dockerfile to your repository (if you don't have one)
Create an ECR repository in your AWS account
Set up GitHub Actions to build and push on every commit

# Create an ECR repository
aws ecr create-repository --repository-name my-app --region us-east-1

→ Don't have a Dockerfile? Check out: How to Write a Production-Ready Dockerfile

Step 3: Create an ECS Express Mode Service

Open the ECS Console → Express mode → Create
Enter your ECR image URI
Configure CPU, memory, and environment variables to match your App Runner settings
Click Create

Your new service will be live in minutes with an AWS-managed URL.

Step 4: Set Up DNS Migration (Blue-Green)

AWS recommends a blue-green approach for zero-downtime migration:

Create a Route 53 weighted routing record set
Point 10% of traffic to the new ECS Express service
Monitor for errors, latency, and functionality
Gradually increase to 25% → 50% → 100%
Decommission the App Runner service once all traffic is migrated

# Example Route 53 weighted record
my-app.example.com → App Runner URL (weight: 90)
my-app.example.com → ECS ALB URL    (weight: 10)

Step 5: Tear Down App Runner

Once all traffic is on ECS and you're confident everything works:

aws apprunner delete-service --service-arn arn:aws:apprunner:us-east-1:123456789:service/my-app/xxx

What About Non-AWS Alternatives?

If the App Runner sunset makes you question your AWS commitment entirely, here are your options outside the AWS ecosystem:

Platform	Best For	Trade-off
Railway	Quick deployments, modern DX	Usage-based pricing, you don't own infra
Render	Predictable pricing, easy setup	Less flexibility than AWS
Fly.io	Global edge deployment	More complex networking model
Coolify (self-hosted)	Full control on your own VPS	You manage the PaaS layer + the server

These are all solid options, but they come with the platform tax trade-off: you're paying for convenience with someone else's infrastructure.

The Bigger Picture: What This Tells Us About Cloud Computing in 2026

The App Runner sunset isn't just a product lifecycle event. It's a signal about where cloud deployment is heading:

1. Simplicity is becoming a feature of existing services, not separate products

Instead of creating new "simple" services, cloud providers are making their core services simpler. ECS Express Mode is ECS-made-easy, not a separate product. Expect the same pattern from other AWS services.

2. Containers on Fargate is the "default" deployment model

AWS is clearly betting on ECS Fargate as the standard way to deploy containerized applications. Not Lambda (too limited for many workloads), not EKS (too complex for most teams), but ECS on Fargate.

→ We explore this further in: ECS vs EKS vs Lambda — How to Choose the Right AWS Compute Service

3. The developer experience gap is still the real problem

Even with ECS Express Mode, deploying to AWS is still harder than Vercel or Railway. The gap is smaller than it was in 2021, but it's still there. And that gap is exactly the space where tools like TurboDeploy add value.

TL;DR — What To Do Right Now

If you're currently on App Runner:

✅ Don't panic — your services keep running
✅ Start planning migration to ECS Express Mode
✅ Set up a Docker build pipeline if you don't have one
✅ Test ECS Express Mode with a non-critical service first
✅ Migrate production services using blue-green (Route 53 weighted routing)

If you were considering App Runner for a new project:

✅ Use ECS Express Mode for the closest experience
✅ Or try TurboDeploy for an even simpler experience that deploys to your AWS account
❌ Don't start with App Runner — the service is entering end-of-life

If you're unsure which option is right:

Read our decision guide → How to Choose Between a PaaS and AWS for Your Startup

👉 Join the TurboDeploy waitlist → — Deploy to AWS without the AWS headache.

Why We're Building TurboDeploy - The Problem with Cloud Deployment in 2026

Parag Agrawal — Thu, 09 Apr 2026 15:42:02 +0000

Every developer has been there.

You've built something — an app, a side project, maybe the MVP of your startup. It works on your machine. It runs beautifully in development. And now you need to put it on the internet.

That's when the fun stops.

If you go with AWS, you're suddenly drowning in a sea of IAM roles, VPCs, security groups, task definitions, load balancers, target groups and CloudFormation templates. You didn't sign up for a PhD in infrastructure, but here you are, three hours in, Googling "what is an ECS cluster" at 2 AM.

If you go with a managed platform like Vercel, Railway or Render, the experience is beautiful. Connect your repo, click deploy and you're live. But this simplicity has a price. Literally.

A few months later, your startup starts growing. And that $0/month hobby plan quietly becomes a $200/month, then a $500/month, then a "wait, why is my cloud bill higher than my rent?" situation.

We've lived through both of these nightmares. And that's exactly why we're building TurboDeploy.

The Two Extremes of Cloud Deployment

In 2026, deploying a web application still forces you into one of two painful choices:

Option A: The AWS Way (Powerful but painful)

AWS is the gold standard of cloud infrastructure. It's what Netflix, Airbnb and thousands of serious companies run on. It gives you:

Full control over every aspect of your infrastructure
Transparent, pay-for-what-you-use pricing
No vendor lock-in (it's your account, your resources)
Enterprise-grade security, compliance, and scalability

But the learning curve is brutal.

Just to deploy a simple Node.js app, you need to:

Create a VPC with subnets
Set up security groups
Create an ECR repository
Build and push a Docker image
Write an ECS task definition
Create an ECS service
Configure an Application Load Balancer
Set up target groups and listeners
Configure IAM roles and policies
Set up CloudWatch logging

That's 10 steps before your "Hello World" is live. And if you get one IAM permission wrong, you get a cryptic error message that sends you down a 45-minute Stack Overflow rabbit hole.

Most developers give up somewhere around step 4.

Option B: The PaaS Way (Easy but expensive)

Platforms like Vercel, Railway, Render, Heroku, and Fly.io exist because Option A is so painful. And they're genuinely excellent products. The developer experience is world-class.

But here's what they don't tell you upfront:

They host your application on their infrastructure.

This means:

You're paying a "platform tax": They buy AWS/GCP resources at bulk prices, mark them up 2–5x and resell them to you as "simplified deployment."
Your costs scale with their pricing, not AWS pricing: When your app grows, you don't benefit from AWS's economies of scale — you benefit from their price tiers.
You're locked in: Your infrastructure definitions, environment configurations and deployment pipelines are all proprietary. Moving to AWS later means starting from scratch.
You don't own your infrastructure: Your containers run on their accounts. Your logs are in their dashboard. Your data flows through their network.

Let me put real numbers on this. Here's what a simple web app (2 vCPU, 4 GB RAM, running 24/7) costs per month:

Platform	Monthly Cost (approx.)	What You Get
Vercel (Pro)	$20/seat + usage	Great for frontend, but serverless function costs and bandwidth add up fast
Railway	$50–150+	Usage-based, but grows linearly with traffic
Render	$20–85 per service	Predictable, but no flexibility in underlying infra
AWS ECS Fargate (direct)	$30–50	Same compute, full control, your account

At small scale, the difference is $20–50/month. Not a big deal.

At growth scale (let's say 5 services, production + staging environments, a database and a background worker), the difference becomes $500–1500/month vs. $150–300/month on AWS direct.

That's $3,600–$14,400/year in "platform tax." For an early-stage startup watching every dollar, that's the difference between hiring a part-time contractor and not.

There Should Be a Third Option

We kept asking ourselves the same question:

What if you could have the simplicity of Vercel — but everything runs in your own AWS account?

No markup. No lock-in. No "we host your app on our cloud and charge you 3x."

Just connect your AWS account, point to your repo, click deploy — and everything gets provisioned in your cloud, with your billing, under your control.

That's TurboDeploy.

What TurboDeploy Actually Does

TurboDeploy is a deployment platform for AWS. But unlike traditional PaaS platforms, we never become your hosting provider. AWS is your hosting provider. We're just the orchestration layer that removes the pain.

Here's how it works:

You connect your AWS account — using a secure, read-scoped IAM role (via AWS AssumeRole). No long-term access keys, ever. We create a narrowly scoped role that can only do what's needed for deployment.
You point to your GitHub repo — or upload your project. Tell us the build command, start command, and port.
You click deploy — and everything happens automatically:
- We pull your code
- Build a Docker image
- Push it to Amazon ECR in your account
- Create an ECS task definition
- Provision an ECS Fargate service behind an Application Load Balancer
- Configure logging via CloudWatch
- Return a public URL
You see everything in your dashboard — deployment status, logs, errors, and your live URL.

The key difference: After deployment, if you go to your AWS console, you'll see the ECS service, the load balancer, the CloudWatch logs — all in your account. If you ever stop using TurboDeploy, your app keeps running. Nothing changes. Because it was never on our infrastructure to begin with.

The Architecture (Simplified)

For the technical readers, here's what's happening under the hood:

┌─────────────┐     ┌──────────────────┐     ┌─────────────────────────────────┐
│  Your Code  │────▶│   TurboDeploy    │────▶│    YOUR AWS Account             │
│  (GitHub)   │     │  (Orchestration)  │     │                                 │
└─────────────┘     └──────────────────┘     │  ┌─────┐  ┌──────┐  ┌──────┐  │
                           │                  │  │ ECR │─▶│ ECS  │─▶│ ALB  │──│──▶ Users
                     AssumeRole               │  └─────┘  │Fargate│  └──────┘  │
                    (temp creds)              │           └──────┘             │
                                              │  ┌──────────────┐             │
                                              │  │  CloudWatch   │             │
                                              │  │  (Logs)       │             │
                                              │  └──────────────┘             │
                                              └─────────────────────────────────┘

Security model: TurboDeploy uses AWS AssumeRole to get temporary, scoped credentials. We never store permanent AWS access keys. The IAM role we create has the minimum permissions needed — it can push images, manage ECS services, and configure load balancers. It can't access your S3 buckets, databases, or anything else.

We also never see or touch your application data. We only orchestrate infrastructure creation. Your code runs entirely in your account.

Why We're Building This Now

Three things converged in 2026 that make this the right moment:

1. AWS just made ECS dramatically simpler

AWS launched ECS Express Mode — a streamlined way to deploy containers on Fargate with automated ALB, auto-scaling, and security group provisioning. This is a signal that even AWS recognizes the deployment experience needs to be simpler. TurboDeploy builds on top of this foundation to make it even easier.

→ Read our deep dive: AWS ECS Express Mode: The Complete Getting Started Guide

2. The "platform tax" backlash is real

Developers are increasingly vocal about PaaS pricing. Reddit threads in r/devops and r/webdev are full of developers sharing "bill shock" stories — especially from Vercel. The shift back to owning infrastructure is happening, but the tooling gap makes it hard for most teams to make the switch.

→ We break down the numbers: The Hidden Costs of Vercel, Railway, and Render — A Real-World Pricing Breakdown

3. "Bring your own cloud" is becoming a real pattern

We're not the only ones who see this trend. But most tools in this space are either too complex (Terraform, Pulumi — great but require IaC expertise) or too opinionated (Coolify, Dokploy — deploy to VPS, not to your cloud account). TurboDeploy sits in the sweet spot: opinionated enough to be simple, flexible enough to use real AWS infrastructure.

What TurboDeploy Is NOT

Let's be honest about our scope. This matters more than marketing promises:

❌ Not a full AWS management console — We do one thing: deploy containerized web apps to ECS Fargate.
❌ Not a database provisioning tool — (Yet. It's on the roadmap, but not in v1.)
❌ Not for multi-service microservice architectures — (Also roadmap. v1 is single-container apps.)
❌ Not Kubernetes — We deliberately chose ECS Fargate over EKS because most startups don't need Kubernetes.
❌ Not a hosting provider — We never host your app. Period.

We're intentionally narrow. We'd rather do one thing perfectly than ten things poorly.

Who Is This For?

TurboDeploy is for:

Solo developers who want AWS-grade infrastructure without the AWS learning curve
Early-stage startup founders who want to own their infrastructure from day one without hiring a DevOps engineer
Small teams who are currently on Vercel/Railway/Render and starting to feel the cost pressure
Indie hackers who want cloud costs measured in dollars, not hundreds of dollars

Even if you're a 200-person engineering org with a dedicated platform team, then also we can probably help you.

Where We Are Today

We're being transparent about this: TurboDeploy is in active development.

Our MVP can deploy a single containerized app (Node.js, Python, etc.) to AWS ECS Fargate in your account, with a load balancer and a public URL. It works. We've tested it.

But we're not pretending it's production-ready for everyone. Features like custom domains, auto-rollback, preview environments, and multi-region support are on the roadmap, not in the product today.

We've launched a waitlist at turbodeploy.dev and we're looking for early adopters who want to try it, break it and help us figure out what to build next.

If this sounds like you, sign up. We'll personally onboard you.

What's Coming Next

Over the next few weeks, we'll be publishing deep dives on the topics that matter to developers building on AWS:

Follow along. We're building in public, and we're not pretending we have all the answers.

The Bottom Line

Cloud deployment in 2026 is stuck between two bad options:

AWS gives you power but drowns you in complexity.
PaaS gives you simplicity but charges you a premium for it.

TurboDeploy is the third option: the simplicity of a PaaS, running entirely in your own AWS account.

Your code. Your AWS. No lock-in.

👉 Join the waitlist at turbodeploy.dev →

Unlocking the Potential: Exploring the Future of Web Development with React

Parag Agrawal — Tue, 30 May 2023 14:41:01 +0000

Introduction

Web development has come a long way, and the future looks incredibly promising. One technology that has gained significant popularity and transformed the web development landscape is React. In this article, we will delve into the potential that React brings to the table, unlocking new possibilities and empowering developers to create exceptional web experiences. Whether you're a seasoned developer or just starting out, understanding the power of React is crucial to stay ahead in the ever-evolving world of web development.

What is React?

At its core, React is a JavaScript library for building user interfaces. Developed by Facebook, React provides a declarative and component-based approach, making it easier to build complex UIs by breaking them down into reusable components. With its virtual DOM and efficient rendering techniques, React has gained popularity for its ability to create highly interactive and performant applications.

Unlocking the Potential: Exploring the Key Features of React

React is packed with powerful features that enhance the development process and enable developers to create dynamic web applications. Let's take a closer look at some of these features:

1. Component-Based Architecture

One of the fundamental concepts of React is its component-based architecture. By breaking down the user interface into reusable components, developers can build complex applications more efficiently. Components are self-contained and can be composed together, offering a modular and scalable approach to web development.

2. Virtual DOM

React utilizes a virtual DOM, which is a lightweight representation of the actual DOM. This allows React to efficiently update and render only the necessary components when changes occur, minimizing the impact on performance. The virtual DOM acts as a middle layer between the actual DOM and the application's state, enabling faster rendering and improved user experience.

3. JSX: The Power of JavaScript and HTML Fusion

React introduces JSX, a syntax extension that combines JavaScript and HTML. This powerful fusion allows developers to write HTML-like code within JavaScript, making it easier to create dynamic and interactive user interfaces. JSX enhances code readability and simplifies the process of building complex UI structures.

4. Unidirectional Data Flow

React follows a unidirectional data flow, which means data flows in a single direction within the application. This clear data flow pattern makes it easier to track and manage data changes, resulting in more predictable and maintainable code. Unidirectional data flow enhances code stability and makes debugging and testing more efficient.

5. React Native: Cross-Platform Development

React extends its potential beyond the web with React Native, a framework that enables developers to build native mobile applications using React. By leveraging React's component-based approach, developers can create mobile apps that are indistinguishable from those built using native languages like Java or Swift. React Native allows for code reusability, reducing development time and effort across multiple platforms.

6. Performance Optimization

React's virtual DOM and efficient diffing algorithm contribute to superior performance. By minimizing unnecessary updates to the actual DOM, React ensures optimal rendering speed. Additionally, React's ability to handle large datasets and its support for server-side rendering (SSR) enhance the overall performance of web applications.

Conclusion

React has undoubtedly unlocked a world of possibilities in web development. Its component-based architecture, virtual DOM, JSX syntax, and other powerful features empower developers to create dynamic, performant, and scalable applications. Whether you're building a simple website, a complex web application, or even a mobile app using React Native, you can harness the potential of React to deliver exceptional user experiences.

As the web continues to evolve, React remains at the forefront of web development technologies, constantly evolving and improving. By investing time in learning React and keeping up with its advancements, developers can stay ahead of the curve and unlock the full potential of web development.

In conclusion, Unlocking the Potential: Exploring the Future of Web Development with React is not just a catchy title; it represents the exciting journey that developers can embark upon with React. So, dive in, explore the vast ecosystem of React, and embrace the future of web development.