Stop med at kæmpe med hosting – du vælger forkert løsning

“Hvorfor er min side stadig ikke online, jeg har jo alle filerne?” spurgte en ven til mig klokken 23.37, mens han sendte endnu et screenshot af en fejlside.

Det er dér, mange rammer muren: selve hjemmesiden er færdig, men deploy-delen føles som sort magi. Det behøver den ikke at gøre.

Hvad betyder “statisk site” – og hvornår er det nok?

Lad os starte med definitionen, så vi ved, hvad vi arbejder med.

Et statisk site er i bund og grund HTML, CSS og JavaScript, som serveren bare sender videre til browseren uden at køre kode på serveren først.

Typiske eksempler:

• Portfolio-side
• Landing page for et produkt
• Dokumentation / wiki
• Blog bygget med statisk site generator (fx Astro, Next i static mode, Gatsby, Hugo)

Det kan godt være genereret af et build-step (fx React eller Svelte), men outputtet er stadig en mappe med filer, som kan ligge hvor som helst.

Hvornår er statisk ikke nok?

Du støder ind i grænsen for statiske sites, når du skal bruge ting som:

• Bruger-login og sessions
• Database med skriv/ændringer fra brugere
• Avanceret betalingsflow
• API endpoints du selv hoster

Man kan godt snyde meget langt med services, serverless functions og tredjeparts-API’er, men på et tidspunkt har du brug for en rigtig backend. Mere om det senere.

Hvad vil du egentlig have din gratis host til at kunne?

Før du vælger mellem Netlify, Vercel eller GitHub Pages, er det værd lige at specificere “kravene”. Altså som et mini projekt-setup.

Spørg dig selv:

• Hvordan er sitet bygget?
  Ren HTML/CSS/JS, eller bruger du et framework som React, Next, Astro, SvelteKit?
• Har du et build-step?
  Fx npm run build der laver en dist eller build mappe.
• Vil du have custom domæne?
  Fx mitnavn.dk i stedet for brugernavn.github.io.
• Skal der være formularer?
  Fx kontaktformular, nyhedsbrev-tilmelding.
• Skal du bruge backend-lignende funktioner?
  Serverless functions, cron-jobs, simple API’er.

Dine svar afgør ret hurtigt, hvad der giver mest mening.

Netlify vs Vercel vs GitHub Pages – kort og ærligt overblik

Her er den korte version, som jeg selv bruger i hovedet, når jeg vælger:

• GitHub Pages: Simpelt, godt til rene statiske sites, portfolios og dokumentation. Ingen avancerede features, men meget stabilt.
• Netlify: God allround til statiske sites og frontend-projekter. Let forms-support, redirects, serverless functions.
• Vercel: Meget stærk til Next.js og moderne frameworks. Super deployment-oplevelse, især når du kører full stack i Vercel-style.

Sammenligningstabel

Mini beslutningsmodel

Hvis du vil have en hurtig “if-else” i hovedet:

• Hvis du har ren HTML/CSS/JS eller en simpel statisk generator
  så er GitHub Pages eller Netlify helt fint.
• Hvis du bruger Next.js og vil bruge deres full stack features
  så vælg Vercel.
• Hvis du vil have forms uden egen backend
  så vælg Netlify.
• Hvis du vil have minimalt setup og bruger GitHub i forvejen
  så er GitHub Pages nemt.

Hvis du vil nørde mere deploy-workflow, har vi også artikler om fx versionsstyring og Git, som spiller tæt sammen med det her.

Sådan foregår et typisk deploy fra Git repo

Selve processen er næsten den samme, uanset om du ender på Netlify, Vercel eller GitHub Pages. Det er faktisk meget rart.

1. Sørg for at dit projekt bygger lokalt

Åbn en terminal i din projektmappe og kør:

npm install
npm run build

Tjek at der opstår en build-mappe (typisk build, dist eller out), og at den indeholder HTML, CSS, JS og assets.

Hvis du ikke kan bygge lokalt, bygger den heller ikke i skyen. Simpelt men overset.

2. Læg koden på GitHub

Opret et repo og commit koden:

git init
git add .
git commit -m "Initial commit"
git branch -M main
git remote add origin <URL-TIL-DIT-REPO>
git push -u origin main

