So you planning to self-host some stuff. Great idea! But let's get some basics straight first.

Just forget about HTTP. It's unencrypted, which means that anybody over the network can sniff and look at what you are browsing. It's insecure which means that bad people can get in the middle and feed you malicious contents without your knowing.

HTTPS is encrypted and cannot be cached by intermediate proxies, and while it depends on certificates, nowadays it's easy and free to obtain them and the overall process is autmated too.

In other words: there is no need to keep using HTTP, switch over to HTTPS on all services. There is one place where HTTP still make sense, and is internally on your server between the actual service

Today Let's Encrypt, a nonprofit Certificate Authority providing TLS certificates, is a de-facto standard on the web. It's free (as in beer too), it's fully automated and it's pretty simple to use. They even provide an automation bot called certbot that do the heavy lifting for you.

You have no excuses, drop HTTP already and host everything on HTTPS.

While you could expose each service by it's own, it's a very bad idea.

First of all, that means you must enable HTTPS on per-service base, which is annoying and depends on direct HTTPS support for each service. In other words, it's a mess.

Then, you cannot easily slap SSO or any layer of authentication on top of your services. You depend on each service capability to link so your SSO, and how safe and good that integration code is, for each service. Much safer and easier to slap SSO on top of the reverse proxy and let it do it's job.

Moreover, using a reverse proxy let you hide between better names and simpler URLs, since you can rename them and provide good sub-paths or sub-domains.

Setting up a reverse proxy is not that difficult, and the added benefits will far outstrip any annoyance.

See The Reverse Proxy concept.

Today it's very common to deploy services using some kind of containerization. This has it's great advantages and i am all for it, but provided that containerization is not a panacea and not always the best solution.

Using containers has great advantages like:

• Hides complex setups behind a compose file (or whatever you use)
• Creates strong(er) barriers between services to avoid cross-hacking
• Allows for logical separation and easy upgrade paths

But at the same time i don't think its always the case to go containers:

• If your OS already provide a package for the service, it might be a better integration
• Critical services (like Authelia SSO, Reverse proxy…) should not be containerized
• Very simple services (like one binary services) do not need to be deployed with all the container complexity

So, always use your brain and evaluate if container is the way to go or not. In the following pages i will show you on a service by service case if container is good or not.

A few last notes:

• Avoid docker at all costs, use podman (open source, much better, fully compatible, even has direct docker-compose support) see Using Containers on Gentoo
• always deploy containers rootless there is 100% no reason to run root services (except your backup solution, maybe)