Yesterday I decided to start "officially" selfhosting. With almost no experience with Docker, I struggled for eight hours straight, but I finally have it working.

Currently, the two tools I am selfhosting with Docker Compose are LibreTranslate and spotDL. I'm only accessing them over the local network using a direct IP:PORT, so there's no domain name. I don't want to use a custom DNS, since it is fingerprintable online, so I want to keep it the same as my VPN.

With that said, I want to add encryption to the connections. I was able to generate my own self signed certificates with this command:

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ./certs/key.key -out ./certs/cert.crt

spotDL was easy to setup with these self signed certs, since it has command flags for --enable-tls, --key-file, and --cert-file. LibreTranslate has an environment variable for - LT_SSL=true, however it gives the following error:

libretranslate  | (URLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1006)')),)

That led me to this issue which is 2 and a half years old. LibreTranslate doesn't have a way to specify certificates that I know of.

I tried using Nginx Proxy Manager to create a reverse proxy, but I couldn't quite figure it out. (I also didn't understand Docker Compose at the time. I had a few hours to go before I did) NPM also seems to want Let's Encrypt certificates which can't be given without a DNS record. I tried manually providing certificates in the config file, but I don't quite understand NPM enough to be able to set it up properly on my own.

My requirements are:

• No changing the DNS from my VPN's default
• No port forwarding, everything should be accessed by the local network only
• No email required (ability to use a fake email without risk is fine)
• Only free and open source software
• Modern security standards where available

I also would like help adding the self signed certificates as a permanent exception in Brave browser, if possible.

This question has been answered. Please stop trying to repeat information that has already been said many times before. Everything in this thread is in good faith, I am here to learn, so I will make mistakes. Furthermore, if you want to contribute something new, please read the entire post to avoid misunderstanding the purpose of this post.

Selfhosting is useful when you either need a lot of storage or a lot of processing power. For example, Kiwix is useful to selfhost on a server because a lot of its content can take up terabytes of storage, which a phone may not have. LLMs are also useful to selfhost because they require a degree of processing power that, again, a phone may not have.

In both cases, there is also a need for perpetual access. If you simply hosted an LLM on your home computer, it wouldn't be very useful to access from your phone since your computer won't be running all the time. So, a separate always-on server is needed.

However, there are some selfhosted software that I don't see a use for. For example, Immich. Immich requires to be run on a server to function, but a lot of (or even all) of its functions are things that could reasonably done entirely on-device. Aves combined with some automatic backup solution such as Nextcloud gets (from what I can tell) most of the functionality Immich offers. Obviously, some features like AI image tagging are missing, but you get the point. AI image tagging is also something that could be run on-device as well, since it's mostly lightweight (iPhones are capable of it). Having a setup like that also comes with the benefit of automatic backups being completely optional, rather than required.

There's no reasonable need for extra storage or extra processing power needed for that use case, from what I can tell. (Disclaimer: I haven't actually used Immich before, so this is speculation. I apologize if I'm missing something obvious) There's a lot of other selfhosted tools like spotDL which have a selfhosted web UI, but no GUI that can be installed outside of a web browser.

I guess my question is why there are so many selfhosted tools that unnecessarily require being run on a separate device. I do understand the legitimate use cases some of them have, but others seem better off on-device airgapped. This especially became an issue trying to find a notes app for Android that requires no account and runs fully locally, or an RSS reader that loads from the device itself. I found Joplin and Feeder or Read You as the software for each of those. I don't like "server-based" selfhosting for things that could be done from the device itself.

I'm sorry if this turned into a rant. If someone could help me understand, I would appreciate that very much.

Cheers!

Edit: The comparison here isn't between selfhosting and using a cloud provider. The comparison here is between selfhosting on a server and running explicitly on-device (besides where extra storage or processing power is required)

Answer

So that nobody has to dig through the comments for answers, this is what I've learned: In the case of Immich, its purpose isn't designed to be a photo gallery. It's designed to be a more polished backup solution, designed explicitly for photos and not general files. While Nextcloud could be used to backup photos, it's not as focused on photos as Immich, and so it isn't as nice to use for that purpose. Immich also allows you to share photos with a link, rather than relying on a cloud provider to do that for you. There's also another benefit to selfhosting that I hadn't entirely realized, which is availability across devices. Some things like an eBook library may not take up much space, but it's convenient to not have to sync manually (or automatically) across devices, and instead access it from a central server. That same logic is true for RSS readers as well, since it's inconvenient to manually add and sync feeds across devices. Syncing across devices can be done with something like Syncthing in some cases, but not all, and so that's where selfhosting can be useful.