Når du kan se filerne på github.com, er du klar til næste skridt.

3. Tilslut repo til hosting

Netlify:

• Log ind på Netlify
• Vælg “Add new site” → “Import an existing project”
• Forbind til GitHub og vælg dit repo
• Indstil build command (fx npm run build) og publish directory (fx dist)

Vercel:

• Log ind på Vercel
• “Add New” → “Project”
• Importér dit GitHub repo
• Vercel gætter ofte framework og build, men dobbelttjek output folder

GitHub Pages (simpel HTML):

• Push dine bygget filer direkte til en branch (fx main eller gh-pages)
• Gå til repo → Settings → Pages
• Vælg branch og evt. folder (/root eller /docs)

GitHub Pages med frameworks kræver ofte et ekstra build-step via GitHub Actions. Hvis du er helt ny, vil jeg normalt anbefale Netlify eller Vercel til de projekter.

4. Skub ændringer og lad platformen bygge

Nu er workflowet typisk:

git add .
git commit -m "Opdateret hero sektion"
git push

Hosting-platformen opdager ændringerne, kører build, og når den er færdig, får du en URL til den nye version.

Det her er i øvrigt en af grundene til, at det giver stor mening at lære Git tidligt. Det fungerer som din deploy-knap. Du kan læse mere om det i andre artikler på Coding Class.

Custom domæne og HTTPS – hvad du skal gøre, og hvad du skal lade være

Det mest skræmmende for mange er faktisk ikke deploy, men DNS. Det kan jeg godt forstå. DNS føles som et UI fra 1998 og opfører sig derefter.

Step 1: Køb domænet

Køb fx mitnavn.dk hos en domæneregistrar (One.com, Simply, Cloudflare, whatever du foretrækker).

Her får du adgang til DNS-indstillinger, typisk et panel hvor du kan lave A-records, CNAME osv.

Step 2: Peg domænet mod din host

Den præcise opsætning afhænger af host, men mønstret er det samme:

• På din host (Netlify/Vercel/GitHub Pages): Tilføj domænet, fx mitnavn.dk, i projektets domain settings.
• Hosten viser typisk hvilke DNS-records du skal oprette (CNAME og/eller A-record).
• Gå til din domæneregistrar, opret/ret DNS-records så de matcher præcis.

Eksempel med Netlify (forenklet):

• CNAME for www → mit-site.netlify.app
• Eventuelt A-records til Netlifys IP’er for roddomæne (mitnavn.dk)

Step 3: Vent (seriøst)

DNS kan tage fra 5 minutter til flere timer om at opdatere. Mange fejlsøger alt for aggressivt i det her vindue.

Hvis dine records matcher det, hosten siger, så giv det tid. Lad være med at skifte fem gange frem og tilbage, det gør det bare langsommere.

HTTPS/SSL: Tryk kun på den rigtige knap

På Netlify og Vercel får du normalt HTTPS automatisk via Let’s Encrypt, når DNS peger rigtigt. Der er typisk en “Enable HTTPS” eller “Verify” knap.

Det du ikke skal gøre:

• Købe ekstra certifikat et andet sted (uden grund).
• Prøve at uploade egne certifikater, hvis du bare laver en almindelig hjemmeside.

Hold dig til platformens standardløsning, medmindre du har meget specifikke krav. Det har du næsten helt sikkert ikke, hvis du læser det her som begynder.

Typiske deploy-fejl – og hvad der faktisk går galt

Nu tager vi den del, hvor folk ofte sidder og river sig i håret. Her er et lille fejlkatalog med årsag og løsning.

1. “Mit site er bare en hvid side”

Sandsynlig årsag: JavaScript-fejl, forkert path til assets, eller du har deployet src-filer i stedet for build-output.

Tjek:

• Åbn dev tools i browseren (F12) → Console. Er der fejl?
• Tjek Network fanen. Får du 404 på CSS/JS filer?
• Har du sat publish directory til build-mappen (fx dist) og ikke roden af repoet?

Løsning: Sørg for at deploye den mappe, som npm run build genererer. Ikke din src-mappe.

2. “SPA routes giver 404 ved reload”

