Puneți aplicația dumneavoastră din Lovable, Bolt sau alt constructor AI pe găzduirea dumneavoastră WebOké

Ați creat o aplicație cu Lovable, Bolt sau un alt constructor AI și doriți să o publicați pe propriul domeniu la WebOké? Este posibil. În acest articol aflați cum să extrageți codul din constructorul AI, cum să compilați și să încărcați aplicația și cum GitHub poate face acest lucru automat pentru dumneavoastră.

1. Ce tip de aplicație aveți?

Deschideți fișierul package.json din proiectul dvs. Din acesta vedeți ce tip de aplicație este.

• O aplicație statică (React cu Vite). În package.json apare vite și niciun framework de server. Cu npm run build creați un folder dist cu fișiere obișnuite HTML, JavaScript și CSS. Pe acestea le încărcați în public_html. Acest lucru funcționează pe orice pachet de găzduire. Multe aplicații din Bolt și aplicațiile mai vechi din Lovable sunt construite astfel.
• O aplicație cu server propriu. Începând cu 13 mai 2026, Lovable creează aplicații cu TanStack Start: în acest caz, în package.json apare @tanstack/react-start. O astfel de aplicație rulează cod pe server și, prin urmare, nu funcționează ca fișiere separate în public_html. O configurați ca aplicație Node.js (consultați punctul 6). Același lucru este valabil și pentru alte aplicații cu server propriu, cum ar fi un backend Express.
• O aplicație cu Supabase sau Lovable Cloud ca backend. Baza de date, autentificarea și funcțiile rămân în acest caz la Supabase sau Lovable. Pe WebOké publicați doar partea vizibilă (front-end-ul). La compilare trebuie însă să furnizați adresa și cheia publică Supabase (consultați punctul 5).

2. Extragerea codului din constructorul AI prin GitHub

Lovable și Bolt pot plasa proiectul dvs. într-un repository GitHub propriu. Modificările circulă atunci în ambele direcții: ce modificați în constructorul AI ajunge în GitHub, iar ce modificați în GitHub revine în constructorul AI.

În Lovable:

1. Deschideți proiectul și accesați Project settings > Git > GitHub.
2. Faceți clic pe Add connection și acordați aplicației Lovable acces la contul dvs. GitHub.
3. La Accounts, faceți clic pe Connect. Lovable creează un repository privat și îl menține actualizat.

Se poate și fără GitHub: cu Download codebase din Project settings > Git descărcați codul (cu un abonament Lovable plătit).

În Bolt:

1. Deschideți proiectul și faceți clic pe pictograma GitHub din dreapta sus.
2. Autentificați-vă în GitHub, faceți clic pe Authorize și instalați aplicația GitHub a Bolt.
3. Introduceți un nume pentru repository și faceți clic pe Create repository. Ulterior, Bolt lucrează în branch-ul main.

3. Compilarea și încărcarea unei aplicații statice

Compilați aplicația pe propriul calculator. Pentru aceasta aveți nevoie de Node.js, versiunea 22 (versiunea actuală Vite necesită minimum 20.19 sau 22.12).

1. Obțineți codul: git clone al repository-ului dvs. sau dezarhivați fișierul descărcat.
2. Deschideți un terminal în folderul proiectului și instalați pachetele cu npm ci (sau npm install dacă nu există un package-lock.json).
3. Compilați aplicația cu npm run build. Acum există un folder dist cu un index.html și un folder assets.
4. Încărcați conținutul folderului dist în domains/domeniuldvs.nl/public_html, cu un program FTP sau cu File Manager din DirectAdmin. Nu încărcați, așadar, folderul dist în sine și nici codul sursă sau node_modules.
5. Plasați fișierul .htaccess de mai jos în public_html.

O aplicație cu mai multe pagini (un router) afișează în browser adrese precum domeniuldvs.nl/despre-noi. Aceste pagini nu există ca fișiere pe server. Dacă reîncărcați o astfel de pagină sau deschideți direct linkul, primiți o eroare 404. Cu acest fișier .htaccess, serverul redirecționează aceste adrese către index.html, iar aplicația afișează apoi pagina corectă:

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^assets/ - [R=404,L]
RewriteRule ^ index.html [L]

Fișierele și folderele existente sunt afișate normal de server. Un fișier lipsă din assets returnează o eroare 404 reală, astfel încât observați mai ușor o greșeală. Toate celelalte adrese sunt direcționate către aplicație.

4. Plasarea aplicației într-un subfolder

Doriți ca aplicația să nu fie pe domeniuldvs.nl, ci pe domeniuldvs.nl/app? Atunci aplicația trebuie să știe acest lucru încă de la compilare. Altfel, browserul caută fișierele în /assets în loc de /app/assets, iar ecranul rămâne alb.

