> a mishmash of vibe coded stuff you don’t understand.
No, there is a difference between "I wrote this code" and "I understand this code". You don't need to write all the code in a project to understand it. Otherwise writing software in a team would not be a viable undertaking.
I've been amazed at the resilience and convenience of a handful of shell scripts calling "docker" commands on Debian for my server at home.
- Figured I'd need to screw with Systemd at some point. Nope, whatever Docker's doing restarts my services on a system restart, and auto-restarts if they break. I haven't had to lift a finger for any of that. My services are always just there, unless something really goes horribly wrong.
- Which directories I need to backup is documented in the shell scripts themselves. Very clear and easy.
- Moving those directories and my shell scripts to another server, potentially with a different distro, would be trivial. Rsync two directories (I've put all the directories I mount in the docker images, under a single directory for convenience), shell in, run the scripts. Writing a meta-script to run all of them would be easy. On a VPS I could have everything that mattered on a network drive, and that'd make it even simpler. Mount network drive, run script(s).
- Version updates are easy. I can switch between "use the latest" and "use this specific version until I say otherwise" at will. Rollbacks are trivial. If the services were public-facing I could automate a lot of this with maybe an hour of effort.
- Port mapping's covered by Docker. If these were public-facing it'd be pretty easy to add one extra container for SSL certs and termination (probably Caddy, because I'm lazy, though historically my answer for this at paying gigs has been haproxy). Like, truly, the degree to which I can interact with and configure this system entirely by using portable-everywhere docker commands & config is very high.
I've been running servers (sometimes private, sometimes public) at home since like 2000, and this is easily my favorite approach I've used so far.
I've used stuff like Dokku at work. I dunno—it's another thing that can and does break. If you're just self-hosting a few services and aren't trying to coordinate the work of several developers, IMO it's simpler and not-slower to just use Docker directly.
I just mean in the usual way that another component in the stack is another way for things to go wrong, another thing to update that might mean api changes that require further effort, and so on.
It was plenty solid, but I’ve definitely seen it fall victim to operator error :-) I’d certainly consider using it again to support a team, under the right circumstances.
When a new ff version releases it breaks custom themes, and then you need to download them again, because they roll out their own fixes, so this does that automatically for you
Not really because then projects started needing multiple containers and orchestration, and might be fussy about the order the different services come up.
