Fra vibe coding til live app - det ingen fortæller dig undervejs

Du har bygget noget. Det virker på din skærm. Du er stolt - og med rette. Næste spørgsmål er selvfølgeligt: hvordan får rigtige folk adgang til det?

Det er her de fleste for første gang opdager at der er et hul mellem "det virker her" og "det kører derude". Et hul som YouTube-videoer og AI-prompts sjældent viser dig fra ende til anden. Det lyder mere kompliceret end det er - men det hjælper at kende vejkortet inden du begynder.

Her er de fem skridt de færreste kender - fordi ingen fortæller om dem.

Inden vi starter: Hvem ejer egentlig din kode?

Det er et spørgsmål de færreste stiller. Og svaret er måske ikke hvad du tror.

Platforme som Lovable, Bolt, Replit og Bubble er bygget rundt om et simpelt princip: jo nemmere det er at komme i gang, jo sværere er det at komme ud igen. Det er ikke ondsindet - det er en ganske fornuftig forretningsmodel. De tjener penge på abonnementer, og din tilfredshed afhænger af at alt bare virker hos dem.

Det er som en møbleret lejlighed. Praktisk fra dag ét - du behøver ikke købe noget som helst. Men når du vil flytte, tager du ikke sofaen med.

Lovable og Bolt giver dig faktisk mulighed for at eksportere din kode. Men du gør det nok ikke - fordi det aldrig føles presserende. Helt indtil platformens priser fordobles, eller de annoncerer at de lukker tjenesten.

Og når du endelig eksporterer, får du typisk en zip-fil. Ikke et rigtigt repo. En zip-fil er bare en pose filer - ingen historik, ingen versioner, ingen måde at se hvad der er ændret siden sidst. Det er et godt udgangspunkt, men det er ikke det samme som at have koden i Git.

Bubble er endnu mere udpræget: der er ingen kodeeksport. Det du har bygget, lever udelukkende i deres system. Siger de op, er det dit problem.

Det er ikke et argument imod at bruge dem. Det er et argument for at vide hvad aftalen er.

Skridt 1 - Gem din kode et sted du ejer den

Det første og vigtigste skridt handler ikke om servere eller domæner. Det handler om at have en kopi af din kode et sted du kontrollerer.

Det hedder versionsstyring, og det mest udbredte værktøj hedder Git. Alle seriøse udviklere bruger det - ikke fordi det er besværligt at lære, men fordi det løser et problem alle støder ind i: hvad gør jeg når noget gik i stykker, og jeg ikke ved hvornår eller hvorfor?

Git er ikke et udviklertrick. Det er den måde professionelle projekter overlever på. Tænk på det som Google Docs for kode: automatisk versionshistorik, mulighed for at gå tilbage til hvad som helst, og et komplet overblik over hvad der er ændret og hvornår.

Det svarer til forskellen på "rapport_endelig_v3_FINAL2.docx" liggende på dit skrivebord - og det samme dokument i Google Docs med 200 versioner gemt automatisk. Den ene kan du miste. Den anden kan du altid rulle tilbage.

GitHub, GitLab og Gitea er tjenester der hoster din kode med Git. Du ejer den, du styrer hvem der har adgang, og ingen platform kan låse dig inde.

Sådan bruger udviklere Git i praksis

Det er enklere end det lyder. Forestil dig at du arbejder på din app og tilføjer en ny funktion - fx en kontaktformular. Sådan ser en typisk arbejdsdag ud:

1. Du åbner din kode og laver ændringerne
2. Når du er tilfreds, gemmer du dem med en kort besked: "Tilføjet kontaktformular"
3. Git tager et snapshot af hele projektet på det tidspunkt - med din besked, dato og hvad der præcis er ændret
4. Du skubber det op til GitHub, og nu ligger det sikkert online

Tre dage senere opdager du at noget er gået i stykker. Du ved ikke hvad. Med Git kan du se en liste over alle dine snapshots, sammenligne dem, og gå tilbage til det der virkede - på under fem minutter.

Vil du prøve noget nyt uden at risikere at ødelægge det der virker? Du laver en gren - en kopi af projektet du kan eksperimentere i. Virker det, fletter du det ind. Virker det ikke, sletter du grenen og intet er tabt.

Det er ikke magi. Det er bare en vane som de fleste professionelle udviklere aldrig arbejder uden.

Eksportér din kode fra Lovable eller Bolt i dag og læg den på GitHub. Det tager cirka 20 minutter første gang. Fra det øjeblik er det dit - uanset hvad platformene gør.

Skridt 2 - Din kode skal bo et sted du ejer

Når du har koden gemt i Git, skal den have en adresse på internettet. Det kræver en server - en computer der kører et sted i verden og svarer når folk besøger din app.

Det gode er at du nu selv bestemmer hvad den server hedder, hvad den koster, og hvornår du skifter den ud. Ingen abonnement der låser dig fast.

Hvad kan du vælge?

