[gcommer]

Lots of good points about the challenges of self-hosting throughout this thread, especially maintenance, security, and time-investment.

Here's my solution to all of them:

Invest in your common infra. Docker provides stable images configured primarily with env vars. I have a docker-compose host with logging/monitoring/alerting. All service-specific files are mounted from a NAS that has backups. All network access is closed by default, but exposed via a central login proxy (tailscale would be an easier alternative, but my Beyondcorp-esque system lets non-technical family members use my services easily from anywhere by tapping a yubikey).

That's 3 pieces of infra to maintain (docker host, NAS, login proxy) but I can check all the boxes for self-hosting 15+ services. O(n) services with O(1) infra.

I regularly spin up new services in under 10 minutes, while only having to touch 3 files that I am already familiar with (docker-compose.yml, dnsconfig.js, nginx.conf). I've run stable services for years on this stack. The only painful issues have been upgrades to the docker host, docker ipv6, and hardware issues.

This is all on a recycled computer in the basement, with a cheap VPS as a stable public entrypoint.

[ziml77]

But then you're adding even more parties to trust as it's often the case that Docker images are not provided by the same people that are maintaining the project.

[gcommer]

Fair point, but I haven't hit it in practice. Tons of services are embracing docker as a first-class output. I just checked and I run exactly 2 images that are from a third party.

[sdoering]

As far as I understand 'below' the application layer there is usually a basic image (like alpine) in docker? Do these first parties maintain these as well? If not the trust chain just got longer.

I would call myself at least somewhat technically capable. But I actually never grasped docker beyond the 'I can pack an image and deploy it to AWS' stage so that I can access an internal tool I built at work over the internet.

I was not really understanding what I was doing and was more or less blindly following some tutorials on the net.

When building and deploying things to the shared hosting environment I use privately I have a better (albeit far from perfect) understanding of what I am doing while I know that I am trusting the underlying infrastructure and the people behind that.

[itsjloh]

How'd you go getting docker + IPv6 going? I spent hours trying to get docker containers to get native IPv6 IPs and eventually gave up because it was to painful.

[gcommer]

I feel for you. I also wasted a lot of very painful hours trying to get it to work. I even had it working for a while before a docker update broke it -- turns out docker-compose's ipv6 support that many people relied on for years was a "bug" that they "fixed".

Ultimately I also gave up and now have a combination of port forwarding, nat64, and 10+ socat proxies in my docker-compose file. (Specifically, intranet->container and container->intranet are ipv6; but container->container is still ipv4)

More generally, I now try to keep my docker host as stock as possible. Whenever I'm reaching for daemon.json I just catch myself, take a step back, and say "what's the stupid but easy way to get this working".

[itsjloh]

Damn, that sucks. How painful.

Honestly tempted to ditch docker-compose in favour of just a bunch of LXC/LCD containers in place. Sure, I mightn't have all the nice networking but damn each container getting internet-routable IPv6 address is just damn nice.

[maccolgan]

Why? All you have to do is add a prefix to both the docker daemon and individual networks configured by compose. I do it and it's painless, never hit a bug. Just ensure the prefixes are at least /112.

[hsn915]

Docker will not solve the problem. It's just another layer in the pile of garbage. It's just another confusing system that the user must learn and become an expert in to even get started. Totally the wrong solution.

You want something that just works without the user having to know anything.