homelab
Blogdeployments automatiseren in mijn homelab
Hoe ik deze Astro-blog laat bouwen en publiceren via een kleine self-hosted deploymentworkflow.
Ik wilde dat deze blog niet langer aanvoelde als een lokale map die toevallig kon builden. De eerste nuttige stap was een deploymentworkflow: de source pushen, de Astro-site in een gecontroleerde job bouwen en alleen de gegenereerde statische bestanden publiceren naar de webhost.
De opzet blijft bewust klein. Forgejo stuurt de workflow aan, een runner doet de build en Nginx serveert de uiteindelijke bestanden. De rest van het homelab levert de infrastructuur errond, maar de publieke kant van de deployment blijft eenvoudig.
Waarom ik deze pipeline wilde
Manueel deployen is prima voor experimenten, maar het schaalt slecht zodra een site een echt project wordt. Ik wilde een herhaalbaar pad van repositorywijziging naar een verse statische build.
Dat geeft duidelijke grenzen:
- de repository blijft de bron van waarheid,
- de buildomgeving beheert de tooling,
- de webhost serveert alleen statische output,
- deployment secrets blijven buiten de repository,
- en elke release volgt dezelfde stappen.
De buildomgeving
De workflow draait in een Node-omgeving die past bij de projectvereisten. Die installeert dependencies, bouwt de site en controleert of de gegenereerde output bestaat voordat er iets gepubliceerd wordt.
Die scheiding vind ik nuttig. De host die de site serveert, heeft geen volledige source tree, package manager state of development tooling nodig. Die heeft alleen het resultaat van de build nodig.
De statische site publiceren
De deployment publiceert de buildoutput in plaats van de projectsource. Verwijderde pagina’s en hernoemde assets moeten ook uit de remote kopie verdwijnen, dus de syncstap houdt de gepubliceerde map gelijk met de huidige build.
De gevoelige onderdelen van dat proces zitten in Forgejo secrets en deploymentinstellingen. Hostnames, credentials, poorten en paden horen niet in de tekst of in de repository.
Homelabcontext
Dit past bij hoe ik het homelab wil opbouwen: elke service heeft een afgebakende taak. Forgejo beheert de projectautomatisering, de runner bouwt de site en Nginx serveert statische bestanden. Proxmox geeft mij de ruimte om die verantwoordelijkheden te scheiden zonder van de blog een complexe applicatie te maken.
Die scheiding maakt het systeem makkelijker te onderhouden. Ik kan de blog aanpassen, de deploymentworkflow bijwerken of de statische host verplaatsen zonder de hele setup opnieuw te schrijven.
Resultaat
Hierdoor voelt de blog meer als infrastructuur en minder als een losse website. De pipeline blijft bescheiden, maar geeft de repository een betrouwbaar deploymentdoel: schrijven, builden en de statische output via een gecontroleerde workflow publiceren.
De volgende stap in deze reeks ging minder over deployment en meer over het vormen van de repository tot de site die ik wilde onderhouden.