I feel the same way. I've invented a config management system which executes an environment-specific shell script based on some metadata about the instance it's

I feel the same way. I've invented a config management system which executes an environment-specific shell script based on some metadata about the instance it's running on. Most of these config scripts are <50 lines and contain no logic, just "copy this config file, mount this volume, grab this secret, restart this service". Works really well for our limited use-case. We used to use chef-solo and keep cookbooks in a separate repo, which was fetched over git by instances at boot time. Now we have developers in control of bake and boot-time scripts, and since "it's just bash" and there's barely any indirection / meta programming, people generally just get it, and it works. Note that this is using an "immutable-ish infrastructure" approach. Chef worked OK before we went immutable, but we'd have problems where the instance would get into a bad state because someone "fixed" something and the next chef run wouldn't apply cleanly. Taking away ssh access would be nice, but we don't have all the log analysis / system insight stuff in place to make that a reality just yet. If we had a more complex use-case, I'd totally use chef again. If our needs expand, I wouldn't expand our little bash "system", but replace it with chef or chef-solo.