I'll admit it: I am a slave to convenience. The perfect Apple customer. For years, I leaned hard into managed services by U.S.-based Cloud giants like AWS, Digital Ocean, Vercel or Netlify for personal projects. It was effortless. Spin up a service, click a few buttons, done. No hardware hassles, no 3 a.m. troubleshooting.

But the world’s shifting. Geopolitical tensions are spiking, and decision-makers keep doubling down on questionable calls. More voices are shouting for EU-based cloud solutions. Time will tell whether companies like Scaleway can rise to the occasion. But it opened another, more present, question. Do I actually want to host my private services on these providers?

I’m not some enterprise juggling auto-scaling or intricate networking setups. I'm just a guy in need of some CPU, RAM and control on a machine to host my projects on.

So I'm ditching the Cloud giants. I migrated everything to rented Hetzner servers, expecting a chore. Instead, I found freedom and a new obsession. I’ve built a lean, European-based, self-hosted stack that’s mine, and it’s a hell of a lot better than the overpriced convenience I used to swallow. For anyone who's interested to know what powers my small rebellion:

Hetzner:
It's reliable, affordable, and local. I can get 5x-10x more per € spent than with Big Cloud.

Coolify:
The open-source wizard that ties it all together. I bring the servers, Coolify brings the slick management. Proxy servers, Docker setups, rolling deployments, PR-based builds — all automatic.

Netbird:
Open-Source Zero-trust networking with WireGuard VPNs. Locks down some of my private services, like my wiki server for my documentation. I also really like their UI design.

Umami:
Self-hosted, privacy-first Web Analytics service. Ditches Google Analytic's creepy tracking and replaces it with a simple and straightforward setup that does not rely on cookies and respects users data.

n8n:
Visual workflows for automation that connect everything without me drowning in scripts. I'm the first to write my own code for some small independent tasks but I can not deny the convenience n8n brings, if I want to just glue something basic together that just needs to work.

Docmost:
Self-hosted documentation server to keep my sensitive docs off SaaS servers.

BetterStack:
A monitoring SaaS for logs, uptime, and performance. It’s my last outsourced piece. My Grafana skills aren't there yet to fully replace it.

Back in my cloud-slave days, I'd have paid for all of this. Storage, compute, bandwith, all inflated by "convenience". Now, with Docker Compose and Coolify, I can spin up new isolated PostgreSQL server in just three clicks. Hetzner's flat rates mean no surprises, and I'm not subsidizing some Silicon Valley campus. Sure, self-hosting takes effort but it's empowering. I'm not just buying; I'm building.

Big Cloud’s convenience came at a price I'm no longer willing to pay for my personal projects. Data's power, and I'm keeping it close. I was seduced by simplicity but the world's too messy for that now. Self-Hosting is my rebellion, and it's damn good. Try it for your next project. You'll wonder why you ever settled.

I walked into the WeAreDevelopers Congress last week expecting the usual mix of keynotes and hallway chats. Instead, the Docker team dropped a bombshell: Docker AI, a bundle of new features that bring large language model (LLM) runtimes and a MCP gateway solution directly into Docker Desktop. The feature overview page is live at docker.com/solutions/docker-ai, and many capabilities are already shipping in the current Desktop release.

What excites me most is that Docker is treating LLM orchestration as a first-class developer experience issue rather than a bolt-on. Developer experience has always been one of my top concerns. Poorly designed microservice systems routinely ignore it. Something I’ll save for another post.

Local models can now be declared in docker-compose.yml, started with a single command, and wired to workflow tools such as n8n without resorting to third-party hacks. MCP servers can be freely added from a catalog. Because everything sits in the same Docker network, a container can talk to the gateway and the models as easily as it talks to Redis. That polish raises the bar for every other AI automation solution I touch. It also solidifies the rise of the MCP and agentic AI workflows.

For anyone who is interested in some technical details. Below is a working docker compose snippet that spins up: a basic n8n instance and a MCP gateway using the DuckDuckGo server that allows agents to search the web or fetch content from specified websites. This example uses the qwen3:0.6B-Q4_K_M model with 0.6B parameters and 4-bit quantization which should run fine on any local machine at the cost of model response quality.

name: Local-Agents
services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: always
    ports:
      - "127.0.0.1:5678:5678"
    environment:
      - N8N_RUNNERS_ENABLED=true
      - N8N_PORT=5678
      - NODE_ENV=production
    volumes:
      - n8n_data:/home/node/.n8n
      - ./local-files:/files
    models:
      qwen3:
        endpoint_var: MODEL_RUNNER_URL
        model_var: MODEL_RUNNER_MODEL

  mcp-gateway:
    image: docker/mcp-gateway:latest
    use_api_socket: true
    command:
      - --transport=sse
      - --servers=duckduckgo
      - --tools=search,fetch_content

