Sådan er sitet bygget – en teknisk gennemgang af hele processen

Dette indlæg dokumenterer den proces, der ligger bag jakob-rohde.com. Ikke som en tutorial, men som en beskrivelse af den faktiske pipeline: hvordan et indlæg eller en ændring bevæger sig fra en prompt i Hermes Desktop, gennem Hermes Agent på agentserver, forbi dev-serveren og Git, og endelig ud på produktionsserveren. Hele kæden er self-hosted, og det er værd at forstå hvert led, fordi det sætter rammen for alt det andet på sitet.

De tre maskiner

Opsætningen hviler på tre fysiske roller, selvom de i praksis er fordelt på to servere og en workstation.

Hermes Desktop kører på min workstation. Det er den grafiske chatflade, hvor jeg skriver prompts. Desktop-appen er ikke selv den der udfører arbejdet – den er klienten der taler med agenten.

Hermes Agent kører på agentserver, en Ubuntu-maskine på mit LAN. Her ligger gatewayen som en systemd-brugerproces, og det er her agenten faktisk udfører kommandoer, læser filer og skriver kode. Når jeg skriver en prompt i Desktop, bliver den sendt hertil og behandlet.

Produktionsserveren er hvor sitet faktisk kører. Appen kører via PM2 fra en mappe på serveren. Foran den står en reverse proxy, som videresender domænet til appen.

Fra prompt til kode

Når jeg beder agenten om noget foregår det sådan:

Jeg skriver prompten i Hermes Desktop.
Desktop-appen sender den til Hermes Agent på agentserver.
Agenten arbejder i en klon af repoet under en udviklingsmappe.
Ændringerne testes lokalt på agentserver, før de rører noget andet.

Det sidste punkt er en fast regel: byg og test altid på agentserver først, og deploy først når det er testet. Det betyder at dev-miljøet og produktionsmiljøet aldrig deler tilstand, og at en fejl fanges tidligt i stedet for at ramme det offentlige site.

Dev-serveren

På agentserver kører en dev-server, tilgængelig på LAN'et. Den bruger en separat SQLite-database og en separat ejerkonto. Det giver et sikkert sted at afprøve nye funktioner – for eksempel vault-editoren, papirkurven eller søgefunktionen – uden at risikere produktionsdata.

En detalje der har betydning: login fra andre maskiner på LAN'et kræver at appens offentlige URL og auth-URL peger på LAN-værten, og at udviklings-origin'en inkluderer den. Uden det forsøger browseren at kalde sin egen loopback-adresse, og login fejler. Det er en klassisk fælde, værd at kende til.

Git som bindeled

Når en ændring er testet og godkendt, committes den og pushes til GitHub. Git fungerer her som det eneste bindeled mellem dev og prod – der er ingen direkte filoverførsel mellem de to servere.

Commit-historikken er også dokumentation. Hver funktion på sitet – vault, papirkurv, søgning, AI-modelvælgeren – er et separat commit med en beskrivende besked. Det gør det muligt at gå tilbage og se præcis hvad der blev ændret, og hvorfor.

Deploy til produktionsserveren

Deploy er en simpel, gentaget sekvens på produktionsserveren:

cd app-mappe
git pull --ff-only origin main
npm install
npm run build
pm2 reload app-navn

git pull --ff-only sikrer at der aldrig opstår en uventet merge. npm run build bygger Next.js-appen, og pm2 reload genstarter processen uden nedetid. PM2 kører appen som en enkelt forekomst i fork-mode med next start.

En ting der dukker op igen og igen: lock-filen på produktionsserveren får lokale ændringer fra npm install, som så kolliderer med git pull. Løsningen er at droppe den lokale ændring med git checkout -- package-lock.json før pull. Det er en lille irritation, men nem at håndtere, når man ved den er der.

Reverse proxy og domænet

Foran produktionsserveren står en reverse proxy. Den håndterer TLS og videresender jakob-rohde.com til appen. Det betyder at produktionsserveren selv ikke eksponerer sine porte direkte – al trafik går gennem proxyen.

Det giver en ren adskillelse: proxyen håndterer certifikater og videresendelse, mens appen kun forholder sig til HTTP på en intern port. Skal der tilføjes et nyt domæne eller en ny tjeneste, gøres det i proxyen uden at røre appen.

Hvorfor denne opsætning

Det kunne være gjort enklere. En enkelt server med appen og en reverse proxy ville dække det meste. Men adskillelsen mellem agentserver og produktionsserver er bevidst. Den giver et testmiljø der er isoleret fra det offentlige site, og den gør det muligt at eksperimentere frit uden risiko.

Self-hosting handler for mig om kontrol. Kontrol over hvor data ligger, hvordan trafikken flyder, og hvornår noget deployes. Denne pipeline er et udtryk for det – hvert led er synligt, og intet er overladt til en tredjepart.

Konklusion

Processen fra prompt til publiceret indlæg er kort, men hvert led har en funktion. Hermes Desktop og Hermes Agent håndterer udviklingen, dev-serveren fanger fejl, Git dokumenterer og transporterer ændringerne, og produktionsserveren bag reverse proxyen leverer sitet. Det er en opsætning der er let at forstå, nem at fejlfinde, og som kan vokse uden at blive uoverskuelig.