Developer Portfolio

For a long time, Docker was one of those things that kept popping up without ever really sticking. I saw it in job listings, in articles I read, in GitHub projects I scrolled through. Always there in the background, but rarely something I consciously spent time on. Still, it showed up often enough to make me wonder: am I missing something here?

At the time, I was mainly working with WordPress. Docker kept showing up as the default approach for local environments. I started to learn Docker not because I needed to fix something, but because I wanted to understand what adopting it would actually change in my day-to-day work.

What Docker means to me

Once I actually started digging into it, I realized Docker approaches things in a fundamentally different way compared to traditional setups. With Docker, you run applications in containers: isolated environments that include everything an application needs to run. No heavy virtual machines, but small, clearly defined environments that you can start, stop, and throw away whenever you want.

For me, the value wasn’t so much that it worked, but how explicit everything became. Things that were implicitly present on my system now had to be defined consciously. That brought clarity and made my setup much easier to understand — especially for my future self.

WordPress as a first playground

WordPress became my first real playground for Docker, not because I had to use it, but because it was familiar territory. I knew WordPress inside out, which meant I could focus entirely on what Docker added to the equation. What changes when PHP, the database, and the web server are no longer “just there” on your machine, but instead live together inside containers?

That experiment mainly taught me how nice it is when an environment is completely detached from your system. I didn’t have to install or tweak anything locally, yet everything behaved exactly as expected. At first it felt a bit clunky, but it quickly started to make sense.

From experiment to standard tooling

After that first experiment, I started using Docker more and more, even outside of WordPress. For self-hosted applications, tools I wanted to try out, small services I needed temporarily. Over and over again, the same benefit came back: I could spin something up quickly, play with it, and just as easily remove it again.

Docker slowly shifted from “something I wanted to understand” to a core part of how I work. Not because it solves everything, but because it gives me the freedom to experiment without long-term consequences.

Why working with Docker feels so comfortable

What Docker gives me most of all is peace of mind. Every application lives in its own world, without interfering with other projects. I no longer have to think about conflicting versions or forgotten configuration changes.

On top of that, Docker behaves the same everywhere. Whether I’m working locally or running something on a server, the environment is predictable. That removes a lot of uncertainty and lets me work faster, simply because I’m not constantly second-guessing whether something works “by accident”.

Maybe the biggest shift is that Docker makes setups disposable. Because everything is defined in configuration, I’m more willing to rebuild things instead of clinging to them. That changes how you look at infrastructure altogether.

Not a dogma, but an invitation

Docker isn’t a goal in itself for me, and it’s certainly not mandatory. For simple projects, I sometimes consciously skip it. But whenever I want to experiment, combine multiple tools, or explore a new stack, I almost automatically reach for Docker.

If you don’t know Docker yet, I’d like to invite you to give it a try. Not because you “should”, but because there’s a good chance it adds something to your work, hobbies, or projects. Start small, with something you already know. Chances are you’ll quickly see why Docker keeps showing up — and why it stuck with me.