Găzduirea unei aplicații create cu AI: de la Lovable sau Bolt la propriul server

Unde rulează astăzi aplicația dumneavoastră

Lovable, Bolt și Replit publică aplicația pe propria infrastructură, dintr-un clic. Iată ce spune documentația lor, consultată în octombrie 2026:

v0 publică într-un proiect Vercel și generează o aplicație Next.js (React, TypeScript, Tailwind CSS); codul se exportă sau se sincronizează cu GitHub în ambele sensuri. Cursor este un editor și un agent de programare instalat pe computerul dumneavoastră: codul se află deja acolo, iar găzduirea rămâne în întregime la alegerea dumneavoastră.

Aceste găzduiri integrate sunt gândite pentru o publicare rapidă. La Lovable, ca și la Replit, versiunea online este un instantaneu, reînnoit la fiecare publicare, iar costul urmează utilizarea platformei (la Lovable, creditele acoperă activitatea back-endului și AI-ul; la Replit, planul Starter include o aplicație publicată, care expiră după 30 de zile și se republică). Trecerea pe propriul server se face pentru un domeniu și date sub controlul dumneavoastră, resurse rezervate, sarcini permanente în fundal sau cerințe de conformitate.

Recuperarea codului și a datelor

Cel mai sigur este să legați proiectul de un depozit GitHub: fiecare modificare ajunge acolo ca un commit, cu tot istoricul. La Lovable, sincronizarea funcționează în ambele sensuri: continuați să construiți în Lovable în timp ce serverul dumneavoastră servește aplicația.

1. Lovable: legați proiectul de GitHub, GitLab sau Bitbucket sau descărcați arhiva .zip a codului (abonament plătit).
2. Bolt: conectați GitHub sau faceți clic pe titlul proiectului, în stânga sus, apoi pe „Download”.
3. Replit: meniul cu trei puncte din partea de sus a arborelui de fișiere, apoi „Download as zip”; sau instrumentul Git, legat de contul dumneavoastră GitHub, cu sincronizarea automată.
4. v0: conectați GitHub din meniul proiectului („Settings”, apoi „GitHub”) sau exportați codul.

Codul nu conține nici conținutul bazei de date, nici fișierele trimise de utilizatori. La Lovable, baza de date se exportă din proiect într-un fișier .backup, care se restaurează cu pg_restore, iar fișierele din stocare se descarcă separat. La Bolt, baza de date se poate atașa propriului dumneavoastră cont Supabase (planurile Pro și Teams).

Din ce este făcută aplicația dumneavoastră

Deschideți fișierul package.json: el arată pe ce se bazează aplicația și, deci, ce trebuie să ruleze serverul dumneavoastră.

Cu Vite, orice variabilă al cărei nume începe cu VITE_ este integrată în codul trimis browserului, în momentul build-ului: orice vizitator o poate citi, iar schimbarea valorii ei cere un nou build. Acest lucru este voit pentru cheia publică Supabase (sb_publishable_… sau vechea anon), făcută pentru browser și încadrată de regulile de securitate la nivel de rând (RLS). Cheia secretă (sb_secret_… sau vechea service_role) ocolește aceste reguli: ea rămâne pe server, fără prefixul VITE_.

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

Activați RLS pe fiecare tabel înainte de punerea online: regulile lui vă protejează datele în timp ce cheia publică circulă în browser.

Instalarea pe propriul server, pas cu pas

Pe un VPS cu Linux, punerea online urmează mereu aceeași ordine. Lovable recomandă Node.js 22 pentru construirea și rularea aplicațiilor sale.

1. Build-ul: clonați depozitul pe server, apoi rulați npm install și npm run build. O aplicație Vite produce fișiere statice în dist/; o aplicație TanStack Start se construiește cu NITRO_PRESET=node-server npm run build și pornește cu node .output/server/index.mjs, pe portul 3000; o aplicație Next.js pornește cu npm run start.
2. Procesul: pentru o aplicație cu server, un serviciu systemd o pornește odată cu mașina și o repornește dacă se oprește.
3. Serverul web: Nginx sau Caddy primește vizitatorii. Pentru o aplicație Vite, el returnează index.html pentru orice adresă necunoscută, altfel o pagină reîncărcată răspunde cu 404; pentru o aplicație cu server, transmite cererile procesului Node.js.
4. Numele de domeniu: o înregistrare DNS A (și AAAA pentru IPv6) indică spre server.
5. HTTPS-ul: un certificat Let's Encrypt, gratuit. Caddy îl obține și îl reînnoiește singur; cu Nginx, se ocupă Certbot.
6. Secretele: într-un fișier de mediu pe care îl poate citi doar utilizatorul aplicației, în afara depozitului Git.
7. Baza de date: păstrați back-endul la furnizorul său sau instalați-l pe serverul dumneavoastră. O aplicație Supabase are nevoie, pe lângă baza PostgreSQL, de autentificare, stocare, timp real și funcții: Supabase self-hosted le reunește.
8. Adresele de redirecționare: adăugați domeniul dumneavoastră la URL-urile autorizate ale autentificării, precum și la Google sau GitHub dacă back-endul își schimbă adresa.
9. Backupurile: baza de date și fișierele în fiecare noapte, copiate în afara serverului, și din când în când o restaurare de probă.

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;
    }
}

De ce are nevoie ca să reziste

O aplicație online trăiește: dependențele ei primesc corecturi, baza de date crește, traficul se schimbă. Ceea ce o păstrează rapidă și sigură se rezumă la o rutină:

Această rutină este meseria unui administrator de sistem și se poate încredința. Cu un Managed VPS, furnizorul de găzduire ține serverul la zi, îl monitorizează zi și noapte și intervine fără să vă aștepte apelul. Vă urmărește proactiv și aplicația (erori, încetiniri, interogări costisitoare, spațiu pe disc) și vă recomandă corecția: o aplicați cu propriul asistent AI, așa cum ați construit aplicația, și păstrați controlul asupra codului.