Differences

This shows you the differences between two versions of the page.

--- services:general [2025/02/06 10:49] – willy
+++ services:general [Unknown date] (current) – removed - external edit (Unknown date) 127.0.0.1
@@ Line 1: / Line 1: @@
-====== Self-hosting services - General toughts ======
-So you planning to self-host some stuff. Great idea! But let's get some basics straight first.
-==== HTTP vs HTTPS ====
-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 [[https://letsencrypt.org/|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.
-==== Use a reverse-proxy ====
-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 [[selfhost:nginx|The Reverse Proxy concept]].
-==== Use containers or bare-bone installation ====
-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)
-  * always deploy containers **rootless** there is 100% no reason to run root services (except your backup solution, maybe)

Willy's Wiki

User Tools

Differences