homelab
Blogdeployments automatiseren voor mijn homelab
Hoe ik deze Astro-blog laat builden en publiceren via een kleine self-hosted deployment workflow.
Ik wilde dat deze blog niet langer aanvoelde als een lokale map die toevallig kan builden. De eerste nuttige stap was een deployment workflow: de source pushen, de Astro-site in een gecontroleerde job builden, en alleen de gegenereerde statische bestanden publiceren naar de webhost.
De setup 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 omgeving errond, maar de publieke vorm 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 nieuwe 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. Hij installeert dependencies, buildt 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. Hij 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 van de remote kopie verdwijnen, dus de syncstap houdt de gepubliceerde map gelijk met de huidige build.
De gevoelige onderdelen van dat proces staan in Forgejo secrets en deploymentinstellingen. Hostnames, credentials, poorten en paden horen niet in content of in de repository.
Homelabcontext
Dit past bij hoe ik het homelab wil opbouwen: elke service heeft een beperkte taak. Forgejo beheert projectautomatisering, de runner buildt de site, en Nginx serveert statische bestanden. Proxmox geeft 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 deployment workflow 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: content schrijven, builden en de statische output via een gecontroleerde workflow publiceren.
De volgende stap in deze reeks ging minder over deployment en meer over de repository vormen tot de site die ik wilde onderhouden.