Defang vs Docker Compose on a Compute Engine VM

You SSH into a Compute Engine instance, install Docker, copy your compose.yaml, and run docker compose up -d. It works. Your app is live.

But look at what’s missing.

The Comparison

Capability	Compute Engine + Docker Compose	Defang + Cloud Run
Deploy command	`gcloud compute ssh` + `docker compose up -d`	`defang compose up --provider=gcp`
Docker Compose file	Same compose.yaml	Same compose.yaml
Auto-scaling	None (single instance)	Cloud Run scales to zero and up
Load balancing	None (or DIY nginx)	Google Cloud Load Balancing, automatic
SSL certificates	Manual (certbot + cron)	Google-managed certificates
Zero-downtime deploys	No — containers restart	Rolling revisions via Cloud Run
Database	Container on the VM (data lost if VM dies)	Managed Cloud SQL with backups
Secrets management	`.env` files on disk	Secret Manager
Redundancy	Single instance, single zone	Multi-region capable
OS patches	You manage them	No OS to manage (serverless)
Monitoring	DIY (install agents)	Cloud Monitoring integrated
Log management	DIY (log rotation, shipping)	Cloud Logging automatic

The Hidden Platform You End Up Building

It starts with docker compose up -d on a Compute Engine VM. Then you need HTTPS, so you install nginx and certbot. Then you need the cert to auto-renew, so you add a cron job. Then you need backups, so you write a script. Then you need monitoring, so you install an agent.

Six months later, you’re maintaining:

nginx reverse proxy with upstream configs
certbot with renewal timers and hooks
Backup crons for database dumps to Cloud Storage
Monitoring agents (Cloud Ops agent or third-party)
Log rotation config so your disk doesn’t fill up
SSH key management via OS Login or manual keys
systemd services to restart Docker on boot
Security updates — apt upgrade, reboots, kernel patches
Firewall rules — VPC firewall rules, manually maintained

You started with a Docker Compose file and ended up building an ad-hoc PaaS. Every piece is another thing that can break at 3am.

Same Docker Compose File, Production Outcome

The key insight: the exact same compose.yaml works with both approaches. The difference is what happens around it.

On Compute Engine:

# Copy your compose file to the server
gcloud compute scp compose.yaml your-instance:~/app/

# SSH in and run it
gcloud compute ssh your-instance
cd ~/app && docker compose up -d

# Then spend weeks building everything else...

With Defang:

# Same compose.yaml, production infrastructure
defang compose up --provider=gcp

# That's it. Cloud Run, Cloud SQL, SSL, monitoring — done.

When a Compute Engine VM Makes Sense

Compute Engine with Docker Compose is a reasonable choice when:

Hobby projects where downtime is acceptable
Internal tools used by a small team
Specific machine types you need (GPU, high-memory)
Learning — it’s a great way to understand what production infrastructure actually requires
Budget is the only priority and your time is free

When to Choose Defang

Choose Defang when your Docker Compose app needs to be production-ready:

You need zero-downtime deploys without building a blue-green system
You need managed databases that survive instance failures
You need auto-scaling — including scale-to-zero to save costs
You need SSL certificates that renew themselves
You want to deploy in minutes, not spend weeks building infrastructure
Your team’s time is better spent on the application, not the platform

Try It

Take the compose.yaml you’d run on a Compute Engine VM and deploy it with Defang instead:

# Install Defang
brew install defang-io/defang/defang

# Deploy your existing compose.yaml to GCP
defang compose up --provider=gcp

Same Docker Compose file. Production GCP infrastructure. No platform to maintain.