I'm doing it :)

I split it into multiple scripts that get called from one, just for my own sanity.

Once you do it for long enough it might be worth it to consider configuration management where you declare native structured resources (users, firewall rules, nginx reverse proxies, etc) rather than writing them in shell.

I use Puppet for distribution of users, firewall rules, SSH hardening + whitelisting, nginx config (rev proxy, static server, etc), Let's Encrypt certs management + renewal + distribution, PostgreSQL config, etc.

The profit from this is huge once you have say 20-30 machines instead of 2-3, user lifecycle in the team that needs to be managed, etc. But the time investment is not trivial - for a couple of machines it is not worth it.

Honestly not having to use Puppet or Ansible are among my reasons for using Docker. I do some basic stuff in cloud-init (which is already frustrating enough) to configure users, ssh, and docker and everything else is just standard Docker tooling.

> I do some basic stuff in cloud-init (which is already frustrating enough)

What do you find frustrating about cloud-init? I'm relatively new to it.

The YAML structure seems poorly thought out, the documentation is low quality, the iteration loop is tedious, etc.

> the iteration loop is tedious

I feel that about the cloud as a whole, tbf. It's incredibly painful to me.

Yeah, I mean you're kind of eating shit either way. You either have to deal with cloud friction or Linux friction, and at least cloud friction is mostly stuff like IAM where the friction is mostly about nudging you toward a better security posture. In Linux the friction is boring stuff like "every component has a different configuration file format and different expectations about where those configuration files are on disk and where it keeps its application data and how it names its command line arguments" and so on.

This isn't bad for a small team, but it becomes increasingly painful as you scale, but it's really hard to make it work smoothly for bigger teams (the sysadmin team becomes a bottleneck for everyone's deployment, deployments slow to a crawl so everyone builds these enormous, buggy releases, testing becomes a once-a-month thing instead of a continuous thing, etc). And the teams that do it well basically end up reinventing a big chunk of the cloud without any of the benefits of a standard, well-documented, widely-understood cloud platform anyway.

I feel y’all are too focused on the end product.

I deploy to pared down bare metal, but I use containerization for development, both local and otherwise, for me and contributors.

So much easier than trying to get a local machine to be set up identically to a myriad of servers running multiple projects with their idiosyncratic needs.

I like developing on my Qubes daily driver so I can easily spin up a server imitating vm, but if I’m getting your help, especially without paying you, then I want development for you to be as seamless as possible whatever your personal preferred setup.

I feel containerization helps with that.