No, unfortunately, open-sourcing it has been on my to-do list for an embarrassingly long time.

But, building one is easier than it sounds! Think of the problem in two parts. First, find a distro used by multiple providers (we're on CentOS) and craft one script that uses each provider's API to spin up a clean machine.

Once you have that done, it's a matter of understanding your own build process, writing a script that you'll pass into each instance on creation that will fetch your source control, install libraries, and put all the pieces together.

Lots of if/else, lots of curl, lots of yum, lots of jq, but all of it is really straightforward.

Also if your providers + OS support cloud-init, then you can express a fleet of instances which run this sort of script at boot time in something like Terraform pretty easily. Switching clouds becomes "uh... what does <provider> call their <size> instance again?"

Alternatively, pre-baking cloud images that have already run such a script and are ready to boot becomes pretty easy with a tool like Packer.

Though, as the underlying OS changes, you'll need something to validate your scripts' functionality against, and a tool that's a little more declarative might make them less fragile to those changes.

I started using this model in '15 and it's not fragile. At all. The less I'm relying on outside frameworks, the better I sleep at night.

Certainly understandable -- I'd prefer to keep things simple and just have some kind of validation in place rather than rely on an abstraction if I can get away with it.

Having maintained various automation over the course of the past decade and a half, I can say things do change around. Over the course of only a few years though, obviously you can stick to some LTS release of whatever you're using and be pretty confident that e.g. "some-package" does not get renamed to "some-package-version" or split into "some-core" and "some-utils", or have a package get upgraded to a version with some less-than-backward-compatible configuration options, etc.

Is this a cookie cutter stack or do you have different models? Be curious to hear more about your application stack.

There's nothing special about our stack. We have four different instance types (static, api, db, proxy), and we rely on a lot of the usual suspects: Apache, Tomcat, MySQL, Varnish, and HAProxy.