A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.
No low-effort posts. This is subjective and will largely be determined by the community member reports.
Resources:
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
For inside the lan/lab, I have my pem chain looks like:
cold storage root-ca -> offline vault qubes VM ca -> pfsense ca -> freeipa ca
I use letsencrypt for externally facing services.
Its a little bit more effort than getting things just workin' but its worth the whole lotta security you get in return. Plus it feels nice looking at a shiny green lock.
My router has Caddy to reverse proxy all http sites which uses a certificate it gets from let's encrypt.
I have my Firefox configured to force HTTPS, so it's rather inconvenient to work with any non-HTTPS sites.
Because of that I decided to make my own CA. But since I'm running in Kubernetes and using cert-manager for certs, this was really easy. Add a resource for a self-singed issuer, issue a CA cert, then create an issuer based on that CA cert. 3 Kubernetes resources total: https://cert-manager.io/docs/configuration/ca/ and finally import the CA cert on your various devices.
However this can also be done using LetsEncrypt, with the DNS01 challenge. That way you don't need to expose anything to the Internet, and you don't need to import a CA on all of your devices. Any cert you issue will however appear in certificate transparency logs. So if you don't want anyone to know that you are running a Sonarr instance, you shouldn't issue a certificate with that in it's name. A way around that is a wildcard cert. Which you can then apply to all your subservices without exposing the individual service in logs. The wildcard will still be visible in the logs though...
I had a Let's Encrypt for an internal domain for a while. It was a wildcard subdomain of one of my external domains. *.x.y.com I created it by setting up a temp webserver and creating it from there. I ran into internal issues because I also had hairpinning for some services and not others.
Alternatively, you could do your own CA with something like EasyCA. You'd have to add the CA cert to all devices, but once you do, you have full control to create any certs you want.
I do DNS challenges with let's encrypt for either host fqnds (for my kubes cluster) or wildcard for the few other services.
The trick is to do a subdomain off of a domain that you own (e.g. thing.lan.mydomain.com) this way, you can scope the DNS to only *.lan.mydomain.com if you're conscious about scoped api security.
Using let's encrypt is nice because you can have a valid ssl chain that android, iOS, windows, and Linux all trust with their default trusts without having to do something with a custom CA (ask me how awful that process can be).
Wildcard is actually good these days because you don’t have to set up DNS entries for your hostnames.
It’s not security, just obscurity - but in the age of crawlers, it’s helpful.
Also, you can use it internally for services on LAN and because LetsEncrypt is a CA everyone trusts, you don’t need to register a local CA (like a FreeIPA instance) with all your devices- which sometimes isn’t possible.
EDIT: you can also use DNS01 challenges and instead of proving yourself by serving up a challenge response from a server, you prove ownership by adding a DNS TXT entry with the response. It is safer, from a security perspective, to use one cert per service.
it's not security, just obscurity
IIRC for my setup it's a bit of both. My DNS API key is scoped to only handle the specific subdomain updates instead of my entire DNS account.
I still use a wildcard for that subdomain for non-kubernetes systems, but the cert plugins for kubes is excellent at handling a LE cert per lan fqdn.
You don't need to register a local CA
This was my biggest reason to move to Let's Encrypt. I have a Hashicorp Vault instance in my homelab for secrets and I tried using it for an internal CA (like how the lab at work is set up), but trying to get on every device and add the full Vault chain to each individual system's trust store was massive pain in the ass.
That sounds cool and kind of makes sense. I’m going to go learn more about this.
Https is pretty trivial to deploy so I would personally set it up
You can use DNS01 for services not accessible from the outside. I use a caddy reverse proxy, with a wildcard cert for *.mydomain.com. caddy handles that for me automagically. Needed? Maybe not, but it's a whole lot prettier, and I learned new things about certs and caddy :)
I use this tutorial to setup external only and internal only URLs both with SSL
as far as I know, there is no way to put a valid certificate like let's encrypt for a service that is not accessible from the net
There definitely is. All of my local services run on a wildcard cert that I got from a DNS challenge with Let's Encrypt. As long as the reverse proxy can access whatever source is issuing the certificate, and as long as the client browser can access public certificate ledgers and has DNS info about your services, things will work just fine locally.
I recommend Netbird to give access to services to your family members, for access control and for the DNS server it provides. It also gives you the bonus of accessing your services remotely.
Feel free to ask if you have any questions.
Just do not use wildcard, very bad security practice. Getting individual cert for each service is easy these days.
Huh? Why?
for start private keys should never leave the system which uses them. Wildcards are even worse, as if one host got compromised, all others can be spoofed.
Because a stolen cert can do a lot more damage
It is all about least privilege
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:
| Fewer Letters | More Letters |
|---|---|
| CA | (SSL) Certificate Authority |
| DNS | Domain Name Service/System |
| HTTP | Hypertext Transfer Protocol, the Web |
| SSL | Secure Sockets Layer, for transparent encryption |
| nginx | Popular HTTP server |
4 acronyms in this thread; the most compressed thread commented on today has 16 acronyms.
[Thread #176 for this comm, first seen 16th Mar 2026, 23:00] [FAQ] [Full list] [Contact] [Source code]
Look into DNS-01 challenge where instead of exposing 80/443, you obtain a cert by creating a TXT record for your domain. This requires your ACME client to support talking to your DNS provider's API. For certbot they're installable via plugins, for lego-acme many providers are included.
This is what i do. Have certbot running every night, and it'll auto skip if it is too soon to renew. If renew is successful then it'll deploy. Pretty much set and forget it.
Once you accept the certificate it being not blessed isn’t much of an issue. And just turning it on should just generate a self signed certificate on anything not a piece of shit.
Let's encrypt doesn't have to be accessible from the web, it accesses the web itself. It's a subtly difference i guess, but you don't need port forwarding or anything. Of course if your jellyfin/immich service is completely blocked from going out on the internet then it still won't work.
as far as I know, there is no way to put a valid certificate like let’s encrypt for a service that is not accessible from the net
I don't think that's true. But Let's encrypt does need to verify the domain name. If it's just a domain you made up in your LAN that is an issue yes. But I have no experience with that though.
You could use self-signed certificates, they are free. but you would need to add custom trusted CA to all the user devices manually. I've never done this myself so no clue how troublesome this really is.
What I do is have a reverse proxy that requests a wildcard certificate (e.g '*.example.com') with Let's encrypt. And then route all my services through the reverse proxy with subdomains. You can get free domains with duckdns.org or others.
When I went through the trouble of doing that, I got nginx reverse proxy set up and then got a Let's Encrypt for my internal local addressing scheme through Let's Encrypt.
It was kind of intimidating to set up, but it worked flawlessly.
@gblues If you use something like yggdrasil, you don't need to bother w/ ssl certs. Just make sure your services are listening on the yggdrasil-specific IPv6 port only, and whenever you connect to one over plain http:// you're guaranteed to have an encrypted, verified connection.