MI-vel készült alkalmazás hosztolása: Lovable-ből vagy Boltból saját szerverre

Hol fut most az alkalmazása

A Lovable, a Bolt és a Replit egyetlen kattintással, a saját infrastruktúráján teszi közzé az alkalmazást. A dokumentációjuk, 2026 októberi állapot szerint, a következőket mondja:

A v0 egy Vercel-projektben tesz közzé, és Next.js-alkalmazást generál (React, TypeScript, Tailwind CSS); a kód exportálható, vagy kétirányúan szinkronizálható a GitHubbal. A Cursor a számítógépére telepített szerkesztő és programozóügynök: a kód már ott van, a tárhely megválasztása pedig teljesen az Ön döntése.

Ezek a beépített tárhelyek a gyors közzétételre készültek. A Lovable-nél és a Replitnél is az online verzió egy pillanatkép, amely minden közzétételkor megújul, a költség pedig a platform használatát követi (a Lovable-nél kreditek fedezik a back-end működését és az MI-t; a Replitnél a Starter csomag egy közzétett alkalmazást tartalmaz, amely 30 nap után lejár, és újra közzé kell tenni). Saját szerverre az lép át, aki saját irányítása alatt álló domaint és adatokat, fenntartott erőforrásokat, állandó háttérfeladatokat szeretne, vagy megfelelőségi követelményeknek kell eleget tennie.

A kód és az adatok megszerzése

A legbiztosabb, ha a projektet egy GitHub-tárolóhoz kapcsolja: minden módosítás commitként érkezik oda, a teljes előzménnyel. A Lovable-nél a szinkronizálás kétirányú: tovább építheti az alkalmazást a Lovable-ben, miközben a szervere kiszolgálja.

1. Lovable: kapcsolja a projektet a GitHubhoz, a GitLabhoz vagy a Bitbuckethez, vagy töltse le a kód .zip archívumát (fizetős előfizetés).
2. Bolt: kapcsolja össze a GitHubbal, vagy kattintson a projekt címére bal felül, majd a „Download” gombra.
3. Replit: a fájlfa tetején a hárompontos menü, majd „Download as zip”; vagy a Git eszköz, a GitHub-fiókjához kapcsolva, automatikus szinkronizálással.
4. v0: kapcsolja össze a GitHubbal a projekt menüjéből („Settings”, majd „GitHub”), vagy exportálja a kódot.

A kód nem tartalmazza sem az adatbázis tartalmát, sem a felhasználók által feltöltött fájlokat. A Lovable-nél az adatbázis a projektből egy .backup fájlba exportálható, amelyet a pg_restore paranccsal lehet visszaállítani, a tároló fájljai pedig külön tölthetők le. A Boltnál az adatbázis a saját Supabase-fiókjához is kapcsolható (Pro és Teams csomag).

Miből áll az alkalmazása

Nyissa meg a package.json fájlt: ebből kiderül, mire épül az alkalmazás, vagyis mit kell futtatnia a szerverének.

A Vite-nál minden VITE_ előtaggal kezdődő változó a build során bekerül a böngészőnek küldött kódba: minden látogató elolvashatja, és az értékének megváltoztatása új buildet igényel. Ez szándékos a Supabase nyilvános kulcsánál (sb_publishable_…, vagy a régebbi anon), amely a böngészőnek készült, és amelyet a sorszintű biztonsági szabályok (RLS) kereteznek. A titkos kulcs (sb_secret_…, vagy a régebbi service_role) megkerüli ezeket a szabályokat: a szerveren marad, VITE_ előtag nélkül.

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

Élesítés előtt kapcsolja be az RLS-t minden táblán: a szabályai védik az adatait, miközben a nyilvános kulcs a böngészőben jár.

Telepítés a saját szerverre, lépésről lépésre

Egy linuxos VPS-en az élesítés mindig ugyanabban a sorrendben történik. A Lovable a Node.js 22-t ajánlja az alkalmazásai buildeléséhez és futtatásához.

1. A build: klónozza a tárolót a szerverre, majd futtassa az npm install és az npm run build parancsot. Egy Vite-alkalmazás statikus fájlokat állít elő a dist/ mappában; egy TanStack Start-alkalmazás a NITRO_PRESET=node-server npm run build paranccsal készül, és a node .output/server/index.mjs paranccsal indul, a 3000-es porton; egy Next.js-alkalmazás az npm run start paranccsal indul.
2. A folyamat: szerveres alkalmazásnál egy systemd-szolgáltatás a géppel együtt elindítja, és újraindítja, ha leáll.
3. A webszerver: az Nginx vagy a Caddy fogadja a látogatókat. Vite-alkalmazásnál minden ismeretlen címre az index.html fájlt adja vissza, különben egy frissített oldal 404-et válaszol; szerveres alkalmazásnál továbbítja a kéréseket a Node.js-folyamatnak.
4. A domain: egy A típusú DNS-rekord (IPv6-hoz AAAA is) a szerverre mutat.
5. A HTTPS: ingyenes Let's Encrypt-tanúsítvány. A Caddy magától megszerzi és megújítja; Nginx mellett a Certbot gondoskodik róla.
6. A titkos kulcsok: egy környezeti fájlban, amelyet csak az alkalmazás felhasználója olvashat, a Git-tárolón kívül.
7. Az adatbázis: hagyja a back-endet a szolgáltatójánál, vagy telepítse a saját szerverére. Egy Supabase-alkalmazásnak a PostgreSQL-adatbázis mellett hitelesítésre, tárolásra, valós idejű funkciókra és függvényekre is szüksége van: a self-hosted Supabase mindezt egyben adja.
8. Az átirányítási címek: vegye fel a domainjét a hitelesítés engedélyezett URL-jei közé, valamint a Google-nál vagy a GitHubnál, ha a back-end címe megváltozik.
9. A mentések: az adatbázis és a fájlok minden éjjel, a szerveren kívülre másolva, és időnként egy próba-visszaállítás.

app.votre-domaine.com {
	reverse_proxy 127.0.0.1:3000
}

server {
    server_name app.votre-domaine.com;
    root /var/www/app/dist;

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

Mi kell ahhoz, hogy tartósan működjön

Egy online alkalmazás él: a függőségei javításokat kapnak, az adatbázisa nő, a forgalma változik. Ami gyorsan és biztonságosan tartja, egyetlen rutinban összefoglalható:

Ez a rutin a rendszergazda szakmája, és rá is bízható. Egy Managed VPS esetén a tárhelyszolgáltató naprakészen tartja a szervert, éjjel-nappal felügyeli, és beavatkozik, anélkül, hogy a hívására várna. Proaktívan az alkalmazását is figyeli (hibák, lassulások, költséges lekérdezések, lemezterület), és javasolja a javítást: Ön a saját MI-asszisztensével alkalmazza, ugyanúgy, ahogyan az alkalmazást is felépítette, a kód feletti irányítás pedig Önnél marad.