Selfhosting voor "dummies" Tip & Tricks

[aliazzz]

Natuurlijk is over dit topic veel te vinden, maar ik wilde een minimale maar duidelijk stappenplan hebben. Bij deze dus! Ik beweer niet dat dit stappenplan "compleet" is of veilig. Self hosting via je NAS is echter zeer goedkoop, maar daardoor krijg je in ruil er overhead aan beheer en security monitoring bij.

Basis-stappenplan voor een minimale self-hosting + domeinconfiguratie

Dit stappenplan bestaat uit een aantal vaste stappen, te weten:

• Domein Configuratie
• Statisch LAN-IP
• Port-forward
• Optioneel hairpin NAT / DNS override

1: Domeinconfiguratie

• Koop of registreer een domein bij een registrar.
• Log in op het DNS-beheer voor dat domein.
• Voeg een A-record toe (of bewerk deze) en eventueel een AAAA-record, die verwijst naar het huidige WAN-IP van je router.
• Als je WAN-IP kan veranderen: stel een DDNS-service in en configureer eventueel je router (als deze dat ondersteunt) of draai een kleine client op je server om DNS automatisch bij te werken.
• Configureer in je router port forwarding: stuur inkomende verzoeken op poort 80/443 (of andere poorten, indien nodig) door naar het LAN-IP van je server.
• Als je wilt dat het domein ook intern (binnen je LAN) oplost, overweeg dan interne DNS in te stellen (bijvoorbeeld via Pi-hole of je router) of gebruik “split DNS” / DNS override zodat het domein intern naar het server-IP verwijst.

Uitleg DNS-records benamingen

• A → Adres-v4 Verwijst een domeinnaam naar een 32 bits lang IPv4-adres (bijv. 192.0.2.1).
• AAAA → Adres-v6 Verwijst een domeinnaam naar een 128 bits lang IPv6-adres (bijv. 2001:db8::1).
• CNAME → CNAME defineert een alias: Canonical Name, Kanonieke naam, kanoniek betekend de echte officiele naam van iets en dus declareeert een CNAME een verwijzing naar de bron (ofwel een alias). Ze verwijst een domeinnaam naar een andere domeinnaam.
• MX → Mail-Exchange Geeft aan welke mailserver(s) e-mail voor het domein email moeten ontvangen.
• SRV → Service-Record Specificeert servers voor bepaalde diensten (bijv. VoIP, chat), inclusief poort en prioriteit.
• TXT → Tekst-Metadata Een vrije tekst of metadata, vaak gebruikt voor verificatie (bijv. SPF, DKIM, Google-site-verificatie).

2. Geef je Self hosted server altijd een vast LAN-IP

• De interne Self hosted server mag nimmer van IP-adres wisselen, anders werken je port-forwards etc. niet meer.
• Op de router stel je voor de Self hosted server een DHCP Static lease in. Natuurlijk er zijn andere wegen mogelijk, maar dit is by-far de gemakkelijkste manier.

3. Port-forward de servicepoorten naar dat LAN-IP

• Dit is het belangrijkste. Bijvoorbeeld: Voor een standaard webopzet achter een reverse proxy:
• WAN:80 → 192.168.1.20:80
• WAN:443 → 192.168.1.20:443
• Als je iets anders wilt aanbieden (SSH, een specifieke service), forward je die poorten in plaats daarvan.
• Je router fungeert nu als poortwachter: verkeer dat je WAN-IP raakt wordt doorgestuurd naar de server.

4. Controleer NAT loopback / hairpin (intern gebruik)

• Als je wilt dat je domeinnaam ook binnen je thuisnetwerk werkt:
• Sommige routers ondersteunen NAT loopback automatisch → klaar
• Andere niet → het domein opent intern niet
• Oplossingen indien nodig:
      NAT loopback inschakelen in de router (indien beschikbaar)
      OF een lokale DNS override instellen (Synoloy DNS Server of Pi-hole, Unbound, OpenWrt, of je router als die “host overrides” ondersteunt)

Nu is jouw server bereikbaar via het internet via een domeinnaam en volledig self-hosted!

[aliazzz]

Tip: zorg altijd voor een Reverse proxy bj self hosting!
Om het beheer nog verder te vergemakelijken is het zeer aan te raden al het inkomend verkeer via een zgn. "reverse proxy" op te vangen en door te sturen naar de achterliggende self hosted dienst. Een reverse proxy is
een server die tussen clients en één of meer webservers staat. Hij onderschept alle binnenkomende verzoeken van clients, stuurt deze door naar de juiste webserver en stuurt het antwoord vervolgens terug naar de client. Dit verbetert de beveiliging, prestaties en betrouwbaarheid van de servers. Inkomend verkeer (vanuit WAN) heet "Ingress/inbound traffic" terwijl uitgaand verkeer "Egress/outbound traffic" heet.

