I Ran Kubernetes and Traditional Hosting Side-by-Side — Here's When Kubernetes Actually Won

TL;DR: The thing that actually pushed me to take Kubernetes seriously wasn't hype — it was a 2am deploy that silently murdered our Python worker and nobody caught it until a client emailed us at 8am asking why their background jobs hadn't processed overnight. Six hours of dead silence

📖 Reading time: ~29 min

What's in this article

1. The Setup That Made Me Actually Compare These Properly
2. What 'Traditional Hosting' Actually Looks Like in 2024
3. Standing Up Kubernetes — What the Docs Don't Warn You About
4. Honest Head-to-Head: Where Each One Wins
5. The Comparison Table You Actually Need
6. The Specific Moment Kubernetes Won Me Over
7. When to Stick with Traditional Hosting
8. When Kubernetes Is the Right Call

---

The Setup That Made Me Actually Compare These Properly

The thing that actually pushed me to take Kubernetes seriously wasn't hype — it was a 2am deploy that silently murdered our Python worker and nobody caught it until a client emailed us at 8am asking why their background jobs hadn't processed overnight. Six hours of dead silence from a service that was supposed to be running. The systemd unit had exited with a non-zero code, Nginx was still routing fine (it only fronted the Node.js API anyway), and our monitoring wasn't granular enough to distinguish "worker is responding" from "worker process exists on the filesystem." That's a very different failure mode.

Our stack at the time was textbook "it works until it doesn't": a Node.js 18 API, a Python 3.11 worker pulling from a Redis queue, and a managed Postgres 15 instance, all living on two DigitalOcean Droplets behind an Nginx reverse proxy. Deploys were a bash script that SSH'd in, pulled from git, ran migrations, and restarted services with systemctl restart. For about 18 months this was genuinely fine. Fast, cheap, understandable. A junior dev could debug it at 3am without a PhD in distributed systems.

After the incident, I didn't immediately reach for Kubernetes. I spent a week tightening the traditional setup first — added proper health check endpoints, wired up a dead man's switch in Datadog, wrote a more defensive deploy script. But the root problem wasn't monitoring. The root problem was that our deploy process had zero rollback capability and zero awareness of whether the new process was actually healthy before it stopped the old one. Systemd doesn't do blue-green. Nginx doesn't do weighted traffic splitting unless you're writing Lua. The tooling ceiling was visible.

So I ran both in parallel for three months before committing. The traditional setup kept serving production. I stood up a k3s cluster on three $24/month Droplets and mirrored traffic to it using a 5%/95% split at the DNS level. Here's what I actually tracked:

• Deploy time start to healthy: bash script averaged 47 seconds, k3s rolling deploy averaged 2 minutes 10 seconds — Kubernetes is slower here, full stop
• Failed deploy recovery time: traditional setup required manual SSH intervention every time, Kubernetes auto-rolled back 4 out of 5 failed deploys based on readiness probe failures
• Worker restart detection: traditional caught crashes only when the systemd service exited cleanly; Kubernetes liveness probes caught two hung-but-not-exited worker states the old setup would have missed entirely
• Monthly infra cost delta: traditional two-Droplet setup ran ~$48/month, k3s three-node cluster ran ~$72/month — 50% more for the redundancy

The parallel run was the only honest way to do this comparison. Every blog post I read before starting was written by someone who'd either never run traditional hosting at real load or had never operated Kubernetes past the tutorial. The actual tradeoffs only show up when you're watching both systems handle the same production traffic on the same codebase. For a broader look at tools your team might already be paying for, check out our guide on Essential SaaS Tools for Small Business in 2026 — some of the observability tools there plugged directly into both setups without any config changes, which made the three-month comparison much less painful.

What 'Traditional Hosting' Actually Looks Like in 2024

The thing that catches people off guard is how capable a well-maintained traditional setup actually is. I've seen teams shipping millions of requests per day on a DigitalOcean Droplet running Ubuntu 22.04, PM2, and Nginx — and they sleep fine at night. "Traditional hosting" in 2024 isn't your cousin's shared cPanel account. It's managed VPS, dedicated bare metal from Hetzner, or AWS EC2 instances where your team owns the full stack from OS upward. The tooling is mature, the mental model is simple, and the operational cost is low until it isn't.

