Hosting aplikacji stworzonej przez AI: z Lovable lub Bolt na Państwa serwer

Gdzie Państwa aplikacja działa dziś

Lovable, Bolt i Replit publikują aplikację na własnej infrastrukturze, jednym kliknięciem. Oto, co mówi ich dokumentacja, sprawdzona w październiku 2026:

v0 publikuje w projekcie Vercel i generuje aplikację Next.js (React, TypeScript, Tailwind CSS); kod można wyeksportować albo synchronizować z GitHubem w obu kierunkach. Cursor to edytor i agent programistyczny zainstalowany na Państwa komputerze: kod już tam jest, a wybór hostingu należy w całości do Państwa.

Te zintegrowane hostingi są pomyślane z myślą o szybkiej publikacji. Zarówno w Lovable, jak i w Replit wersja online to migawka, odnawiana przy każdej publikacji, a koszt zależy od zużycia platformy (w Lovable kredyty pokrywają aktywność backendu i AI; w Replit plan Starter obejmuje jedną opublikowaną aplikację, która wygasa po 30 dniach i wymaga ponownej publikacji). Na własny serwer przechodzi się, by mieć domenę i dane pod własną kontrolą, dedykowane zasoby, stałe zadania w tle lub spełnić wymogi zgodności.

Pobranie kodu i danych

Najpewniej jest połączyć projekt z repozytorium GitHub: każda zmiana trafia tam jako commit, z całą historią. W Lovable synchronizacja działa w obu kierunkach: mogą Państwo dalej budować w Lovable, podczas gdy Państwa serwer udostępnia aplikację.

1. Lovable: proszę połączyć projekt z GitHubem, GitLabem lub Bitbucketem albo pobrać archiwum .zip z kodem (płatny abonament).
2. Bolt: proszę połączyć GitHub albo kliknąć tytuł projektu w lewym górnym rogu, a potem „Download”.
3. Replit: menu z trzema kropkami nad drzewem plików, a potem „Download as zip”; albo narzędzie Git, połączone z Państwa kontem GitHub, z automatyczną synchronizacją.
4. v0: proszę połączyć GitHub z menu projektu („Settings”, potem „GitHub”) albo wyeksportować kod.

Kod nie zawiera ani zawartości bazy, ani plików przesłanych przez Państwa użytkowników. W Lovable bazę eksportuje się z poziomu projektu do pliku .backup, który przywraca się poleceniem pg_restore, a pliki z pamięci masowej pobiera się osobno. W Bolt bazę można podłączyć do własnego konta Supabase (plany Pro i Teams).

Z czego składa się Państwa aplikacja

Proszę otworzyć plik package.json: mówi on, na czym opiera się aplikacja, a więc co musi uruchamiać Państwa serwer.

W Vite każda zmienna, której nazwa zaczyna się od VITE_, zostaje wbudowana w kod wysyłany do przeglądarki w chwili budowania: każdy odwiedzający może ją odczytać, a zmiana jej wartości wymaga ponownego zbudowania. Tak ma być w przypadku publicznego klucza Supabase (sb_publishable_… lub starszego anon), przeznaczonego dla przeglądarki i ograniczonego regułami bezpieczeństwa na poziomie wierszy (RLS). Klucz tajny (sb_secret_… lub starszy service_role) omija te reguły: pozostaje na serwerze, bez prefiksu VITE_.

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

Proszę włączyć RLS dla każdej tabeli przed uruchomieniem aplikacji: to jego reguły chronią Państwa dane, gdy klucz publiczny krąży w przeglądarce.

Przeniesienie na własny serwer, krok po kroku

Na VPS z Linuksem uruchomienie przebiega zawsze w tej samej kolejności. Lovable zaleca Node.js 22 do budowania i uruchamiania swoich aplikacji.

1. Budowanie: proszę sklonować repozytorium na serwer, a następnie uruchomić npm install i npm run build. Aplikacja Vite generuje pliki statyczne w katalogu dist/; aplikację TanStack Start buduje się poleceniem NITRO_PRESET=node-server npm run build i uruchamia poleceniem node .output/server/index.mjs, na porcie 3000; aplikację Next.js uruchamia się poleceniem npm run start.
2. Proces: w przypadku aplikacji z serwerem usługa systemd uruchamia ją razem z maszyną i restartuje, jeśli się zatrzyma.
3. Serwer WWW: Nginx lub Caddy przyjmuje odwiedzających. W przypadku aplikacji Vite zwraca index.html dla każdego nieznanego adresu, bo inaczej odświeżona strona odpowie błędem 404; w przypadku aplikacji z serwerem przekazuje żądania do procesu Node.js.
4. Nazwa domeny: rekord DNS A (oraz AAAA dla IPv6) wskazuje na serwer.
5. HTTPS: bezpłatny certyfikat Let's Encrypt. Caddy uzyskuje go i odnawia samodzielnie; przy Nginx zajmuje się tym Certbot.
6. Sekrety: w pliku środowiskowym czytelnym wyłącznie dla użytkownika aplikacji, poza repozytorium Git.
7. Baza danych: backend może zostać u swojego dostawcy albo trafić na Państwa serwer. Aplikacja Supabase potrzebuje, oprócz bazy PostgreSQL, uwierzytelniania, pamięci masowej, czasu rzeczywistego i funkcji: Supabase self-hosted łączy je wszystkie.
8. Adresy przekierowań: proszę dodać swoją domenę do dozwolonych adresów URL uwierzytelniania, a także w Google lub GitHub, jeśli backend zmienia adres.
9. Kopie zapasowe: baza i pliki co noc, kopiowane poza serwer, a od czasu do czasu próbne przywrócenie.

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

Czego potrzeba, by aplikacja działała stabilnie

Aplikacja online żyje: jej zależności dostają poprawki, baza rośnie, ruch się zmienia. To, co utrzymuje ją szybką i bezpieczną, sprowadza się do stałej rutyny:

Ta rutyna to praca administratora systemów i można ją powierzyć. Z Managed VPS firma hostingowa utrzymuje serwer w aktualności, nadzoruje go dniem i nocą i interweniuje bez czekania na Państwa telefon. Proaktywnie czuwa także nad Państwa aplikacją (błędy, spowolnienia, kosztowne zapytania, przestrzeń dyskowa) i poleca Państwu poprawkę: wdrażają ją Państwo za pomocą własnego asystenta AI, tak jak zbudowali Państwo aplikację, i zachowują kontrolę nad swoim kodem.