If you've ever moved a Docker project from a Mac to a Linux server, you've probably hit this error:
Connection refused: host.docker.internal:3000
On macOS and Windows, host.docker.internal is a magic DNS name that resolves to your host machine's IP address. It's incredibly useful for connecting containers to local databases or APIs running outside of Docker.
But on Linux? It doesn't exist by default.
Umami is great. Lightweight, privacy-friendly, no cookies, no tracking drama. We use it ourselves on Hostim.dev, and we ship a one-click Umami template for anyone who wants simple, privacy-focused analytics.
But once you start relying on analytics to make actual decisions, you hit the limits pretty quickly.
n8n is a popular open-source automation tool – like Zapier, but self-hosted. Here's how to run it on your own VPS using Docker Compose, and expose it securely over HTTPS using Caddy as the ingress proxy.
If you want a broader primer, check out How to Self-Host a Docker Compose App. But you don't need to read it first – this guide is self-contained.
Most side projects start the same way.
You grab a VPS from Hetzner or DigitalOcean, install Docker, run docker compose up, and boom – you're live.
It feels cheap. It feels simple. Until it isn't.
When you talk to enough developers about how they deploy projects, a few patterns start to emerge. Some are obvious in hindsight, others caught me completely off guard.
Here are my biggest takeaways so far.
You've got a working docker-compose.yml, and now you want to put it online.
Maybe it's a SaaS side project. A personal site. A dashboard for a client. Whatever it is – you're here because you want to host a Compose app, and you don't want to spend hours fiddling with YAML, CI pipelines, or Kubernetes manifests.
Let's walk through what it really takes to host a Docker Compose project on your own. And then I'll show you what I built to make this process go away – for myself and anyone else who's tired of copy-pasting configs.