models:
  qwen3:
    model: ai/qwen3:0.6B-Q4_K_M
    context_size: 8192
    runtime_flags:
      - --no-prefill-assistant

volumes:
  n8n_data:

The MCP server tools are exposed at http://mcp-gateway:8811/sse. Every model runner answers under the OpenAI API schema at http://model-runner.docker.internal/engines/v1 inside the docker network.

When you need local testing from the host machine, enable a TCP bridge using docker desktop enable model-runner --tcp=12434. After that, you can hook up any OpenAI-compatible client or framework at http://localhost:12434/engines/v1 or just run your naked POST requests against it. Some MCP services need extra secrets, such as API tokens, to function. You can inject them like this docker mcp secret set 'linkedin-mcp-server.linkedin_cookie=AQEDAS....'

Find more use cases here: https://github.com/docker/compose-for-agents/tree/main/crew-ai

For anyone building agentic AI systems or just curious about running powerful models on-device. This is the cleanest on-ramp I have seen so far.

In my years as an engineer, I’ve come to appreciate a truth that’s often overlooked: not everything is as trivial as it seems on the surface. One distinction that stands out is the difference between "simple" and "easy." It’s one thing to be unaware of this nuance. It’s quite another to recognize it and still push for changes, treating the two as interchangeable. That’s a risky move, and sooner or later, it’ll catch up with you.

This one feature you want to add to your product? Yeah, that might be a simple feature but that doesn't make it easy. The distinction isn’t just semantics; it’s a practical reality that can make or break your work.

Running a marathon is simple. Put one foot in front of the other until you cross the finish line. There’s no hidden complexity in the instruction, no convoluted riddle to unravel. Yet, if you've ever laced up your shoes and hit the pavement, you know the truth.

Simple isn’t easy.

It requires effort beyond merely describing the steps involved. Simplicity often disguises the hard work that might be necessary for things to even be simple in the first place. It is a triumph of effort, not a happy accident. We rarely stumble into clarity. We forge it through discipline, mistakes, and deep respect for our craft.

So the next time you talk about a feature, a process, a data pipeline, remember the marathon analogy. Simple means clarity of understanding, direction, or function. Easy implies it’s effortless, and that’s rarely the case when you’re building something worthwhile.

Confusing simple with easy leads to underestimated efforts, missed deadlines, or half-baked results. Recognizing and respecting their difference makes us better engineers, data professionals, and leaders.

For most of my life, I’ve operated like a human calculator — plugging in inputs, applying a fixed set of rules, and trusting the (hopefully) deterministic outputs. This highly analytical mindset has been my guiding compass in areas such as Software Development, Physics, Finance, and Data Analytics throughout my professional and even private life.

It would be dishonest to say this approach hasn't been successful. These disciplines are my comfort zone. Almost every problem has a law or rule I can rely on for certainty. And in that certainty lies security.

But here’s the thing: my world of logical precision leaves little mental real estate for emotions or human connection. You’re constantly flirting with burnout by trying to fit every situation into a perfectly explainable, repeatable framework.

I’d be lying if I claimed not to recognize the potential pitfalls of this way of thinking. Yet understanding something and truly internalizing it are two very different things. And, in my case, it took a single YouTube lecture to spark a small quarter-life crisis.

A few weeks ago, I revisited the concept of Discounted Cash Flow (DCF) valuations. I grasp the math, but I’ve never found a practical mental framework to estimate future cash flows or choose the right discount rates. It was a puzzle I wanted to solve purely for the sake of solving it, not for any practical gains.

My search led me to Aswath Damodaran’s lectures on company valuation. He’s a phenomenal teacher by the way. In one of the opening lectures, he explains how it would be very challenging for him to teach the concepts of company valuations to Engineers. Their number- and truth-driven minds get hung up on explaining every single detail and connection in their quest for the "absolute truth".

I perfectly understood his point intellectually. But emotionally, I didn't want to. Here was someone essentially telling me, through my screen, that he wouldn’t be able to teach me something because of the way I think about problems.

Yet I knew he was right, because the mere fact that I was watching his lecture was proving his point. I was there solely to find "the truth". A recipe I could just pull out whenever I would need it.

At the risk of sounding melodramatic, that moment led me to reassess how I approach some things in life in general.

Maybe it’s time to move beyond the hyper-analytical worldview and start embracing the intangible. So, in 2025, I’m making a deliberate investment in strengthening my softskills and communication abilities. This growth feels essential — not just as a personal evolution but also as a hedge against the rising influence of large language models (LLMs).

While I still firmly believe Software Developers aren’t disappearing anytime soon, I’d prefer to stay one compelling story (or charming smile) ahead of something like Devin.ai.

Here’s to growth beyond numbers and technology for 2025.