After I Ditched Docker, My World Became a Better Place

I’ve had a grudge against Docker for a long time.

The most infuriating thing? A Docker image insists on downloading its entire family tree of dependencies, practically moving the whole npm registry onto my machine. And for what? So I can stare blankly as my CI/CD pipeline takes 15 minutes to run… for the tenth time this week.

My crappy little computer’s fan spins like a jet engine just to start a few applications that aren’t even that complex. I change one line of code, and want to see the effect locally, but the time it takes for the image to rebuild is long enough to brew a pot of coffee.

Zoom image will be displayed

And what was all this for?

All I wanted was to run a project that needed Python, Rust, Node.js, and PHP, along with Redis and PostgreSQL.

I’m not building a rocket ship here.

But I always thought I was doing the “right” thing. Docker sounds so impressive, doesn’t it? Environment isolation, production parity, infinite scalability. But all I ever got was complexity, writing YAML until I wanted to puke, and a local environment that threw a tantrum every other day.

Until one day, I just… had enough.

I completely wiped Docker from my workflow.

And guess what? The sky didn’t fall.

In fact, my world became a better place.

What Did I Replace Docker With? The Answer is ServBay

I’ll say it, even if I get flak for it: Most developers don’t need Docker. What they really need is a reliable, straightforward development environment.

So I asked myself: What was I actually using Docker for?

Zoom image will be displayed

1. A Local Development Environment? Docker is Overkill.

My project has a React front-end, a Node.js API, a Python data service, a legacy (but critical) PHP module, and a high-performance tool written in Rust.

Before, all of this was crammed into a clunky docker-compose.yml file. Now, I use ServBay, an integrated development tool. It lets me use a graphical interface to pick the versions of PHP, Node.js, and Python I want, like choosing from a menu. Services like databases and Redis are just a click away to start or stop.

The result? Zero stress. Zero mental overhead. And it’s ridiculously fast.

2. CI/CD Builds? Docker is a Burden.

Docker images were once the nightmare of my GitHub Actions. A single microservice build could easily eat up 12 minutes.

Now? I use GitHub’s official runners that come with pre-installed environments and run a few clean shell scripts. No Docker-in-Docker, no pushing and pulling images, no cache invalidation hell.

My CI now finishes in 3 minutes. Every. Single. Time.

“But… What About Consistency Between Dev and Prod?”

Look, I’ve heard that line so many times my ears are bleeding.

“Docker guarantees consistency between development and production environments!”

Wake up. It absolutely does not.

Unless you strictly lock down the version of every base image and software package in your Dockerfile and force a full rebuild on every change, your container environment is always, silently, dangerously drifting.

How many times have I heard, “but it works on my machine,” only to see it explode in the staging environment? Why? Maybe a low-level dependency in the base image was updated. Maybe a package in Alpine Linux changed. Or maybe some cursed caching layer decided to act up.

Since I switched to ServBay and adopted a .servbay.config for deployment, I've actually encountered fewer environment inconsistency bugs. Why? Because there are fewer moving parts, clearer version control, and a more transparent development environment.

The Real Reason: You Don’t Trust Your Dev Environment

Docker has become a band-aid that covers up the real problems:

  • Messy, outdated documentation.

  • Everyone’s local setup is a unique, snowflake configuration.

  • An onboarding process so chaotic it makes new hires want to quit.

But these are process problems, not container problems.

When I stopped using Docker, I was forced to document the environment setup steps with absolute clarity. And with ServBay, that process is now as simple as one sentence: “Download ServBay, check the boxes for the services you need, and click start.”

Here are my current stats:

  • Build Time: From 12 minutes → 3 minutes

  • New Dev Onboarding Time: From 2 hours → 15 minutes

  • Disk Space: From 20GB+ of Docker images → Less than 500MB

  • Mental Overhead: I finally understand my own tech stack, and I no longer have to investigate mystical problems like “why can’t this container connect to that container?”

Please, Stop Building a K8s Cluster for Your To-Do App

Have you ever met a developer who, with spittle flying, explains the microservice architecture of their simple To-Do app?

“Dude, we have a task creation service, a notification service, using Redis for caching, RabbitMQ for the message queue, data stored in PostgreSQL, and it’s all orchestrated by Kubernetes…”

Wow, sounds impressive.

But in reality, all they probably needed was an Express.js service, a database, and maybe a cron job.

But no, we containerize everything, add five layers of abstraction, and bury ourselves in a sea of YAML — only to spend most of our time debugging why the K8s Ingress isn’t routing to our service.

Let me tell you something you might not want to hear: Developers often mistake the complexity of their tools for engineering maturity. It feels like if you’re not writing elaborate YAML files, you’re not being professional. The result? Most of your time is spent fighting your tools instead of delivering value.

Of course, I’m not saying Docker is useless. In certain scenarios — like needing extreme security isolation or distributing complex non-web applications — it’s still a powerful tool.

But in my day-to-day web development work, it’s the definition of using a sledgehammer to crack a nut.

I don’t need a tool that can simulate an entire data center. I just need an environment that lets me run my code quickly and reliably. And ServBay does exactly that.

So, Here’s the Takeaway

You don’t need containers.

You need clarity, discipline, and a tech stack you can actually control.

And most importantly:

Stop tinkering just to look smart in the tech scene. Start working for speed, sanity, and shipping products.

1
Subscribe to my newsletter

Read articles from Lamri Abdellah Ramdane directly inside your inbox. Subscribe to the newsletter, and don't miss out.

Written by

Lamri Abdellah Ramdane
Lamri Abdellah Ramdane