Yeah. I’m seeing a lot a it in this thread tbh. People are stylizing themselves to be IT admins or cybersec people rather than just hobbyists. Of course, maybe they do do it professionally as well, but I’m seeing an assumption from some people in this thread that its dangerous to self host even if you don’t expose anything, or they are assuming that self hosting implies exposing stuff to the internet.

Tailscale in to you machine, and then be done with it, and otherwise only have access to it via local network or VPN.

Now, about actually keeping the services secure, further than just having them on a private subnet and then not really worrying about them. To be explicit, this is referring to fully/partially exposed setups (like VPN access to a significant number of people).

There are two big problems IMO: Default credentials, and a lack of automatic updates.

Default credentials are pretty easy to handle. Docker compose yaml files will put the credentials right there. Just read them and change them. It should be noted that you still should be doing this, even if you are using gui based deployment

This is where docker has really held the community back, in my opinion. It lacks automatic updates. There do exist services like watchtower to automatically update containers, but things like databases or config file schema don’t get migrated to the next version, which means the next version can break things, and there is no guarantee between of stability between two versions.

This means that most users, after they use the docker-compose method recommended by software, are manually, every required to every so often, log in, and run docker compose pull and up to update. Sometimes they forget. Combine this with shodan/zoomeye (internet connected search engines), you will find plenty of people who forgot, becuase docker punches stuff through firewalls as well.

GUI’s don’t really make it easy to follow this promise, as well. Docker GUI’s are nice, but now you have users who don’t realize that Docker apps don’t update, but that they probably should be doing that. Same issue with Yunohost (which doesn’t use docker, which I just learned today. Interesting).

I really like Kubernetes because it lets me, do automatic upgrades (within limits), of services. But this comes at an extreme complexity cost. I have to deploy another software on top of Kubernetes to automatically upgrade the applications. And then another to automatically do some of the database migrations. And no GUI would really free me from this complexity, because you end up having to have such an understanding of the system, that requiring a pretty interface doesn’t really save you.

Another commenter said:

20 years ago we were doing what we could manually, and learning the hard way. The tools have improved and by now do most of the heavy lifting for us. And better tools will come along to make things even easier/better. That’s just the way it works.

And I agree with them, but I think things kinda stalled with Docker, as it’s limitations have created barriers to making things easier further. The tools that try to make things “easier” on top of docker, basically haven’t really done their job, because they haven’t offered auto updates, or reverse proxies, or abstracted away the knowledge required to write YAML files.

Share your project. Then you’ll hear my thoughts on it. Although without even looking at it, my opinion is that if you have based it on docker, and that you have decided to simply run docker-compose on YAML files under the hood, you’ve kinda already fucked up, because you haven’t actually abstracted away the knowledge needed to use Docker, you’ve just hidden it from the user. But I don’t know what you’re doing.

You service should have:

• A lack of static default credentials. The best way is to autogenerate them.
  • You can also force users to set their own, but this is less secure than machine generated imo
• Auto updates: I don’t think docker-compose is going to be enough.

Further afterthoughts:

Simple in implementation is not the same thing as simple in usage. Simple in implementation means easy to troubleshoot as well, as there will be less moving parts when something goes wrong.

I think operating tech isn’t really that hard, but I think there is a “fear” of technology, where whenever anyone sees a command line, or even just some prompt they haven’t seen before, they panic and throw a fit.

EDIT and a few thoughts:

adding further thoughts to my second afterthought, I can provide an example: I installed an adblocker for my mom (ublock origin). It blocked a link shortening site. My mom panicked, calling me over, even though the option to temporarily unblock the site was right there, clear as day.

I think that GUI projects overestimate the skill of normal users, while underestimating the skill of those who actually use them. I know people who use a GUI for stuff like this because it’s “easier”, but when something under the hood breaks, they are able to go in and fix it in 5 minutes, whereas an actual beginner could spend a two weeks on it with no progress.

I think a good option is to abstract away configuration with something akin to nix-gui. It’s important to note that this doesn’t actually make things less “complex” or “easier” for users. All the configs, and dials they will have to learn and understand are still there. But for some reason, whenever people see “code” they panic and run away. But when it’s a textbox in a form or a switch they will happily figure everything out. And then when you eventually hit them with the “HAHA you’ve actually been using this tool that you would have otherwise ran away from all along”, they will be chill because they recognize all the dials to be the same, just presented in a different format.

Another afterthought: If you are hosting something for multiple users, you should make sure their passwords are secure somehow. Either generate and give them passwords/passphrases, or something like Authentik and single sign on where you can enforce strong passwords. Don’t let your users just set any password they want.