Hacking all those things together feels empowering, like a complex construct that can be built from simple things we are already used to. This article has a very "hacky" spirit, love it!
Why not have both? A single server/service AND easy-to-install modules providing atomic functionality? Just make the install/uninstall process easy (like just downloading and optionally unpacking a modules archive into installed_modules Dir)?
On the contrary, I didn't find Syncthing setup very easy, as I don't want to be dependent on external resources when doing a sync over LAN and thus I had to setup a coordinator myself and it's a bit confusing with all these long tokens that I needed for some reason.
Because we are a big company and would like to utilize resources better.
We also want homogeneity in tech when possible (we already heavily use kubernetes, we don't want to keep docker hosts anymore).
Teams of testers need to be accounted in terms of resource quotas and RBAC.
What exactly do you see as an overkill in wanting to run short-lived containers in kubernetes rather than in docker (if we already have kubernetes and "cook" it ourselves)?
I think it would be best to illustrate the readme with a problem it tries to solve: currently I don't understand why a simple set of INSERT operations wouldn't suffice.
Also, the phrase "ingest data into Postgres" sounds wrong: it would be postgres, not your tool that would ingest data (if it could), your tool should be described as the one "putting data into Postgres".
And thus you probably have named your tool wrong...
It is not obvious what the result of this would be. What hostname will it have? How will the disk be partitioned? What packages will be installed? What timezone will be set? What keyboard layout will be set? And so on.