The right amount of infrastructure for a new project

There's a recurring pattern: a developer starts a new project, looks at what mature companies run, and tries to build that infrastructure from day one. Three environments (dev, staging, prod), Kubernetes, managed databases, separate Redis instances, load balancers.

All of that infrastructure exists to solve problems they don't have yet.

What You Actually Need at the Start

One server. A single VPS with 2-4GB RAM runs a typical Laravel or Next.js application serving thousands of users per day. DigitalOcean, Hetzner, or Linode. $10-20/month. Enough.

A managed database (optional at first). If you're not a DBA, a managed PostgreSQL service (Supabase, RDS, Neon) takes database backups, failover, and upgrades off your plate. Worth the cost for peace of mind.

Nginx in front. Handles TLS termination, serves static files efficiently, and gives you basic rate limiting.

A deployment script. git pull && composer install && php artisan migrate --force && php artisan config:cache. That's a deployment.

The Kubernetes Trap

Kubernetes solves real problems at scale: auto-scaling, zero-downtime deployments across a cluster, rolling updates, self-healing. If you have 50 services and a team of 20, those problems are real.

If you have one application and a team of 3, Kubernetes is a full-time job disguised as infrastructure.

The Right Trigger for Each Tool

• Load balancer: when one server isn't handling the load
• Kubernetes: when you have so many services that managing them separately is more work than managing a cluster
• Staging environment: when you have enough traffic that untested changes on prod are a real risk
• Redis: when your database is the bottleneck (see: the other post about Redis)

Build for the problem you have. Scale to the problem you'll have next.