Loading...
Stop Using Docker Like It's 2015

Stop Using Docker Like It's 2015

Jonas Scholz - Co-Founder von sliplane.ioJonas Scholz
5 min

Docker has grown up. Have you?

Back in 2015, Docker was shiny and new. You probably ran your first container with something like:

docker run -it ubuntu bash

You felt powerful. You installed Vim inside the container. Maybe even Node.js. You didn't use a .dockerignore. You ran everything as root. You thought you were deploying containers, but really, you were just spinning up a weird kind of VM.

Fast forward to 2025: that same approach is holding you back. Docker today is a fast, composable, production-grade tool - if you actually use it right.

Let's talk about the habits that need to die, and how to do things the 2025 way.


❗️ The Old Habits That Need to Die

1. Using the version: Field in docker-compose.yml

The version: field in Docker Compose files is more obsolute than Bootstrap CSS. Still writing it? Why? Every time you do, a whale cries. Just start with your services: block and move on with your life. Yes, thats a pet peeve of mine.

2. No Healthchecks

If your container crashes and you didn't configure a healthcheck, that's on you. Docker and Compose can't restart or manage something they don't know is broken.

healthcheck:
  test: ["CMD", "curl", "-f", "http://localhost:3000"]
  interval: 30s
  timeout: 5s
  retries: 3

This one change turns Docker Compose into a viable production orchestrator - for real.

3. Root by Default

Still running as root in production? Your container shouldn't be a liability. Create a non-root user in your Dockerfile and switch to it. It's not hard:

RUN useradd -m appuser
USER appuser

Just make sure that your volume mounts are owned by the non-root user. Otherwise shit breaks (trust me, I know).

4. No .dockerignore

Nothing like shipping your .git, .env, and node_modules to production. Use a .dockerignore, save your build context, and keep secrets and bloat out of your image.

You might think this is a no-brainer, but I see it all the time (I run a docker hosting company and see hundreds of Docker app every week).

5. Bloated, One-Stage Dockerfiles

If your Dockerfile has all your build tools, compilers, and test dependencies in the final image: stop. Use multi-stage builds.

FROM node:20 AS build
WORKDIR /app
COPY . .
RUN npm install && npm run build

FROM node:20-slim
WORKDIR /app
COPY --from=build /app/dist ./dist
CMD ["node", "dist/index.js"]

6. Manual Builds Without Cache

You're still typing docker build . every time? Set DOCKER_BUILDKIT=1, start using layer caching, and make your life easier. Add --mount=type=cache for package managers and build systems. It's not just faster - it's smarter.


What Modern Docker Looks Like

Here's how you should be using Docker in 2025:

Compose Without Legacy Bloat

services:
  app:
    build: .
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3000"]
      interval: 30s
      timeout: 5s
      retries: 3
    user: "1000:1000"

Devcontainers, Watch Mode, and You

  • Use docker compose watch for live-reload in local dev
  • Use bind-mounted volumes + hot reload for fast iteration
  • Use .dockerignore + caching for minimal rebuilds
develop:
  watch:
    - path: .
      action: rebuild

The "Docker Isn't Good for Production" Crowd

It's not Docker's fault. It's yours.

You didn't add healthchecks, so Docker couldn't restart a broken service. You didn't set up multi-stage builds, so your image is 2GB of junk. You ran everything as root, so now you're scared of your own software.

Docker can be production-ready - if you treat it like a production tool.


The "Docker Is Bad for Local Dev" Crowd

Also wrong. You're probably using it wrong. Here's what helps:

  • docker compose watch = live rebuilds
  • BuildKit cache mounts = fast builds
  • Bind volumes + hot reload = native-like DX

If you're waiting 2 minutes for each build or watching logs from docker logs -f, it's a skill issue, not a Docker issue.


TL;DR: Stop Using Docker Like It's 2015

Docker isn't a toy anymore. It's a modern, battle-tested tool for development and production - but only if you stop using it like it's 2015.

Ditch the version: field. Add healthchecks. Use BuildKit. Learn caching. Use non-root users. Stop blaming the tool.

And please, for the love of whales, add a .dockerignore file.


Got an outdated Docker habit you had to unlearn? Drop it in the comments. Let's banish the 2015 container energy, together.

Cheers,

Jonas Co-Founder sliplane.io

Welcome to the container cloud

Sliplane makes it simple to deploy containers in the cloud and scale up as you grow. Try it now and get started in minutes!