1. Setați în vite.config.js (sau vite.config.ts) opțiunea base: '/app/'.
2. Transmiteți routerului aceeași cale. În React Router faceți acest lucru cu <BrowserRouter basename={import.meta.env.BASE_URL}>.
3. Compilați din nou și încărcați conținutul folderului dist în public_html/app.
4. Plasați în public_html/app/.htaccess același fișier ca mai sus, cu RewriteBase /app/.

5. Supabase, Lovable Cloud și alte setări (variabile env)

Setările care încep cu VITE_, precum VITE_SUPABASE_URL și VITE_SUPABASE_PUBLISHABLE_KEY (în proiectele mai vechi VITE_SUPABASE_ANON_KEY), sunt incluse de Vite în fișierele JavaScript la build. Ulterior nu le mai puteți configura pe server.

• Valorile le găsiți în fișierul .env al proiectului dumneavoastră. Preluați numele exact așa cum sunt.
• Dacă fișierul .env nu există în proiectul dumneavoastră, creați-l în folderul proiectului înainte de a rula npm run build. În GitHub Actions le setați ca secret (consultați punctul 7).
• Dacă ați modificat o valoare, refaceți build-ul aplicației și încărcați-o din nou.

6. O aplicație cu server propriu: ca aplicație Node.js

O aplicație cu cod de server, precum o aplicație TanStack Start din Lovable, o configurați cu Setup Node.js App în DirectAdmin. Cum funcționează aceasta puteți citi în Activarea Node.js în DirectAdmin. Pentru o aplicație TanStack Start procedați astfel:

1. Faceți build-ul aplicației pe computerul dumneavoastră cu NITRO_PRESET=node-server npm run build. Acum există un folder .output.
2. Creați o aplicație în Setup Node.js App, cu Node.js 22 și un folder în afara public_html, de exemplu apps/myapp.
3. Încărcați folderul .output în acel folder.
4. Creați în același folder un fișier start.cjs cu acest singur rând și completați start.cjs la Application startup file:

   import('./.output/server/index.mjs');

5. Setați configurările de care are nevoie serverul, precum SUPABASE_URL și SUPABASE_PUBLISHABLE_KEY, la Environment variables.
6. Faceți clic pe Restart. Faceți acest lucru și după fiecare încărcare nouă.

Fișierul start.cjs este necesar deoarece serverul din .output este un modul JavaScript modern (.mjs), iar mediul Node.js încarcă fișierul de pornire în modul vechi. Dacă aplicația returnează o eroare 503, verificați stderr.log în folderul aplicației dumneavoastră.

7. Implementare automată cu GitHub Actions

Cu GitHub Actions, GitHub construiește aplicația dvs. la fiecare modificare din branch-ul main și pune rezultatul pe pachetul dvs. Deoarece Lovable și Bolt scriu în GitHub, o modificare făcută în generatorul AI ajunge online după câteva minute. Funcția Git din DirectAdmin nu construiește nimic, ci doar plasează fișiere; de aceea, pentru o aplicație Vite, GitHub Actions este mai practic.

Parolele și cheile nu le puneți niciodată în repository, ci ca secret în GitHub:

1. Deschideți repository-ul dvs. pe GitHub și accesați Settings > Secrets and variables > Actions.
2. Faceți clic pe New repository secret, completați numele și valoarea, apoi faceți clic pe Add secret. Repetați pentru fiecare secret din varianta pe care o alegeți.
3. Creați în repository fișierul .github/workflows/deploy.yml cu unul dintre cele două exemple de mai jos.
4. După următoarea modificare, verificați în fila Actions dacă a reușit. Cu Run workflow îl puteți porni și manual.

Varianta A: prin FTPS (toate pachetele de hosting). Creați în DirectAdmin un cont FTP separat pentru GitHub, cu opțiunea Domain la Root directory (consultați Cum funcționează FTP la WebOké?). Secrete: FTP_SERVER (numele serverului pachetului dvs., de exemplu linux2023.webawere.nl, nu numele domeniului dvs.), FTP_USERNAME (numele complet, de exemplu github@domeniuldvs.nl), FTP_PASSWORD și valorile VITE_ ale aplicației dvs.

name: Build and deploy

on:
  push:
    branches: [main]
  workflow_dispatch:

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run build
        env:
          VITE_SUPABASE_URL: ${{ secrets.VITE_SUPABASE_URL }}
          VITE_SUPABASE_PUBLISHABLE_KEY: ${{ secrets.VITE_SUPABASE_PUBLISHABLE_KEY }}
      - uses: SamKirkland/FTP-Deploy-Action@v4.4.0
        with:
          server: ${{ secrets.FTP_SERVER }}
          username: ${{ secrets.FTP_USERNAME }}
          password: ${{ secrets.FTP_PASSWORD }}
          protocol: ftps
          port: 21
          local-dir: ./dist/
          server-dir: public_html/

