TIL: When Docker Makes Local Development Easier

There’s a specific kind of frustration that only happens in local development.

The code is fine.
The feature is small.
The ticket looks harmless.

Then you pull the project, run the setup commands, and suddenly half your morning is gone because PostgreSQL is on the wrong version, Redis isn’t running, Node changed again, and someone forgot to mention that one service also needs a custom environment variable.

I’ve been there more than once.

At first, I didn’t think Docker was the answer for local development. I mostly saw it as a deployment thing. Something you use later, when the app is ready to leave your machine. Locally, I preferred to install things myself. Node on the machine. Database on the machine. Maybe Redis too. Simple enough.

Until it wasn’t.

The problem usually appears slowly. One project starts with a frontend app and a small backend API. Then we add a database. Then a queue. Then a worker. Then maybe an object storage service, or a mock service that behaves like a third-party API. Nothing feels too complex on its own, but the full setup starts to become annoying.

And the worst part is not even the first setup. It’s the second one.

A new developer joins the project. Someone changes laptop. Another person comes back to the project after two months. Suddenly the README becomes a checklist of small traps.

“Install this version.”
“Start this manually.”
“Create this folder.”
“Don’t forget to seed the database.”
“Use this port unless it’s already taken.”

That’s where Docker started to make more sense to me.

Not because it’s perfect. It isn’t. Docker can also become messy if we use it badly. But when the project has multiple services, it gives us a cleaner way to say: this is the app, these are the things it needs, and this is how you start them.

A simple docker-compose.yml can remove a lot of guessing.

services:
  app:
    build: .
    ports:
      - "3000:3000"
    environment:
      DATABASE_URL: postgres://app:secret@db:5432/app
      REDIS_URL: redis://redis:6379
    depends_on:
      - db
      - redis
    volumes:
      - .:/app
      - /app/node_modules

  db:
    image: postgres:16
    environment:
      POSTGRES_USER: app
      POSTGRES_PASSWORD: secret
      POSTGRES_DB: app
    volumes:
      - db_data:/var/lib/postgresql/data

  redis:
    image: redis:7

volumes:
  db_data:

This isn’t special. That’s the point.

With a setup like this, the project becomes easier to run because the important parts are written down as code. The database version is clear. Redis is part of the stack. The ports are visible. The app knows where to find its services.

The command becomes boring:

docker compose up

And boring is good here.

I don’t want local development to feel clever. I want it to be repeatable. I want someone to clone the repo, copy the env file, run one command, and start working without asking five different people what’s missing.

There’s another small benefit that I didn’t care about at first. Docker makes it easier to break things safely.

Need to test a migration? Run it locally.
Need to reset the database? Drop the volume.
Need to try a new Redis version? Change the image tag.

Of course, you still need to be careful. A local Docker setup can drift away from production. It can also hide issues if the container is too different from the real deployment. But for most day-to-day frontend and full-stack work, it helps a lot.

Especially when the frontend depends on backend services.

That’s the part I think many frontend developers underestimate. Modern frontend work is rarely just “run the UI”. The UI depends on auth, APIs, feature flags, file uploads, search, queues, and sometimes background jobs. If those pieces aren’t easy to start locally, the frontend work gets slower too.

You either mock too much, or you keep switching environments. Both options have a cost.

Docker gives you a middle ground. You can run enough of the system locally to test real flows, without installing every service directly on your machine.

The trick is to keep it small.

A local Docker setup should help the team, not become a second production cluster. I like starting with the services that are painful to install or easy to mismatch: databases, Redis, object storage, maybe a mail catcher. The app itself can run inside Docker or outside it, depending on the project.

Sometimes I still run the frontend directly with npm run dev. That’s fine. Docker doesn’t need to own everything.

The real lesson for me was this: Docker is useful when it removes repeated setup pain.

If the project has one frontend app and no dependencies, maybe Docker adds more noise than value. But if every developer needs the same database, the same queue, the same worker, and the same fake services, then Docker starts to pay off quickly.

It turns local setup from a private machine problem into a shared project file.

That’s a big shift.

Because once the setup is shared, it can be reviewed. It can be fixed. It can be improved over time. And when something breaks, the team doesn’t have to debug five different laptop setups before even looking at the code.

Today I learned that Docker doesn’t make development easier just because it’s Docker.

It makes development easier when it makes the project easier to start, easier to reset, and easier to share with the next person.