A typical production stack for a Node.js API looks exactly like this: Ubuntu 22.04 LTS, PM2 handling process management and restarts, Nginx as the reverse proxy, and Certbot auto-renewing Let's Encrypt certs. The deploy script most teams actually use in practice:

# deploy.sh — runs on the server via SSH from CI
cd /var/www/myapp
git pull origin main
npm install --production
pm2 restart myapp --update-env

# or with zero-downtime if you're being careful
pm2 reload myapp --update-env

That's it. It's not glamorous, but it works. GitHub Actions SSH into the box, run that script, done. Deploys take 15 seconds. No YAML manifests, no container registries, no control planes. For a team of 2–4 engineers shipping a single product, this is genuinely the right call. The Nginx config for a proxied Node app with upstream pooling looks like this:

# /etc/nginx/sites-available/myapp.conf
upstream myapp_backend {
    server 127.0.0.1:3000;
    server 127.0.0.1:3001;  # second PM2 instance if you're cluster-moding
    keepalive 64;
}

server {
    listen 443 ssl;
    server_name api.example.com;

    ssl_certificate /etc/letsencrypt/live/api.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/api.example.com/privkey.pem;

    location / {
        proxy_pass http://myapp_backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Where this model visibly cracks is horizontal scaling. You get a traffic spike and you need three more app servers. Now you're either manually provisioning Droplets and SSHing through the setup checklist, or you've got a half-baked Ansible playbook someone wrote in 2021 that may or may not still work. On AWS the answer is supposedly AMI baking — snapshot your configured EC2 instance, use it in an Auto Scaling Group — but building a reliable AMI pipeline takes real engineering effort. Most teams don't have it. What they have is a Slack message that says "just spin up another box and follow the wiki."

The dirty secret nobody talks about in postmortems: the shell scripts holding these environments together contain years of undocumented decisions. That one sed command in bootstrap.sh that patches a config file? The guy who added it left in 2022. Nobody knows if removing it breaks something. I've inherited setups where the Nginx config had rewrite rules compensating for a routing bug in an old app version — a bug that got fixed, but nobody removed the workaround. The server just carries it forward forever. Traditional setups accumulate tribal knowledge the way old codebases accumulate dead code: silently, continuously, and with nobody taking ownership.

None of this means the approach is wrong. A $24/month Hetzner CX31 with this stack can handle serious load if your app is reasonably efficient. The tradeoff you're making is explicit: low infrastructure complexity, low cost, simple mental model — in exchange for manual scaling, fragile institutional knowledge, and no standardized way to run multiple services without them stepping on each other. That last point is what eventually pushes teams toward containers. Not the scaling. The "we need to run four services on this box and they all need different Node versions" problem.

Standing Up Kubernetes — What the Docs Don't Warn You About

The thing that surprised me most wasn't the complexity of Kubernetes itself — it was how much invisible setup exists between "cluster is running" and "my app is actually deployed." I tested three paths: a self-managed kubeadm cluster on bare VMs, DigitalOcean Kubernetes (DOKS), and AWS EKS. I landed on DOKS for this comparison because EKS adds $0.10/hour per cluster just for the control plane (~$73/month before a single node), and kubeadm means you're responsible for etcd backups, control plane upgrades, and certificate rotation. DOKS gives you a managed control plane for free — you only pay for the worker nodes. That's a meaningful difference when you're evaluating, not running production.

Spinning up the cluster with doctl is genuinely fast — about 4 minutes for a 3-node setup:

# Install doctl first, then authenticate
doctl auth init

# Create a 3-node cluster in NYC3 — s-2vcpu-4gb is $24/month per node
doctl kubernetes cluster create myapp-cluster \
  --region nyc3 \
  --size s-2vcpu-4gb \
  --count 3

# Wait for it... then grab the kubeconfig
# This is step the docs bury in a footnote
doctl kubernetes cluster kubeconfig save myapp-cluster

# Verify your context actually switched
kubectl config current-context

That last command matters more than it looks. kubectl context does not auto-switch when your cluster finishes provisioning. I spent 15 minutes wondering why kubectl get nodes was hitting my old Minikube cluster. The kubeconfig save command merges the new context into ~/.kube/config and sets it as current — skip it and you're talking to the wrong cluster with zero indication that's what's happening.

Once the context is right, Helm 3 is the fastest path to running real infrastructure. No Tiller, no cluster-side component — Helm 3 is purely client-side, which removes a whole attack surface that Helm 2 had. Getting Postgres running:

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

# Install PostgreSQL with a custom password — don't skip the password flag,
# the default leaves it auto-generated and you'll lose it on pod restart
helm install my-postgres bitnami/postgresql \
  --set auth.postgresPassword=yourpassword \
  --set primary.persistence.size=10Gi

# Watch it come up
kubectl get pods -w

Now write your own Deployment. The thing I wish someone had told me: always set resource requests and limits. Without them, Kubernetes has no basis for scheduling decisions, and one misbehaving pod can starve everything else on the node. Here's a working example for a Node.js app:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 2
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: myapp
          image: ghcr.io/yourusername/myapp:1.0.2  # tag explicitly — never use :latest in prod
          ports:
            - containerPort: 3000
          resources:
            requests:
              memory: "128Mi"
              cpu: "250m"
            limits:
              memory: "256Mi"
              cpu: "500m"
          env:
            - name: DATABASE_URL
              valueFrom:
                secretKeyRef:
                  name: app-secrets
                  key: database-url
---
apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  selector:
    app: myapp
  ports:
    - port: 80
      targetPort: 3000
  type: LoadBalancer

The image line above is where most first-timers hit a wall. Your local Docker images are completely invisible to Kubernetes — the nodes need to pull from a registry. I pushed to GitHub Container Registry (GHCR) because it's free for public images and integrates cleanly with GitHub Actions. But I made the classic mistake of leaving the package visibility set to private, then forgetting to create an imagePullSecret. The result was ImagePullBackOff with a cryptic auth error. Fix it by creating the secret and referencing it in your pod spec:

# Create the pull secret from your GHCR credentials
kubectl create secret docker-registry ghcr-secret \
  --docker-server=ghcr.io \
  --docker-username=yourusername \
  --docker-password=YOUR_GITHUB_PAT \
  --docker-email=[e-mail]

# Then add this to your Deployment spec under spec.template.spec:
# imagePullSecrets:
#   - name: ghcr-secret

# Confirm the pod can actually pull now
kubectl describe pod <pod-name> | grep -A5 Events

The kubectl describe command at the end is your first debugging reflex to build. The Events section tells you exactly where Kubernetes got stuck — whether it's a failed pull, a failed readiness probe, or an OOMKill because you set your memory limit too low. Logs tell you what your app thinks; Events tell you what Kubernetes thinks.

Honest Head-to-Head: Where Each One Wins

The thing that surprises most teams moving from VPS hosting to Kubernetes is that K8s doesn't win every category. It wins some of them decisively, loses others just as decisively, and the "right" choice depends almost entirely on where your app sits today — not where you hope it'll be in three years.

Setup Time: Traditional Hosting Wins, No Contest

A DigitalOcean Droplet running Nginx and your app is live in under 15 minutes. I've done it enough times to know the ceiling. With K8s, the first time you stand up a real cluster with ingress, TLS, and a working deployment manifest, you're looking at 2-3 hours minimum — and that's if you're not fighting cert-manager or misconfigured ingress class annotations. The managed options (DOKS, GKE Autopilot) reduce infra setup but don't eliminate the conceptual overhead of writing your first working Deployment + Service + Ingress stack. Kubernetes assumes you already know what it's doing.

Self-Healing: Kubernetes Wins Decisively

Kill a pod manually and watch what happens:

kubectl delete pod myapp-7d9f8b6c4-xk2pq
# pod deleted

kubectl get pods
# myapp-7d9f8b6c4-lm9rt   1/1   Running   0   8s

Eight seconds. The ReplicaSet controller notices the pod count dropped and schedules a replacement immediately. On a traditional server, this behavior requires explicit intent. Your /etc/systemd/system/myapp.service needs Restart=always and RestartSec=5 configured — it doesn't happen by default. I've inherited production setups where a crashed Node process just... stayed down, because nobody added that line. K8s makes the right behavior the default behavior.

Zero-Downtime Deploys: Another K8s Win

Rolling updates in K8s are built into the spec:

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0   # never kill old pods before new ones are ready
      maxSurge: 1         # allow one extra pod during transition

You get this for free. On a traditional server you're either writing your own blue-green swap with Nginx upstream reloads, reaching for a tool like Deployer or Capistrano, or accepting 2-3 seconds of downtime per deploy and hoping users don't notice. That last option is more common than teams admit.

Horizontal Scaling: Not a Fair Fight

Scaling up in K8s:

kubectl scale deployment myapp --replicas=5

Five pods across available nodes, load balancing handled by kube-proxy. The equivalent on traditional hosting means provisioning new VMs, installing dependencies, configuring your load balancer, and possibly snapshotting a base image first so you're not running an Ansible playbook every time. Even with automation the gap is real — K8s reduces scaling to a single command or an HPA policy. The only asterisk is that you need headroom in your node pool, otherwise you're waiting on node provisioning anyway.

Cost at Small Scale: Traditional Hosting Wins

A 3-node DOKS cluster (the minimum for any real HA setup) costs roughly $36-$72/month before you add managed load balancers ($12/mo each on DO) or persistent volumes. A single $12/month Droplet running a low-traffic app with Nginx and systemd costs $12/month. That's it. If your app handles a few hundred requests a day and doesn't need HA, Kubernetes is overhead you're paying for in both money and mental energy. The break-even point is somewhere around needing multiple services, multiple replicas, or multiple engineers deploying independently — below that threshold, a VPS is the economically honest choice.

Debugging Complexity: Depends on What You Call Simple

Traditional hosting debugging is linear. Something broke? Start here:

journalctl -u myapp -n 100 --no-pager

One command, one log stream, one process. With Kubernetes you have more tools, but you also have more layers to check. A request failing might mean the pod is crashlooping (kubectl describe pod), the service selector doesn't match (kubectl get endpoints), the ingress is misconfigured, or the readiness probe is failing silently. The debugging commands are good:

• kubectl logs myapp-pod --previous — logs from the last crashed container, not the current one
• kubectl describe pod myapp-pod — shows events, which is where most config errors surface
• kubectl exec -it myapp-pod -- /bin/sh — drop into the running container directly

But more tools doesn't mean faster diagnosis. The first time a junior dev hits a CrashLoopBackOff with an unhelpful exit code and has to cross-reference pod events, container logs, and liveness probe config simultaneously, they'll miss journalctl. K8s debugging is learnable — it's just not simple.

The Comparison Table You Actually Need

The thing that surprises most teams is that Kubernetes doesn't save money at small scale — it costs more. A DigitalOcean Droplet at $6-12/mo running Nginx + a Node app with a cron job is not a problem Kubernetes solves. It's a problem Kubernetes makes worse. The table below is built around the question: "at what point does the tradeoff actually flip?"

| Factor                  | Traditional VPS           | Managed K8s (DOKS/EKS/GKE)        | Self-Managed kubeadm         |
|-------------------------|---------------------------|------------------------------------|------------------------------|
| Setup complexity        | Low — SSH in, run Nginx   | High — YAML, RBAC, ingress, certs  | Highest — you provision etcd |
| Scaling model           | Manual (resize or script) | Automatic via HPA + cluster scaler | Same as managed, more config |
| Zero-downtime deploys   | Requires scripting        | Built-in rolling updates           | Built-in rolling updates     |
| Pricing floor           | ~$6–12/mo per node        | ~$70–150+/mo (control plane + nodes) | Bare metal + your ops time   |
| Operational overhead    | Medium, predictable       | High upfront, stabilizes over time | Extremely high, always        |
| Recovery from failure   | Manual intervention       | Pod rescheduling, self-healing     | Same + you fix etcd yourself |
| Team skill requirement  | Linux fundamentals        | K8s, Docker, Helm, cloud IAM       | All of the above + kubeadm   |

Managed K8s pricing floors are genuinely painful to pin down because the control plane fee alone on EKS runs $0.10/hr (roughly $73/mo before a single node), and GKE's Autopilot charges per pod resource rather than per node. DOKS doesn't charge for the control plane, which is why it's the cheapest entry point for teams experimenting. My honest advice: go to each provider's pricing calculator right now, configure your actual expected workload, and ignore any number in a blog post — including this one. Promo credits routinely distort the math for 60-90 days and then teams get surprised.

The zero-downtime deploy row is the one I'd focus on most if you're evaluating this for a production migration. With a traditional VPS, you can absolutely get blue-green deploys working with some Nginx upstream config and a deploy script, but you're maintaining that script forever. One bad sed command at 2am and you've taken down prod. With managed K8s, rolling updates are the default behavior — you bump the image tag in your Deployment spec and the rollout happens automatically with configurable surge and unavailability settings:

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1        # spin up 1 extra pod before killing old ones
    maxUnavailable: 0  # never drop below desired replica count during rollout

Self-managed kubeadm deserves a direct warning rather than a bullet point: unless you have a dedicated platform engineer whose job description literally includes "owns Kubernetes infrastructure," don't do it. You are responsible for etcd backups, control plane upgrades, certificate rotation, and CNI plugin compatibility. When etcd corrupts during an upgrade (and at some point, it will), you need someone who has actually practiced the restore procedure. The cost savings at scale on bare metal are real — I've seen teams run large Hetzner bare metal fleets for a fraction of the EKS equivalent — but the operational cost is enormous and usually hidden until an incident.

The skill requirement gap between VPS and managed K8s is steeper than most job postings suggest. You don't just need Docker knowledge — you need to understand RBAC policies, write serviceable Helm charts, debug CrashLoopBackOff from bad resource limits, and configure ingress controllers (which have their own separate learning curve). A team of two backend developers can own a VPS fleet confidently. The same two developers adopting Kubernetes cold will spend their first three months fighting the platform instead of shipping features. That's not a knock on Kubernetes — it's just the honest ramp-up cost you should budget for.

The Specific Moment Kubernetes Won Me Over

The moment that flipped me from "K8s is overkill" to "we needed this months ago" was embarrassingly mundane. We pushed a bad memory leak in a Node 20 background worker, and it started OOMKilling inside the pod. Before I even finished reading the Slack alert, Kubernetes had restarted the container and the service was healthy again. Total downtime: under 10 seconds. The same class of bug on our old DigitalOcean Droplet setup once took us 23 minutes to fully resolve — not because we were slow, but because the recovery path had gaps.

The reason the auto-recovery worked so cleanly was a liveness probe we'd set up almost as an afterthought:

livenessProbe:
  httpGet:
    path: /health
    port: 3000
  initialDelaySeconds: 15   # give the app time to actually boot
  periodSeconds: 10
  failureThreshold: 3        # 3 consecutive failures before K8s pulls the trigger
  timeoutSeconds: 5

Three failures at 10-second intervals means your pod gets 30 seconds to recover on its own before K8s restarts it. That's intentional — you don't want a single slow GC pause nuking your pod. The initialDelaySeconds: 15 is critical too; skip it and K8s will kill your pod on startup before it's even finished loading env vars.

Contrast this with what happened on our Droplet setup. PM2 would dutifully restart the crashed Node process — that part actually worked fine. The problem was Nginx. It held a reference to the old Unix socket path, and the restarted PM2 process sometimes bound to a slightly different socket or needed a moment to re-register. Result: Nginx kept routing to a dead upstream, returning 502s, while PM2 reported everything as "online." Someone had to SSH in, run pm2 restart app && nginx -s reload, and manually verify. That manual step is fine once. It's a liability at 3am on a Saturday.

The second win was canary deployments. On traditional hosting, a canary deploy meant either spinning up a second Droplet and playing games with your load balancer weights, or building some custom Nginx upstream percentage routing — realistically a weekend project that kept getting deprioritized. With K8s, it's a two-field YAML change using a simple two-Deployment pattern:

# stable: 9 replicas, canary: 1 replica
# same Service selector, K8s distributes ~10% traffic to canary naturally
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-canary
spec:
  replicas: 1          # 1 out of 10 total = ~10% traffic
  selector:
    matchLabels:
      app: api
      track: canary
  template:
    metadata:
      labels:
        app: api
        track: canary   # Service selects on 'app: api', catches both deployments
    spec:
      containers:
        - name: api
          image: myrepo/api:v2.1.0-rc1

The third win is the one I'm most embarrassed to admit we needed: secrets management. Before K8s, we had .env files sitting on production servers, committed to a private repo, rotated manually when someone left the team. It was the thing everyone knew was bad but never had a forcing function to fix. Moving to Kubernetes made the right path the easy path. We use external-secrets-operator pointed at AWS Secrets Manager, so the actual secret values never live in our Git repo or on disk — just a reference:

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: api-secrets
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secretsmanager
    kind: ClusterSecretStore
  target:
    name: api-env-secrets   # creates a normal K8s Secret with this name
  data:
    - secretKey: DATABASE_URL
      remoteRef:
        key: prod/api        # path in AWS Secrets Manager
        property: DATABASE_URL

Rotation now happens in AWS Secrets Manager, the operator syncs on the refreshInterval, and pods pick up the new secret on the next restart. No SSH, no manual vim .env, no "who has access to that server again?" The .env file approach isn't a character flaw — it's just what you do when your infrastructure doesn't give you a better option. K8s gives you a better option.

When to Stick with Traditional Hosting

The thing that surprises most devs when they're evaluating Kubernetes is how much of the pitch is genuinely irrelevant to their situation. K8s was designed by teams running thousands of microservices across hundreds of nodes. If you're shipping a WordPress site, a SaaS with 200 users, or an internal tool your company built in 2019 — the operational overhead will absolutely eat you alive before you see a single benefit.

A team of one or two developers has maybe 20-30 hours a week of engineering capacity after meetings, support, and actual feature work. Kubernetes will consume a meaningful chunk of that just for maintenance: certificate rotations, node upgrades, debugging CrashLoopBackOff errors, figuring out why your PVC isn't binding. I've watched solo founders spend three weekends getting a cluster "production-ready" only to realize they'd shipped zero features. The operational tax is real and front-loaded — you pay it before you get anything back.

If your app is a standard LAMP or LEMP stack that hasn't needed to scale horizontally in the last two years, that's your app telling you something. Predictable, low-traffic workloads don't benefit from orchestration. A single Hetzner CX21 (2 vCPU, 4GB RAM, €4.51/mo) running Nginx + PHP-FPM + MySQL will handle most side projects without breaking a sweat. Compare that to a 3-node K8s cluster on Hetzner — you're looking at 3× CX21 minimum plus the load balancer at €5.83/mo, putting you north of €20/mo before you've even considered managed control planes. For predictable traffic, that math doesn't work.

Stateful workloads deserve special attention here. K8s PersistentVolumes technically work, but "technically works" is hiding a lot of pain. If you need a specific RAID configuration, a local NVMe with particular mount flags, or a database that expects very specific filesystem behavior (looking at you, some older Oracle and MSSQL configs), mapping that into a PV/PVC/StorageClass chain is genuinely difficult. You'll fight with access modes, you'll discover that ReadWriteMany isn't supported by the block storage provider you chose, and your database will have opinions about volume expansion that Kubernetes doesn't handle gracefully. A dedicated server or even a VPS with a hand-configured mount point just works here.

My actual recommendation if you want deployment automation without touching Kubernetes: run Coolify (self-hosted, free, runs on a single €5 VPS), Laravel Forge (~$15/mo, manages your own servers via SSH), or Ploi (~$8/mo, similar to Forge but slightly cheaper entry point). These tools give you one-click deployments, SSL via Let's Encrypt, queue workers, database management, and environment variable handling — basically everything a small team needs. Here's a Coolify install that takes under 5 minutes:

# Run on a fresh Ubuntu 22.04 VPS (minimum 2GB RAM)
curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash

# Coolify starts on port 8000 — set up a reverse proxy or use
# their built-in Traefik config to get HTTPS on your dashboard

The honest trade-off: Forge and Ploi give you a polished UI and great support but you're paying monthly forever and they're opinionated about PHP/Node stacks. Coolify is broader (supports Docker Compose, static sites, databases) and self-hosted, but you own the maintenance. Either way, you get 90% of what Kubernetes offers for a deployment workflow at 10% of the complexity — which is the right call until your team grows, your traffic genuinely unpredictable, or you're running enough services that manual server management starts costing you more time than learning K8s would.

When Kubernetes Is the Right Call

The signal I watch for most is when your on-call team starts writing custom scripts to restart specific services, scale individual components, or route traffic around a broken node. That improvised orchestration layer you're building? Kubernetes ships that as a first-class feature. When your bash scripts start looking like a half-broken scheduler, you've already decided you need K8s — you just haven't admitted it yet.

Independent scaling is the core argument

If your API pod needs 20 replicas during a product launch while your background workers sit at 2, traditional hosting makes you choose between over-provisioning the workers or under-provisioning the API. With K8s you just write two separate Deployment specs with different resource requests and autoscaling rules. They share cluster resources without coupling their scaling behavior. The thing that genuinely surprised me the first time I set this up was how little YAML it actually took:

# api-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
      - name: api
        image: myapp/api:v1.4.2
        resources:
          requests:
            cpu: "500m"
            memory: "512Mi"
          limits:
            cpu: "1000m"
            memory: "1Gi"
---
# worker-deployment.yaml — same cluster, completely independent scaling
apiVersion: apps/v1
kind: Deployment
metadata:
  name: worker
spec:
  replicas: 2
  template:
    metadata:
      labels:
        app: worker
    spec:
      containers:
      - name: worker
        image: myapp/worker:v1.4.2
        resources:
          requests:
            cpu: "250m"   # workers are CPU-light, don't over-allocate
            memory: "256Mi"

The Docker Compose to K8s mental leap is real but survivable

Your team knowing Docker is genuinely useful — the image build pipeline, layer caching, multi-stage builds, all of that carries over directly. The conceptual jump is that Compose describes what runs on one machine, while K8s describes what runs across a cluster of machines where any individual node can disappear. That shift changes how you think about storage, networking, and state. A volume mount in Compose is trivial; in K8s you're now thinking about PersistentVolumeClaims, storage classes, and whether your cloud provider's CSI driver handles ReadWriteMany. Tools like kompose convert can translate Compose files into K8s manifests, but I'd treat the output as a learning aid rather than production config — it rarely handles secrets, health checks, or resource limits correctly.

Zero-downtime deploys alone can justify the switch

Building rolling deploys on traditional hosting without K8s usually means NGINX upstream config manipulation, custom health check scripts, and a deployment runbook that someone forgot to update six months ago. K8s rolling updates with maxUnavailable: 0 and maxSurge: 1 give you this out of the box, plus automatic rollback if your new pods fail readiness probes. The readinessProbe is the piece most teams misconfigure early on — if you don't set it, K8s sends traffic to pods that are still warming up a JVM or loading a model into memory, and you get a flood of 502s during deploys. Get this right and your deploys stop being events.

Managed K8s on AWS/GCP/Azure removes the hardest parts

Running your own control plane is a full-time job. EKS, GKE, and AKS offload that completely — you pay around $0.10/hour per cluster on EKS (as of 2024 pricing) for a managed control plane, and in exchange you never touch etcd, API server certificates, or control plane upgrades. The integration depth matters too: GKE can automatically provision a Google Cloud Load Balancer when you create a Service of type LoadBalancer, tie into Cloud IAM via Workload Identity so pods get GCP permissions without storing service account keys as secrets, and connect to Cloud SQL via the sidecar proxy pattern without punching holes in your VPC. If you're already running RDS and using IAM roles for EC2, EKS with IRSA (IAM Roles for Service Accounts) extends that same model to pods with maybe two hours of config work.

HPA with custom metrics is where K8s actually pulls ahead

CPU-based autoscaling is fine for stateless services, but if you're running workers that process a queue, you want to scale on queue depth — not CPU. The Horizontal Pod Autoscaler supports custom metrics via the custom.metrics.k8s.io API, which means you can point it at a metric from Prometheus, Datadog, or directly from SQS/Pub-Sub via an adapter. A realistic setup looks like this: your SQS queue length is exposed via KEDA (Kubernetes Event-Driven Autoscaling), and HPA scales your workers from 0 to 50 replicas based on messages in flight. Scale-to-zero on workers that are genuinely idle is something you can theoretically build on traditional autoscaling groups, but the feedback loop is slower and the minimum billing unit is usually a full EC2 instance. With K8s you can scale fractional CPU workers down to nothing and back up in under 30 seconds.

Gotchas I Hit That Cost Me Real Time

The one that got me first — and I've watched it get almost every team that migrates to Kubernetes — is deploying pods without resource requests and limits. You think "it's fine, we're the only tenant on this cluster," then one service starts leaking memory during a traffic spike and your entire node goes into memory pressure. The kubelet starts evicting pods semi-randomly. Suddenly your database sidecar is dead and nothing in the logs explains why. Always set both requests and limits, even if your estimates are rough at first:

resources:
  requests:
    memory: "128Mi"
    cpu: "100m"
  limits:
    memory: "512Mi"
    cpu: "500m"

Start conservative, then watch actual usage in your metrics and tune. The requests value affects scheduling decisions; the limits value triggers OOMKill or CPU throttling. They're different knobs. Most people treat them as one.

I skipped PodDisruptionBudgets on a staging cluster for months because drains were infrequent. Then I did a node upgrade on a production cluster — one node drain, three replicas of my API service, but two happened to be co-scheduled on the same node. Down to zero. The fix is embarrassingly simple and should live next to every Deployment:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api-pdb
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app: api

The Nginx Ingress controller + cert-manager combo is the most deceptively fiddly setup I've dealt with. Getting TLS working sounds like a 20-minute job. It took me most of an afternoon the first time. The annotations are not forgiving — kubernetes.io/ingress.class vs ingressClassName field depends on which version of ingress-nginx you're running. The cert-manager ClusterIssuer staging vs production ACME endpoint confusion will get you at least once. And if you forget the cert-manager.io/cluster-issuer annotation on the Ingress object itself, the certificate just... never gets requested. No error. Silence.

# The annotation that silently does nothing if you typo it:
annotations:
  cert-manager.io/cluster-issuer: "letsencrypt-prod"  # must match ClusterIssuer name exactly
  nginx.ingress.kubernetes.io/ssl-redirect: "true"

The RBAC error every Kubernetes user has memorized by now:

Error from server (Forbidden): clusterrolebindings.rbac.authorization.k8s.io
is forbidden: User "your-user" cannot create resource "clusterrolebindings"
in API group "rbac.authorization.k8s.io" at the cluster scope

This hits you when you're installing Helm charts that need cluster-level permissions (Prometheus, Argo CD, basically anything non-trivial). The fix is running kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user=$(gcloud config get-value account) on GKE, or the equivalent on your provider. But the deeper lesson is understanding that your kubeconfig user is not automatically cluster-admin even if you created the cluster. Document this in your team's runbook immediately.

Traditional hosting has its own class of silent killers. The one I hit most on bare-metal and VM setups: systemd unit files where EnvironmentFile= points to /etc/myapp/.env, that file gets created during provisioning, but on a server rebuild the path is subtly different or the file permissions are wrong. The service starts, systemd reports active (running), but every environment variable the app expects is empty. No crash, no error — just wrong behavior at runtime. Always add an ExecStartPre check:

[Service]
EnvironmentFile=/etc/myapp/.env
ExecStartPre=/bin/test -f /etc/myapp/.env
ExecStart=/usr/bin/node /opt/myapp/server.js

The mistake that cuts across both worlds: not setting up log aggregation before you need it. kubectl logs only gives you the current running pod's stdout. Pod crashes and restarts? You get the new pod's logs. The previous container's logs are accessible briefly with kubectl logs --previous, but once that pod is gone from the node, that data is gone. On traditional hosts, relying on journald without shipping to something persistent like Loki, Papertrail, or even a simple rsyslog remote target means the same problem. Set up your log shipping on day one — not after the first incident where you're staring at an empty log stream trying to understand why the app died at 3am.

---

Disclaimer: This article is for informational purposes only. The views and opinions expressed are those of the author(s) and do not necessarily reflect the official policy or position of Sonic Rocket or its affiliates. Always consult with a certified professional before making any financial or technical decisions based on this content.

---

Originally published on techdigestor.com. Follow for more developer-focused tooling reviews and productivity guides.