Varianta B: prin SSH cu rsync (pachete cu SSH). SSH este inclus în Power Webhost Three și Four, AI Wordpress Three și Power Reseller, pe portul 1967 și doar cu cheie (consultați Acces SSH și Terminalul în DirectAdmin).

1. Creați pe computerul dvs. o cheie separată pentru GitHub, fără parolă: ssh-keygen -t ed25519 -f github-deploy -N "".
2. Puneți conținutul fișierului github-deploy.pub în DirectAdmin la SSH Keys > PASTE KEY.
3. Puneți conținutul fișierului github-deploy (cheia privată) în secretul SSH_PRIVATE_KEY. Apoi ștergeți fișierul de pe computerul dvs.
4. Rulați ssh-keyscan -p 1967 linux2023.webawere.nl și puneți rezultatul în secretul SSH_KNOWN_HOSTS. Astfel, GitHub verifică faptul că se conectează într-adevăr la serverul dvs.
5. Adăugați ca secrete și SSH_HOST (numele serverului), SSH_USER (numele dvs. de utilizator DA), DOMEIN (de exemplu domeniuldvs.nl) și valorile VITE_.

name: Build and deploy

on:
  push:
    branches: [main]
  workflow_dispatch:

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run build
        env:
          VITE_SUPABASE_URL: ${{ secrets.VITE_SUPABASE_URL }}
          VITE_SUPABASE_PUBLISHABLE_KEY: ${{ secrets.VITE_SUPABASE_PUBLISHABLE_KEY }}
      - name: Deploy
        env:
          SSH_KEY: ${{ secrets.SSH_PRIVATE_KEY }}
          SSH_KNOWN_HOSTS: ${{ secrets.SSH_KNOWN_HOSTS }}
          SSH_HOST: ${{ secrets.SSH_HOST }}
          SSH_USER: ${{ secrets.SSH_USER }}
          DOMEIN: ${{ secrets.DOMEIN }}
        run: |
          mkdir -p ~/.ssh
          printf '%s\n' "$SSH_KEY" > ~/.ssh/deploy_key
          chmod 600 ~/.ssh/deploy_key
          printf '%s\n' "$SSH_KNOWN_HOSTS" > ~/.ssh/known_hosts
          rsync -rlptz --delete --exclude=.well-known --exclude=cgi-bin \
            -e "ssh -p 1967 -i ~/.ssh/deploy_key" \
            dist/ "$SSH_USER@$SSH_HOST:domains/$DOMEIN/public_html/"

Dacă nu folosiți Supabase, eliminați rândurile cu VITE_SUPABASE sau înlocuiți-le cu variabilele VITE_ ale propriei aplicații. Dacă autentificarea eșuează de câteva ori, serverul blochează temporar adresa IP a GitHub. În acest caz, verificați secretele și porniți din nou workflow-ul.

8. Erori frecvente

• Pagina principală funcționează, dar la reîmprospătare sau la accesarea unui link direct apare o eroare 404. Fișierul .htaccess de la punctul 3 lipsește sau se află în directorul greșit.
• Un ecran alb. Deschideți instrumentele pentru dezvoltatori ale browserului dvs. (F12) și verificați la Console sau Network. Vedeți erori 404 pentru fișierele din /assets? Atunci calea nu este corectă: ați încărcat chiar directorul dist în loc de conținutul acestuia, sau aplicația se află într-un subdirector fără setarea base corectă (punctul 4).
• Aplicația se încarcă, dar autentificarea sau datele nu funcționează, sau vedeți un mesaj precum supabaseUrl is required. Variabilele VITE_ nu erau disponibile la build. Adăugați-le în .env sau ca secret și refaceți build-ul.
• Build-ul eșuează cu un mesaj despre versiunea Node.js. Folosiți Node.js 22, atât pe computerul dvs., cât și în workflow (node-version: 22).
• npm ci eșuează. Nu există un fișier package-lock.json, de exemplu pentru că proiectul are doar un bun.lock. Rulați o dată npm install și adăugați noul package-lock.json în repository-ul dvs.
• Build-ul nu conține niciun index.html. În acest caz este vorba de o aplicație cu propriul server, precum TanStack Start. Configurați-o ca aplicație Node.js (punctul 6).

Consultați și: Conectarea cu FileZilla (FTP, FTPS și SFTP) și Chei SSH și autentificarea prin SSH.

Explicații detaliate cu capturi de ecran: Configurarea unei aplicații Node.js în ghidul DirectAdmin.