• Railway eller Render - starter gratis, nemme at komme i gang med, godt til at teste af
• Hetzner VPS - 35-60 kr. om måneden for en lille server du selv ejer og styrer fuldt ud
• SSL-certifikat (Let's Encrypt) - gratis. Giver din app det lille hængelås i browseren og krypterer al trafik. Sættes op én gang

Når det er sat op, er serveren din. Du kan flytte den, kopiere den, slukke den. Det bestemmer du.

Hvad med databaser?

Både Railway og Render tilbyder managed databases (Postgres, Redis, MySQL) som en del af deres platform. Det betyder du kan køre både din app og din database samme sted - og de håndterer backups, sikkerhed og opdateringer for dig. På Hetzner VPS installerer du selv hvad du vil - fuld kontrol, men også fuldt ansvar.

Hemmeligheder hører ikke hjemme i koden

Din app har sandsynligvis API-nøgler - til OpenAI, Stripe, din database, eller noget helt tredje. Og hvis du har vibe-coded den, er der god chance for at de står direkte i koden:

const apiKey = "sk-proj-abc123..." // 🚨 Dette er et problem

Hvorfor er det et problem?

Når du pusher til Git (selv private repos), kan API-nøgler blive eksponeret. GitHub scanner automatisk efter kendte nøgleformater, og tjenester som OpenAI og Stripe deaktiverer nøgler de finder i offentlige repos. Værre: hvis nogen får adgang til din kode, har de adgang til dine tjenester - og din regning.

Løsningen: Environment Variables

I stedet for at skrive API-nøgler direkte i koden, gemmer du dem som environment variables - hemmelige værdier der kun eksisterer på serveren, aldrig i koden.

Sådan ser det ud i praksis:

// ❌ Gør IKKE dette
const apiKey = "sk-proj-abc123..."

// ✅ Gør dette i stedet
const apiKey = process.env.OPENAI_API_KEY

Din kode refererer til navnet (OPENAI_API_KEY), men værdien lever kun på serveren. Når du udvikler lokalt, gemmer du dem i en .env fil:

OPENAI_API_KEY=sk-proj-abc123...
STRIPE_SECRET_KEY=sk_test_xyz...
DATABASE_URL=postgresql://...

Vigtig regel: Tilføj .env til din .gitignore fil, så den aldrig bliver committet til Git.

Hvordan virker det på serverne?

• Railway & Render: Built-in UI til at tilføje environment variables. Du indtaster dem én gang, og de er tilgængelige for din app
• Hetzner VPS: Du sætter dem i din deployment-config eller direkte på serveren

Alle tre platforme understøtter det fuldt ud - det er standard praksis.

Bonus: Hvad hvis du allerede har pushet API-nøgler?

Hvis du opdager at du har committet API-nøgler til Git:

1. Deaktivér nøglen med det samme i tjenesten (OpenAI, Stripe, etc.)
2. Generér en ny nøgle
3. Fjern den gamle nøgle fra koden og tilføj den nye som environment variable
4. Commit ændringen

At slette nøglen i en ny commit er ikke nok - den lever stadig i Git-historikken. Deaktivér altid nøglen først.

Skridt 3 - Opdateringer uden at noget går galt

Du har fundet ud af at lægge din app online. Nu vil du lave en ændring - tilføje en funktion, rette en fejl. Det er her mange tager den hurtige løsning: logger ind et sted, kopierer filer manuelt, krydser fingre. Det virker - helt indtil det ikke gør, og appen er halvt opdateret og halvt i stykker på én gang.

Det er som at renovere køkkenet mens restauranten er åben. Det kan lade sig gøre - men det kræver en plan.

Det du vil have er en kontrolleret måde at sende ændringer fra din computer til din server på - så du altid kan rulle tilbage hvis noget går galt. Det hedder CI/CD (Continuous Integration/Continuous Deployment) og lyder mere kompliceret end det er.

I praksis betyder det: du gemmer en ændring i Git, skubber den til GitHub, og serveren henter automatisk den nye version og sætter den i drift. Ét trin, ingen krydse fingre. Værktøjer som GitHub Actions, Railway eller Render kan sættes op til at gøre det automatisk.

Når det er sat op, opdaterer du din app ligesom du gemmer kode: ét trin, og du kan altid rulle tilbage hvis noget går galt.

Skridt 4 - Dit eget navn på appen

Et domæne. Dit eget navn i stedet for et link der ser ud som tilfældig tekst. Det koster typisk 80-150 kr. om året og er det første der får en app til at ligne noget rigtigt.

Du registrerer det hos fx Namecheap, One.com eller Gandi. Det er dit - uanset hvilken server du bruger, og uanset hvad der sker med platformene du startede på.

Skridt 5 - Hvem finder ud af det hvis noget går galt?

Din app kan gå ned. En server kan have problemer. Noget kan holde op med at virke en tirsdag aften. Spørgsmålet er: finder du det ud fordi du selv opdager det? Eller fordi en bruger skriver til dig efter at have prøvet tre gange?

Det er som en butik uden alarm. Du finder ud af der var indbrud da du møder ind om morgenen. En nattevagt kalder dig inden for minutter.

Automatiske tjek der pinger din app og sender dig en besked hvis den ikke svarer - det er den del der giver mest ro i maven. Tjenester som UptimeRobot starter gratis og er sat op på ti minutter.

Hvad koster det egentlig?

Her er hvad en typisk lille app koster om måneden når du selv ejer det hele:

En fuldt fungerende app med eget domæne, SSL og overvågning: 45-90 kr. om måneden - og du ejer det hele selv.

Sammenlign det med de platforme du måske allerede bruger

Bemærk: Priserne på platformene gælder ofte kun hosting - du betaler stadig ekstra for AI-assisteret kodning, højere limits osv. Med dit eget setup betaler du kun for infrastrukturen, og du kan bruge hvilken som helst AI-assistent (Cursor, Copilot, Claude) uden at være låst til én platform.

Når du vibe-coder din egen app, har du allerede gjort det sværeste: du har koden. Det ville være ærgerligt at give kontrollen over den væk bagefter.

Hvad laver en DevOps-person egentlig?

Det er et godt spørgsmål - og svaret er mere jordnært end det lyder.

En DevOps-person er den der kender vejkortet. Ikke fordi rejsen er svær, men fordi den første gang altid tager længere tid end nødvendigt når man ikke har gået den før. De opsætter Git, server, automatiske opdateringer og overvågning - typisk på en dag - og sikrer at du har et fundament du selv kan bygge videre på.

Du kan finde guider online og sætte det hele op selv - det tager typisk nogle weekender og en del googling. Men hvis du hellere vil bruge tiden på at bygge din app end at lære infrastruktur, er det her en DevOps-person giver værdi.

Det er ikke et månedligt abonnement på at nogen gør det for dig. Det er et engangssetup der giver dig friheden til at styre det selv bagefter. Næste gang du vil opdatere din app, gør du det med ét trin - fordi nogen satte det rigtigt op fra starten.

Det er præcis den slags hjælp jeg tilbyder via i80.dk - ikke som en der overtager dit projekt, men som en der kender arkitekturen, forklarer hvad der sker undervejs, og sikrer at du forstår det fundament du bygger på. Teknikken bag behøver ikke være en sort boks.

Bag kulisserne: Hvordan denne artikel kom online

Artiklen du læser nu tog præcis den rejse jeg har beskrevet. Her er hvad der skete bag kulisserne:

1. Skrevet i Markdown Jeg skrev denne artikel i en simpel tekstfil (.md) - ingen fancy editor, bare ren tekst med formatering. Markdown er det udviklere bruger fordi det er nemt at læse og nemt at konvertere til HTML.

2. Gemt i Git (på min egen server) Filen blev committet til mit Git repo på min egen Gitea-server - ikke GitHub eller GitLab. Gitea er open source software du selv kan køre. Det kunne lige så godt have været på Hetzner, Railway eller en lille server derhjemme.

I mit tilfælde kører den på en lille server jeg har stående - ikke fordi det er nødvendigt, men fordi jeg kan lide at have fuld kontrol. Du får samme resultat med en Hetzner VPS til 35 kr./md.

3. Automatisk bygget til en container Når jeg pusher til Git, starter en automatisk CI/CD proces: - Serveren opdager den nye commit - Markdown konverteres til HTML - Hele websitet bygges til et Docker container image - Containeren er som en lille pakke med alt der skal til for at køre websitet - kode, dependencies, alt

4. Deployed automatisk Containeren bliver automatisk deployed og sat i drift. Fra jeg trykker "git push" til artiklen er live: cirka 2-3 minutter. Ingen manuel kopiering af filer, ingen krydse fingre.

5. Du læser den nu Når du besøger i80.dk, serverer containeren HTML'en. SSL-certifikatet fra Let's Encrypt sørger for det grønne hængelås i browseren.

Sammenligning: Hjemmeserver vs. cloud

Min setup kører på en lille server jeg selv ejer - det giver mig fuld kontrol og lidt nørd-tilfredsstillelse. Men der er ingen magisk forskel på det og en Hetzner VPS:

For de fleste giver Hetzner VPS eller Railway bedst mening - du får kontrol uden at skulle tænke på hardware. Min hjemmeserver er mest fordi jeg nørder med det og elsker at forstå hver eneste del af stakken.

Hele setup'et - uanset om det kører derhjemme eller i skyen - kostede én dags arbejde at sætte op. Nu opdaterer jeg det med ét tryk - præcis som beskrevet i Skridt 3.

Rejsen er til at overskue

Fem skridt. De fleste vibe-codere er suveræne til skridt nul: bygge noget der virker. Resten er ikke sort magi - det er bare ting der ikke er på pensummet for AI-assisteret udvikling. Endnu.

Du behøver ikke forstå alt på én gang. Start med skridt 1 i dag: eksportér din kode og læg den på GitHub. Det tager 20 minutter og giver dig ejerskab over det du har bygget.

Resten af rejsen er lærbar. Første gang er den bare ny - og det er her det giver mening at have nogen med der har gået den mange gange før.

Er du i tvivl om noget på rejsen, er du velkommen til at skrive til mig på i80.dk.