No regret
Voordelen van een reverse proxy zijn dat "ingress" tot de reverse proxy komt en niet verder. De proxy handelt immers zelf het achterliggende verkeer af. Tevens kan de reverse proxy automatisch de certificaat afhandeling automatiseren en daarmee is de dienst altijd voorzien van een geldig certificaat. Daarnaast kan de reverse proxy ook bij een hoog beschikbaarheids scenario (High Availablity) de traffic load-balancing verzorgen.
Het mag duidelijk zijn dat een reverse proxy een "no-brainer" is, juist bij self hosting! De moeite van het inrichten van de reverse proxy staat niet in verhouding met de overhead in beheer en daaruit volgende hoofdpijn bij het overslaan hiervan.

populaire reverse proxies

Proxy - Sterke punten - Use cases

NGINX - Lichtgewicht, razendsnel, ingebouwde caching en load balancing - Websites, API’s, reverse proxy voor webapps.
NGINX Proxy manager - kant-en-klare container image van NGINX met een ingebouwde webinterface (GUI) om reverse proxies te beheren - Ideaal voor homelabs en kleine netwerken.
HAProxy- Zeer robuust, uitgebreide load balancing, health checks - Enterprise setups, high-availability clusters.
Apache mod_proxy - Klassiek, veel modules, integratie met Apache - Legacy apps, eenvoudige proxy setups.
Caddy - Automatische HTTPS (Let’s Encrypt), moderne configuratie - Homelabs, self-hosting, snelle TLS setup.
Traefik - Dynamische configuratie, Docker/Kubernetes integratie - Cloud-native, microservices, container orchestration.


In mijn homelab setup stoei ik zowel met Caddy als Traefik.

[aliazzz]

Tips om self hosting slim in te richten
Hierbij zijn er een aantal keuzes te voor self hosting bedenken, te weten:

Self hosting platform

• Docker based,
• Podman based,
• Kubernetes based

Bare metal server hosting wordt niet behandeld. Mocht je wel bare metal willen hosten, dan staat je natuurlijk geheel vrij om te doen maar wordt hier niet behandeld. 

🐳 Docker-based self hosting
Voordelen

• Grootste community en documentatie → veel tutorials en kant-en-klare images.
• Eenvoudig te gebruiken: docker run en docker-compose zijn laagdrempelig.
• Breed ondersteund door third-party tools.
• Snelle setup voor kleine projecten of homelabs.
• Draait veelal op server machine, tenzij je Docker swarm inzet

Nadelen

• Draait standaard met een daemon als root → minder veilig.
• Minder geschikt voor enterprise security policies.
• Orchestratie beperkt: Docker Swarm bestaat, maar wordt weinig gebruikt (Kubernetes is defacto standaard).

   
🦭 Podman-based self hosting
Voordelen

• Rootless containers → veiliger en beter voor multi-user omgevingen.
• CLI is vrijwel identiek aan Docker → makkelijke overstap.
• Ondersteuning van OCI container format in traditionele Docker en Pod variant → perfecte tussenstop voor Docker en Kubernetes.
• Kan containers a la Docker draaien → veel docker tutorials en kant-en-klare images
• Kan containers a la Kubernetes (pods) draaien → veiliger, schaalbaarder en kubernetes compatible
• Geen centrale daemon → kleinere attack surface.
• Goed geïntegreerd met systemd → handig voor services op Linux.
• Draait veelal op 1 machine → biedt transparante stepping stone naar Kubernetes (Enterprise schaalbare omgeving).
• Bijna volledige orchestratie → self-healing, rolling updates zonder downtime

Nadelen

• Kleinere community dan Docker → minder kant-en-klare voorbeelden voor Pods.
• Minder bekend dan Docker, dus soms meer uitzoekwerk maar wint rap aan populariteit

   
☸️ Kubernetes-based self hosting
Voordelen

• Volledige orchestratie: world scalable, self-healing, rolling updates without downtime, software defined infra, software defined networking
• Ideaal voor microservices en complexe setups.
• Extreem flexibel en betrouwbaar: load balancing, secrets, network policies, network shares, service oriented, atomic updates, AI hulp bij wijzigingen
• Grote community en ecosystem (Helm, Operators, CRDs).
Nadelen

• Complex → steile leercurve, zeker voor een homelab.
• Resource-intensief → meer CPU/RAM nodig dan Docker/Podman.
• Overkill voor kleine setups (1–2 apps).
• Configuratie en beheer kost meer tijd mits goede tooling ontbreekt

