I like that it's a bash script only - there was this bash-based Docker reimplementation, so maybe these two fit well together?

But come on, how many levels of abstraction do we want to pile onto another? Namespaces, containers, Docker files, compose, swarm, k8s, helm, cloudfront, terraform, auth servers/OAuth, ad-hoc "REST" auth kludges, dynamic languages, distro- and lang package managers/ecosystems, blabla - because IT'S SO MUCH EASIER LOL. All of which are one-of-a kind snowflake solutions to self-inflicted problems on top of an O/S that is already highly portable, for good reasons. We're just kicking the can down the road, or alternatively, blow up cyclical/generational bubbles to trap freshmen and idiots. Cloud tooling seems like a zero-sum game at this point, wasting talent for three "cloud providers" to make loads of cash. The whole thing is antithetical to humanist, local-first, site autonomy principles in the name of growth for very few.

https://github.com/p8952/bocker? Last commit was 7 years ago, and even then this was more of an experiment / PoC - I really don't think this was ever meant as a viable replacement. (IMHO Bash is a horrible language as well.)

I agree with your sentiment on container/cloud tooling. It doesn't need to be this complicated, the needs of the 1% are dictating the experience for the 99%. However Docker (the basic CLI interface) and Dockerfile (the format) did a lot to bring containers to the mainstream, and you can still get quite a lot out of it by just sticking to the basics. For self-hosting simple services, or even just deploying your application, on plain old VPS/box-under-the-desk, it's still just plain brilliant; at least compared to loading files into a shotgun and aiming in the general direction of /opt, /usr/local, /home/app, /etc.