Hosting af en app bygget med AI: fra Lovable eller Bolt til din egen server

Hvor din applikation kører i dag

Lovable, Bolt og Replit publicerer applikationen på deres egen infrastruktur med ét klik. Her er, hvad deres dokumentation siger, læst i oktober 2026:

v0 publicerer på et Vercel-projekt og genererer en Next.js-applikation (React, TypeScript, Tailwind CSS); koden kan eksporteres eller synkroniseres med GitHub i begge retninger. Cursor er en editor og en programmeringsagent, der er installeret på din computer: koden ligger der allerede, og hostingen er helt dit eget valg.

Disse indbyggede hostingløsninger er tænkt til at publicere hurtigt. Hos både Lovable og Replit er onlineversionen et øjebliksbillede, der fornyes ved hver publicering, og omkostningen følger brugen af platformen (hos Lovable dækker kreditter backendens aktivitet og AI; hos Replit omfatter Starter-planen én publiceret applikation, der udløber efter 30 dage og skal publiceres igen). Man flytter til sin egen server for at få et domæne og data under egen kontrol, reserverede ressourcer, permanente baggrundsopgaver eller for at opfylde krav til compliance.

Hent koden og dataene

Det sikreste er at forbinde projektet med et GitHub-repository: hver ændring lander der som et commit, med hele historikken. Hos Lovable virker synkroniseringen i begge retninger: du bygger videre i Lovable, mens din server leverer applikationen.

1. Lovable: forbind projektet med GitHub, GitLab eller Bitbucket, eller download kodens .zip-arkiv (betalt abonnement).
2. Bolt: forbind GitHub, eller klik på projektets titel øverst til venstre og derefter på «Download».
3. Replit: menuen med tre prikker øverst i filtræet og derefter «Download as zip»; eller Git-værktøjet, forbundet med din GitHub-konto, med automatisk synkronisering.
4. v0: forbind GitHub fra projektets menu («Settings» og derefter «GitHub»), eller eksportér koden.

Koden indeholder hverken databasens indhold eller de filer, dine brugere har uploadet. Hos Lovable eksporteres databasen fra projektet som en .backup-fil, der gendannes med pg_restore, og filerne i lageret downloades separat. Hos Bolt kan databasen knyttes til din egen Supabase-konto (Pro- og Teams-planerne).

Hvad din applikation består af

Åbn filen package.json: den viser, hvad applikationen bygger på, og dermed hvad din server skal køre.

Med Vite bliver enhver variabel, hvis navn begynder med VITE_, bygget ind i den kode, der sendes til browseren, på tidspunktet for build: hver besøgende kan læse den, og en ny værdi kræver et nyt build. Det er meningen for Supabases offentlige nøgle (sb_publishable_… eller den ældre anon), som er lavet til browseren og beskyttes af sikkerhedsreglerne på rækkeniveau (RLS). Den hemmelige nøgle (sb_secret_… eller den ældre service_role) går uden om de regler: den bliver på serveren, uden præfikset VITE_.

VITE_SUPABASE_URL=https://xxxx.supabase.co
VITE_SUPABASE_PUBLISHABLE_KEY=sb_publishable_xxxx
VITE_SUPABASE_PROJECT_ID=xxxx

Slå RLS til på hver tabel før lanceringen: det er reglerne, der beskytter dine data, mens den offentlige nøgle cirkulerer i browseren.

Sæt den på din egen server, trin for trin

På en VPS med Linux følger idriftsættelsen altid den samme rækkefølge. Lovable anbefaler Node.js 22 til at bygge og køre sine applikationer.

1. Build: klon repositoriet på serveren, og kør derefter npm install og npm run build. En Vite-applikation producerer statiske filer i dist/; en TanStack Start-applikation bygges med NITRO_PRESET=node-server npm run build og startes med node .output/server/index.mjs på port 3000; en Next.js-applikation startes med npm run start.
2. Processen: for en applikation med server starter en systemd-tjeneste den sammen med maskinen og genstarter den, hvis den stopper.
3. Webserveren: Nginx eller Caddy tager imod de besøgende. For en Vite-applikation returnerer den index.html på enhver ukendt adresse, ellers svarer en genindlæst side med 404; for en applikation med server sender den forespørgslerne videre til Node.js-processen.
4. Domænenavnet: en DNS-post af typen A (og AAAA for IPv6) peger på serveren.
5. HTTPS: et gratis certifikat fra Let's Encrypt. Caddy henter og fornyer det af sig selv; med Nginx klarer Certbot det.
6. Hemmelighederne: i en miljøfil, som kun applikationens bruger kan læse, uden for Git-repositoriet.
7. Databasen: behold backenden hos dens leverandør, eller installér den på din server. En Supabase-applikation har ud over sin PostgreSQL-database brug for godkendelse, lagring, realtid og funktioner: selvhostet Supabase samler dem.
8. Redirect-adresserne: tilføj dit domæne til godkendelsens tilladte URL'er, og hos Google eller GitHub, hvis backenden skifter adresse.
9. Backup: databasen og filerne hver nat, kopieret uden for serveren, og en prøvegendannelse en gang imellem.

app.dit-domaene.com {
	reverse_proxy 127.0.0.1:3000
}

server {
    server_name app.dit-domaene.com;
    root /var/www/app/dist;

    location / {
        try_files $uri $uri/ /index.html;
    }
}

Det skal der til, for at den holder

En applikation online lever: dens afhængigheder får rettelser, dens database vokser, dens trafik ændrer sig. Det, der holder den hurtig og sikker, kan samles i en rutine:

Denne rutine er en systemadministrators fag, og den kan overlades til andre. Med en Managed VPS holder hostingudbyderen serveren opdateret, overvåger den dag og nat og griber ind uden at vente på dit opkald. Udbyderen følger også din applikation proaktivt (fejl, langsomme svartider, tunge forespørgsler, diskplads) og anbefaler dig rettelsen: du gennemfører den med din egen AI-assistent, ligesom du byggede applikationen, og du beholder hånden på din kode.