Key Takeaways
Als je de tijd hebt (en wellicht nog geen grote ervaring met Containers in het algemeen), sla Docker over en stop je tijd in het leren en begrijpen van Podman! Dit omdat Podman veiliger is voor self hosting, backward compatible is met Docker, maar tegelijkertijd ook forward compatible is met Kubernetes. daarmee sla je dus meerder vliegen in 1 klap. De Podman command line interface (CLI) is idem maar uitgebreider dan die van Docker. Alle bekende docker commando's zitten dus in de CLI van podman (handig!) maar de Podman CLI is uitgebreider met features die niet in Docker bestaan.

Ook is Podman "by-design" veiliger dan Docker omdat deze daemonless draait. Er is bij Podman dus geen centrale achtergrondservice actief om containers of processen te beheren. Elke container/pod draait rootless tenzij ander gespecificeerd door de gebruiker. Elke actie wordt direct uitgevoerd door het commando zelf, zonder dat er een aparte “manager” continu actief is in tegenstelling bij Docker. Een zeer grote "attack vector" is daarmee weggenomen en verhoogt de veiligheid van self-hosting. Podman bezit een manifest export functie waardoor Pods "eenvoudig" naar een selfhosted kubernetes cluster gemigreerd kunnen worden.

Door de voordelen van Podman biedt deze "de gulden middenweg" voor self-hosting waarbij het groeipad naar Kubernetes open ligt. Mocht jouw NAS geen Podman aanbieden, no worry, gewoon starten met Docker self hosting, maar let hierbij op dat dit gaandeweg complexer zal worden dan self-hosting via Podman naarmate jouw selfhosting behoeften groeien. Een slimmere overweging is om Podman op een NUC of Raspberry pi te draaien en van daaruit de self hosting te regelen! [/list]

[aliazzz]

Pod vs Container Primer
Het verschil tussen een pod en een container is fundamenteel, helaas worden deze begrippen vaak door elkaar gehaald. Een Container is een OCI (open Container Initiative) compatible formaat. Zowel Pods als reguliere containers gebruiken dit als gemeenschappelijke basis.



🐳 Container
Definitie: Een container is een geïsoleerde omgeving waarin een applicatie draait, inclusief alle benodigde afhankelijkheden (libraries, runtime, configuratie).
Kenmerken:

• Draait één proces of dienst (bijv. een webserver).
• Heeft eigen bestandssysteem, netwerk en resources.
• Lichtgewicht alternatief voor een virtuele machine.

Voorbeeld: Een Nginx‑container die alleen een webserver uitvoert.

🦭 Pod
Definitie: Een pod is een groep van één of meerdere containers die samen draaien en resources delen binnen deze afgesloten Pod omgeving. De pod is een "schil" om de containers heen.
Kenmerken:

• Containers in een pod delen netwerk (IP‑adres, poorten) en vaak opslag.
• Wordt gebruikt om meerdere containers die samen één applicatie vormen, te bundelen.
• In Kubernetes en Podman wordt automatisch een infra‑container gestart om de pod‑omgeving vast te houden.

Voorbeeld: Een pod met een Nginx‑container (webserver) én een sidecar‑container (logging of proxy).

Wanneer gebruik je Pods?
Gebruik altijd pods wanneer je meerdere containers dezelfde netwerkruimte wilt laten delen (bijvoorbeeld een webapplicatie met een sidecar).

Wanneer gebruik je een afzonderlijke Container?
Gebruik afzonderlijke containers wanneer je slechts één dienst nodig hebt zonder externe afhankelijkheden.

Sidecars
Een niet onbelangrijk stuk gereedschap zijn zogenaamde Sidecars (zijspan). Sidecars zijn containers die naast de hoofdcontainer(s) draaien en ondersteunende taken uitvoeren. Ze delen dezelfde netwerk- en opslagruimte en voegt ondersteunende functies toe, zoals logging, monitoring, beveiliging of proxy‑functionaliteit, zonder dat je de hoofdapplicatie(s) hoeft aan te passen. Voorbeelden van Sidecars zijn de Proxy-, Log- en Ambassador-sidecars.

Samengevat
Een container is de bouwsteen (één dienst), terwijl een pod een verzameling van containers is die samenwerken en dezelfde omgeving delen. Het combineren van containers in combinatie met sidecars in een pod maakt beheer en herbruikbaarheid aanzienlijk gemakkelijker. Het gebruik van Sidecars is niet verplicht en kan per situatie verschillen.

Tips

• Als je meer dan 1 container "aan elkaar knoopt" in Docker, overweeg dan mits mogelijk over te stappen naar Podman doodat dit vele malen veiliger te realiseren is met Podman.
• Run containers niet als root → verklein het aanvalsvlak
• Update host en Docker regelmatig, stel podman in dat deze automatisch images update→ bescherm tegen bekende kwetsbaarheden
• Geen gevoelige data in images: stop geen wachtwoorden, API‑keys of certificaten in je Dockerfile of (self built) image