I appreciate the spirit, but to shine some more light around the negativity you’re seeing in the comments, it’s a lot to ask for others to run your code on their machines. If you want folks to be running in docker, that’s oftentimes basically giving root access.

If I’m giving root access, I’d at least want for the person who wrote the code to have a thorough understanding of what the code, which once again is running as root on my home network, is doing.

The LastPass hack a few years back was enabled by a self-hoster running an outdated version of Plex on their personal machine. There is weight in choosing what software to run and support in your personal setup. The negativity you’re seeing is due to the belief that vibe coding, while able to produce something functional, is not reflective of solid, sustainable, and secure software development practices, and simply does not meet the bar for code to give root access to. It’s (probably) not personal.

virtually all home server setups run docker compose. no one is complaining about Docker, they’re complaaining about AI. The code is immaculate. Its fully tested as well. No one as looked at the code.

Also idk where you heard Docker is like giving root, thats just not correct on multiple levels. If it were a privledged container, which is unnecessary, then we could have a discussion. If you want a daemonless service, use podman. Use anythign you want, the source is there. Docker is not a requirement but is certainly not an issue in any way.

When you run a self-hosted application, do you first go through and read all the code? I don’t, I’ll tell you that. I’m going to assert that most folks don’t, and unless I hear otherwise I’ll assume you don’t read all the code for every self-hosted application you use.

No one is complaining about Docker, they’re complaining about AI Correct. Saying you “vibe-coded” something up suggests that you didn’t do it yourself, or at least was only loosely invested in it. If you didn’t put much time into it, then it’s not as vetted for folks. Running your code on someones homelab is then akin to pushing the new grads vibe-coded refactor into prod, which I think we all know is a bad idea. The mitigation for that is for the user to vet the code themselves, which we already asserted earlier doesn’t really happen in practice. So we have two options, either push the vibe-coded refactor into prod, or acknowledge that we’ve introduced an additional requirement onto the users to vet the code themselves. The docker issue was just brought up as an example of what could go bad by running poorly vetted code on a machine.

Also idk where you heard Docker is like giving root

If I’m not looking through all the code, then as a user I’ll just be following your included instructions, of which the recommended method is to fire up docker-compose. If docker-compose bind mounted mounted /, my understanding is that the container now has default write-access to the entire host - am I mistaken?

It would, but that *would only work/be possible if *you are running docker as the root user. Though people OFTEN create a docker user that runs docker as root, which is a bad practice and source of confusion. Docker is plenty safe, but I don’t even want to argue that, it’s completely irrelevant. I don’t actually care how you run it. Docker compose is by far the standard for home server applications. You can use podman with it, it’s fine. You can skip it entirely and run it directly. These are merely options provided.

Here is the install instructions for Sonarr, arguably the most famous example of something people self host. sonarr.tv/#downloads-docker

They have non-docker instructions too of course, as do I. Am I correct that a few of you are mad that I included dockerfiles and docker compose examples in the repo? Where did I go wrong?

Am I correct that a few of you are mad that I included dockerfiles and docker compose examples in the repo? Where did I go wrong?

No, we’re not upset about docker. Did you read the majority of my last comment?

Correct. Saying you “vibe-coded” something up suggests that you didn’t do it yourself, or at least was only loosely invested in it. If you didn’t put much time into it, then it’s not as vetted for folks. Running your code on someones homelab is then akin to pushing the new grads vibe-coded refactor into prod, which I think we all know is a bad idea. The mitigation for that is for the user to vet the code themselves, which we already asserted earlier doesn’t really happen in practice. So we have two options, either push the vibe-coded refactor into prod, or acknowledge that we’ve introduced an additional requirement onto the users to vet the code themselves. Both are not ideal. I’m proposing that it is that friction that you’ve introduced that folks are upset about. The docker issue was just brought up as an example of what could go bad by running poorly vetted code on a machine.

I don’t care what you do but you are placing a lot of assumptions on the word vieb coded. If you’re interested, look at the code and see for yourself, that’s why it’s open source. If you aren’t that’s fine, because nothing is for sale here.