Hosta en app byggd med AI: från Lovable eller Bolt till din egen server

Var din applikation körs i dag

Lovable, Bolt och Replit publicerar applikationen på sin egen infrastruktur, med ett klick. Så här säger deras dokumentation, läst i oktober 2026:

v0 publicerar på ett Vercel-projekt och genererar en Next.js-applikation (React, TypeScript, Tailwind CSS); koden kan exporteras eller synkroniseras med GitHub åt båda hållen. Cursor är en editor och en programmeringsagent som är installerad på din dator: koden finns redan där, och hostingen är helt ditt eget val.

De här inbyggda hostinglösningarna är gjorda för att publicera snabbt. Hos både Lovable och Replit är onlineversionen en ögonblicksbild som förnyas vid varje publicering, och kostnaden följer användningen av plattformen (hos Lovable täcker krediter backendens aktivitet och AI:n; hos Replit omfattar Starter-planen en publicerad applikation, som löper ut efter 30 dagar och publiceras på nytt). Man flyttar till en egen server för en domän och data under egen kontroll, reserverade resurser, ständiga bakgrundsjobb eller krav på regelefterlevnad.

Hämta koden och data

Det säkraste är att koppla projektet till ett GitHub-repository: varje ändring hamnar där som en commit, med hela historiken. Hos Lovable fungerar synkroniseringen åt båda hållen: du fortsätter bygga i Lovable medan din server levererar applikationen.

1. Lovable: koppla projektet till GitHub, GitLab eller Bitbucket, eller ladda ner kodens .zip-arkiv (betalt abonnemang).
2. Bolt: anslut GitHub, eller klicka på projektets titel uppe till vänster och sedan på ”Download”.
3. Replit: menyn med tre punkter högst upp i filträdet och sedan ”Download as zip”; eller Git-verktyget, kopplat till ditt GitHub-konto, med automatisk synkronisering.
4. v0: anslut GitHub från projektets meny (”Settings” och sedan ”GitHub”), eller exportera koden.

Koden innehåller varken databasens innehåll eller filerna som dina användare har laddat upp. Hos Lovable exporteras databasen från projektet som en .backup-fil, som återställs med pg_restore, och filerna i lagringen laddas ner separat. Hos Bolt kan databasen kopplas till ditt eget Supabase-konto (planerna Pro och Teams).

Vad din applikation består av

Öppna filen package.json: den visar vad applikationen bygger på, och därmed vad din server måste köra.

Med Vite byggs varje variabel vars namn börjar med VITE_ in i koden som skickas till webbläsaren, vid bygget: varje besökare kan läsa den, och ett nytt värde kräver ett nytt bygge. Det är avsikten för Supabases publika nyckel (sb_publishable_…, eller den äldre anon), som är gjord för webbläsaren och omgärdad av säkerhetsreglerna på radnivå (RLS). Den hemliga nyckeln (sb_secret_…, eller den äldre service_role) går förbi de reglerna: den stannar på servern, utan prefixet VITE_.

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

Aktivera RLS på varje tabell före lanseringen: det är reglerna som skyddar dina data medan den publika nyckeln cirkulerar i webbläsaren.

Lägg den på din egen server, steg för steg

På en VPS med Linux följer publiceringen alltid samma ordning. Lovable rekommenderar Node.js 22 för att bygga och köra sina applikationer.

1. Bygget: klona repositoryt på servern och kör sedan npm install och npm run build. En Vite-applikation producerar statiska filer i dist/; en TanStack Start-applikation byggs med NITRO_PRESET=node-server npm run build och startas med node .output/server/index.mjs, på port 3000; en Next.js-applikation startas med npm run start.
2. Processen: för en applikation med server startar en systemd-tjänst den tillsammans med maskinen och startar om den om den stannar.
3. Webbservern: Nginx eller Caddy tar emot besökarna. För en Vite-applikation skickar den tillbaka index.html för varje okänd adress, annars svarar en omladdad sida med 404; för en applikation med server skickar den vidare förfrågningarna till Node.js-processen.
4. Domännamnet: en DNS-post av typen A (och AAAA för IPv6) pekar på servern.
5. HTTPS: ett gratis certifikat från Let's Encrypt. Caddy hämtar och förnyar det på egen hand; med Nginx sköter Certbot det.
6. Hemligheterna: i en miljöfil som bara applikationens användare kan läsa, utanför Git-repositoryt.
7. Databasen: behåll backenden hos dess leverantör, eller installera den på din server. En Supabase-applikation behöver, utöver sin PostgreSQL-databas, autentisering, lagring, realtid och funktioner: självhostad Supabase samlar dem.
8. Omdirigeringsadresserna: lägg till din domän bland autentiseringens tillåtna URL:er, och hos Google eller GitHub om backenden byter adress.
9. Säkerhetskopiorna: databasen och filerna varje natt, kopierade utanför servern, och en provåterställning då och då.

app.din-doman.com {
	reverse_proxy 127.0.0.1:3000
}

server {
    server_name app.din-doman.com;
    root /var/www/app/dist;

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

Det som krävs för att den ska hålla

En applikation i drift lever: dess beroenden får säkerhetsrättningar, dess databas växer, dess trafik förändras. Det som håller den snabb och säker ryms i en rutin:

Den här rutinen är en systemadministratörs yrke, och den går att lämna över. Med en Managed VPS håller leverantören servern uppdaterad, övervakar den dag och natt och griper in utan att vänta på ditt samtal. Leverantören följer också din applikation proaktivt (fel, långsamma svarstider, tunga frågor, diskutrymme) och rekommenderar rättelsen: du genomför den med din egen AI-assistent, precis som du byggde applikationen, och du behåller kontrollen över din kod.