Skip to content

Comment on Selfhosting on Localhostparent

Comments

Putting something in a transient docker container and then bending over backwards to enable file persistence is just... wrong.

Do you mean declaring the volumes? What's so hard about that? There's a massive benefit when everything is homogenous. I can look at a docker-compose.yml file and instantly know where all the important data is. I can also copy volumes to a new host with a one-liner:

    sudo docker run \
        --rm \
        --log-driver none \
        --volume  myservice_data:/data \
        alpine \
        tar -cf - -C /data . \
            | ssh -o "StrictHostKeyChecking no" user@host.example.com \
                'sudo docker run --rm -i \
                    -v myservice_data:/data \
                    alpine tar -C /data -xpvf -'
For development, I self host Portainer, Caddy, Authelia, Cloudflare Tunnel, Gitea, Drone, MinIO, Nexus, Bookstack, Nextcloud, and ArchiveBox. I barely think about any of them. I pin to a major version and schedule nightly updates using SystemD. Everything is templated, so after I set up a new container it's as simple as:
    systemctl enable --now update-container@gitea.timer
It's a very pragmatic solution if your needs are satisfied with vertical scaling because everything can go into a single VM that's plugged in to a homogenous VM backup system. The only thing that's a little bit complex about mine is that I run MinIO in a separate VM that doesn't get backed up because I use it as cache storage for APT, Docker Hub, NPM, etc. proxies in Nexus.

Docker can be frustrating while you're learning it, but everything's like that and once you get proficient with it you'll never want to go back to the old way of doing things. Docker is the packaging format that won (for servers) IMO.

I actually waited far too long to learn Docker. Turns out that in general it's been far easier to work with than the "traditional" self-hosting methods that I used to go with.

It also forces you to keep a clean system, app logs are easy to find and consume nearly any way you want, and if a container from one developer isn't fitting your needs, it's usually super easy to drop in someone else's different container implementation of the same app with one config change (the repo name).

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.