Single Page Apps (React Router, Vue Router osv.) bruger typisk client-side routing. Serveren kender kun til /, men du prøver at loade /about direkte, så hosten svarer med 404.

Sandsynlig årsag: Manglende redirect/rewrites.

Løsning på Netlify: Tilføj en _redirects fil i din publish folder med:

/*    /index.html   200

Løsning på Vercel: Brug frameworkets anbefalede setup. For de fleste moderne frameworks håndterer Vercel det automatisk. Tjek deres docs, hvis du har custom routing.

GitHub Pages: Her er det lidt mere hacky. Nogle bruger en custom 404-side, der loader din SPA og router videre. Det er en af grundene til, at jeg normalt peger mod Netlify/Vercel til SPA’er.

3. “Builden fejler på serveren, men virker lokalt”

Sandsynlige årsager:

• Manglende environment variables (API keys osv.) på hosten.
• Node-version forskellig lokalt vs. på hosten.
• Dependencies, der kun er installeret globalt hos dig, men ikke i package.json.

Løsning:

• Tjek build-logs i Netlify/Vercel dashboard. Læs fejlen helt igennem.
• Sørg for at alle environment variables er sat i hostens UI (fx API_URL).
• Tilføj en engines sektion i package.json, hvis du er afhængig af en bestemt Node-version.

4. “Jeg ser ikke mine ændringer efter deploy”

Sandsynlig årsag: Cache. Enten i browseren eller CDN’en hos hosten.

Løsning:

• Force refresh i browseren (Ctrl+F5 eller Cmd+Shift+R).
• Prøv i inkognito-vindue.
• Tjek om der er cache headers eller aggressive service workers, hvis du leger med PWA.

Hvis logs siger “Deploy succeeded”, men intet ændrer sig, er det næsten altid cache-relateret.

5. “Mit custom domæne viser stadig den gamle side”

Sandsynlig årsag: DNS peger stadig på gammel host, eller din computer/browser har cached DNS.

Løsning:

• Tjek DNS via et eksternt værktøj (fx dig eller et online DNS lookup). Matcher IP/CNAME det, hosten siger?
• Hvis ja: vent. Giv det op til et par timer.
• Hvis nej: ret DNS-records, så de er 1:1 med hostens instruktioner.

Hvornår bør du vokse ud af “statisk + gratis host”?

På et tidspunkt opdager du måske, at du er ved at tvinge et frontend-hosting-setup til at være en backend. Det er et godt tegn, faktisk. Det betyder bare, at dit projekt er blevet mere avanceret.

Typiske tegn på at du er klar til backend

• Du vil have rigtigt login-system med permissions.
• Du skal gemme data fra brugere, ikke kun sende det videre til en mail.
• Du har mange forskellige API endpoints og forretningslogik, der ikke bør ligge i client-side JavaScript.
• Du bøvler med workarounds, som føles mere og mere skøre.

På det punkt giver det mening at kigge på rigtige backend-løsninger (Node, Django, Flask, Laravel osv.) eller hosted backends (Supabase, Firebase m.fl.).

Hvordan tager du næste skridt uden at smide alt ud?

Du behøver ikke rive alt ned for at få backend. Du kan:

• Beholde dit frontend-build deployet på Netlify/Vercel.
• Bygge et separat API (fx i Node/Express) og hoste det andetsteds.
• Lade frontend kalde dit nye API i stedet for fx Netlify Forms.

Det giver en glidende overgang fra “rent statisk” til “rigtig webapp” uden at du skal starte helt forfra. Mange professionelle projekter bruger i praksis samme opdeling.

Hvis du gerne vil have en rolig introduktion til backend-tanker, så er næste skridt at lære om HTTP, API’er og måske en simpel server i fx Python eller Node.

Hvis du kun gør én ting anderledes når du deployer

Hvis du skal vælge én forbedring efter den her artikel, så lad det være den her: Deploy altid build-output, ikke hele projektet blindt.

Byg lokalt, se hvad der kommer ud, peg din host på præcis den mappe, og brug logs aktivt. Resten er mest detaljer, som du lærer hen ad vejen, én fejl ad gangen. Det er sådan de fleste af os har gjort det.