For me, everything exposed to the internet is https (that is http + Apache reverse proxy using Let’s Encrypt), and everything that is not (and I access via my tailnet) is http.

Back when I joined Lemmy (and before I understood what .ml was), I tried to contribute to the project. I suggested updating a link (possibly to docs) that was using an HTTP connection. The goal at the time was to make Lemmy approachable for normal users. As a user, I have non-secure sites blocked in my browser, so I have to manually proceed… and seeing that warning makes me not want to use a site. The devs told me that the link didn’t matter because the site was static. That was the end of my being willing to contribute, and my monetary support for the project ended as soon as I understood the dev’s beliefs and personalities.

short answer (and the safest one) is yes, use HTTPS always.

However, if and only if a service you are using is confined locally or via your privately hosted VPN (this just means not available over the public internet) you are probably OK without, unless there are other people on your local network who might be interested in snooping.

with your VPN (looks like netbird in this case) you should be OK, as the VPN handles encryption in the absense of HTTPS.

For more research checkout LetsEncrypt. its a super simple way to setup SSL (Which generally makes up the S part in HTTPS) and it’s free.

i think many of us started like you. you’ll get there, you’re just about to learn a lot of stuff before you do.

If you’re not using https, then anyone who can see the traffic in your VPN can see everything you do.

Whether that’s a problem depends. In principle, as long as access to your VPN is restricted to people you trust, then http inside it is fine. In practice, if your security isn’t perfect, and someone gets access to your VPN, then https provides a meaningful second line of defense.

My recommendation would be to never use http for anything where a breach would be really painful. It’s good that vaultwarden is on https. Beyond that, https is absolutely the best practice, but if someone getting access to your service is only a mild inconvenience, then leaving it on http is fine as long as it’s only accessible inside your VPN - the risk is relatively low, and the consequences aren’t bad.

Is this a problem or does it not matter

It’s not a problem, but it does matter. With plain HTTP traffic everything you send and receive from a given site is unencrypted, so anyone in the chain delivering your package can read what you’re doing, collect your passwords and do all kinds of shenanigans. If it’s just your local network which is secured from the public internet then it’s pretty much just you who can intercept that traffic and it’s generally fine, as you already have all the passwords and such. And if you connect to the services via VPN that takes care of ‘secured from public interenet’ -part of the equation.

HTTPS is the same traffic, but encrypted with certificates. To achieve that you’ll need to have a server certificate and then browsers can use the public part of certificate to encrypt your traffic. With docker that’s commonly achieved either with docker-proxy or external proxy like nginx. Your computer already has a bunch of certificate authorities which it trusts and they are bundled in your operating system and/or browser. Without a trusted certificate your browser throws a warning about it, but if you proceed with ‘untrusted’ certificate the traffic will still be just as strongly encrypted as it would be with a ‘known’ certificate. The catch is that anyone can create their own certificates, so there’s no guarantee if the server actually is what it claims to be. For example I could sign my own certificate for gmail.com and offer that to users and steal their passwords. That would of course be trivial to figure out as the browser wouldn’t show the “good” lock symbol on address bar, but the certificate would be technically speaking a working certificate.

Now, to get a certificate for your own services you need to either build your own certificate authority and add that to trusted list of your devices or obtain a certificate from a already known authority like letsencrypt. With letsencrypt (and other similar services) you need to provide a proof that you own a domain which you’re obtaining the certificate for, so with those you can’t get a certificate for gmail.com or any other random domain name. Letsencrypt uses ‘certbot’ tool to validate certs, other services ask for spesific DNS entry or something else for proof that the domain is actually yours. But the main part is that all the ‘commonly known’ certificate authorities work only on publicly available services and domains (a bit simplified explanation, but that’s roughly it).

But once you have the certificate you’ll need to configure something on your network to use it. Actual best practice and configuration depends on the service you’re running. If your services run only on your local network and they are never allowed to public internet you’re likely fine to run everything without HTTPS encryption, but it’s still good to understand the differences and effects between unencrypted and encrypted traffic.

If the access is only over VPN then http is fine, that’s how I access my arr setup. You can create certificates and manually upload them to radarr and other sites but it’s not necessary.

@inquanto Theoretically, when you are alone in your own network it can be ok, to go only with http. But login passwords over http are transferred without encryption.

The problem with https are valid certificates, so that clients can connect to your selfhosted services without issues.
For example, I was not able to connect with a KDE PIM program to a Nextcloud with a self signed certificate or with http only.

With step-ca there can be a solution for this problem:
https://jan.wildeboer.net/2025/07/letsencrypt-homelab-stepca/