Defang vs Heroku for Docker Compose Users

You have a multi-service Docker Compose application. A web frontend, an API, a database, a cache, maybe a background worker. You run docker compose up locally and everything works — services discover each other by name, dependencies start in order, and the whole stack runs together.

Now you want to deploy it. Here’s where the paths diverge.

The Docker Compose Gap

Heroku deploys individual containers. Not Docker Compose multi-service applications. That distinction changes everything.

Your compose.yaml locally:

services:
  web:
    build: ./web
    ports:
      - "3000:3000"
    depends_on:
      - api
      - cache

  api:
    build: ./api
    ports:
      - "8080:8080"
    environment:
      - DATABASE_URL
    depends_on:
      - db
      - cache

  db:
    image: postgres:16

  cache:
    image: redis:7

  worker:
    build: ./api
    command: ["node", "worker.js"]
    depends_on:
      - db
      - cache

What this becomes on Heroku:

• web → Heroku App #1
• api → Heroku App #2
• worker → A dyno in App #2 (or App #3)
• db → Heroku Postgres add-on (attached to each app separately)
• cache → Heroku Redis add-on (attached to each app separately)
• Service discovery by container name → Gone. Configure URLs manually.
• depends_on → Gone. Hope everything starts in the right order.
• Shared networks → Gone. Everything goes over the public internet.
• One deploy command → Gone. Deploy each app separately.

What this becomes with Defang:

defang compose up --provider=aws
# Same compose.yaml. All services deploy together.

What Docker Compose Users Lose on Heroku

Docker Compose Feature	Heroku	Defang
Multi-service compose.yaml	Must split into separate apps	Deploys as-is
Service discovery by name	Not supported — use URLs	Works (via private networking)
depends_on ordering	Not supported	Respected
Shared networks	Not supported — public internet only	Private VPC networking
Single deploy command	Deploy each app separately	defang compose up
Local-production parity	Different architecture entirely	Same compose.yaml
Docker Compose volumes	Not supported	Supported

Full Comparison

Feature	Defang	Heroku
Docker Compose support	Native — deploys your compose.yaml	None — individual containers only
Where it runs	Your AWS account (ECS + Fargate)	Heroku’s platform
Infrastructure ownership	You own everything	Heroku owns it
Scaling	AWS auto-scaling	Dyno-based scaling
Database	Managed RDS, ElastiCache, DocumentDB	Heroku Postgres, Redis, third-party add-ons
AI/LLM	Managed AWS Bedrock via annotation	Third-party add-ons
Environments	Named stacks (dev/staging/prod)	Heroku Pipelines
Vendor lock-in	Standard Docker Compose + AWS	Heroku Procfile, platform-specific

When to Choose Defang

• You have a Docker Compose application with multiple services
• You want to deploy your compose.yaml as-is — no rewriting
• You want to own your infrastructure in your own AWS account
• You need access to the full AWS ecosystem (SQS, SNS, Bedrock, etc.)
• You want managed services (RDS, ElastiCache, Bedrock) via simple annotations

When to Choose Heroku

• You’re deploying a single container, not a Docker Compose app
• You don’t use Docker Compose at all
• You want zero infrastructure management and don’t need AWS ownership
• You’re building a prototype that doesn’t need multi-service architecture
• Simplicity is more important than Docker Compose compatibility

Migration Path

Already on Heroku? Defang has built-in migration support:

$ defang init
? How would you like to start?
  Generate with AI
  Clone a sample
> Migrate from Heroku

Defang will:

1. Connect to your Heroku account (via Heroku CLI or auth token)
2. Fetch your app’s configuration, dynos, and add-ons
3. Generate a complete compose.yaml with managed services

Then deploy to your own AWS account:

$ defang compose up --provider=aws

Check the full migration tutorial for details.