Stop Dockerizing Everything: When a Single next start Is Enough

Last year I spent three days writing a Dockerfile, a docker-compose.yml, an nginx reverse proxy config, and a GitHub Actions pipeline to deploy a Next.js app that had four pages and zero paying users.

Three days. For infrastructure nobody asked for.

I could have run vercel deploy and been live in 90 seconds. Instead I was debugging why my multi-stage build kept failing because node-gyp couldn't compile a native module in Alpine Linux.

If this sounds familiar, this post is for you.

The Setup That Nobody Needs

Here's what I see indie hackers build before they have a single customer:

• Docker container with multi-stage builds
• Docker Compose with separate services for app, database, Redis, and worker
• Nginx or Traefik as a reverse proxy
• CI/CD pipeline with build, test, lint, and deploy stages
• Sometimes Kubernetes. For one app. With three routes.

This isn't engineering. It's procrastination disguised as professionalism.

The Question That Fixes Everything

Before adding any infrastructure, ask one question: "Do I have paying users who need this?"

Not "might I need this someday." Not "what if I scale to 10K users." Right now, today, does a real person need this to exist?

If the answer is no, you don't need it.

What Actually Works for Solo Devs

Here's my current deployment for Fleetzz, a real SaaS with real users:

For the marketing site and dashboard frontend: Vercel. Zero config. Push to main, it deploys. SSL, CDN, edge functions, preview deployments. All free tier.

For the API: A single VPS running the Django app with gunicorn behind Caddy. Caddy handles SSL automatically. No Docker. No nginx config files. Just apt install, pip install, systemctl enable.

For the database: Managed PostgreSQL. One click. Automated backups. No Docker volume mounts to worry about.

Total deployment time: under 10 minutes. Total monthly cost: under $20.

When Docker Actually Makes Sense

Docker isn't bad. It's just not always necessary. Here's when it earns its place:

You have a team. "Works on my machine" is a real problem when five people have different Node versions, different OS configurations, and different Python environments. Docker solves this. For a solo dev, you ARE the machine. There's only one.

You need multiple services running together locally. If your app needs PostgreSQL, Redis, and Elasticsearch to run, docker compose up is genuinely faster than installing all three natively. Use Docker for local development, deploy without it.

You're deploying to a shared server with other apps. Containers provide real isolation. If you're running three different apps on one VPS, containers keep them from stepping on each other.

Your production environment must match staging exactly. This matters for enterprise teams deploying to air-gapped networks or regulated environments. If you're shipping a SaaS MVP, Vercel's preview deployments already give you this.

The Real Cost of Over-Engineering

Every piece of infrastructure you add has a maintenance cost:

• Docker images need to be updated when base images get security patches
• Docker Compose files break when you upgrade services
• CI/CD pipelines need debugging when Actions runners change
• Kubernetes clusters need monitoring, scaling policies, and someone who understands pod scheduling

As a solo dev, every hour you spend on infrastructure is an hour you're not spending on the product. Your users don't care if you deploy with Docker or with a bash script. They care if the app works.

The Minimal Stack

If you're building a Next.js SaaS as a solo dev or small team, here's everything you need:

1. Hosting: Vercel (free tier handles most early-stage apps)
2. Database: Neon, Supabase, or PlanetScale (managed, free tier)
3. Deployment: git push to main
4. SSL: Automatic (Vercel, Caddy, or Cloudflare)
5. CI/CD: GitHub Actions with one step: npm run build

That's it. No Dockerfile. No compose file. No nginx. No Kubernetes.

The Rule

If you have fewer than 1,000 users and fewer than 3 developers, you almost certainly don't need containers in production. Use managed services. Push to main. Ship the product.

You can always add Docker later when you actually need it. You can never get back the week you spent writing YAML files instead of talking to customers.

Ship the product first. Optimize the infrastructure never (until you have to).

---

I'm Anas. I build Fleetzz and other products. If this was useful, follow me for more on building SaaS without over-engineering it.