Хостване на приложение, създадено с AI: от Lovable или Bolt до вашия сървър

Къде работи приложението ви днес

Lovable, Bolt и Replit публикуват приложението на собствената си инфраструктура с едно кликване. Ето какво казва тяхната документация, прегледана през октомври 2026 г.:

v0 публикува в проект на Vercel и генерира приложение на Next.js (React, TypeScript, Tailwind CSS); кодът се експортира или се синхронизира с GitHub в двете посоки. Cursor е редактор и агент за програмиране, инсталиран на компютъра ви: кодът вече е там, а хостингът остава изцяло по ваш избор.

Тези вградени хостинги са замислени за бързо публикуване. И при Lovable, и при Replit онлайн версията е моментна снимка, подновявана при всяко публикуване, а цената следва употребата на платформата (при Lovable кредити покриват дейността на бекенда и AI; при Replit планът Starter включва едно публикувано приложение, което изтича след 30 дни и се публикува отново). Преминава се на собствен сървър заради домейн и данни под ваш контрол, запазени ресурси, постоянни фонови задачи или изисквания за съответствие.

Вземане на кода и данните

Най-сигурно е проектът да се свърже с хранилище в GitHub: всяка промяна пристига там като commit, с цялата история. При Lovable синхронизацията работи в двете посоки: продължавате да изграждате в Lovable, докато сървърът ви обслужва приложението.

1. Lovable: свържете проекта с GitHub, GitLab или Bitbucket или изтеглете архива .zip с кода (платен абонамент).
2. Bolt: свържете GitHub или щракнете върху заглавието на проекта горе вляво, после върху „Download“.
3. Replit: менюто с три точки в горната част на дървото с файлове, после „Download as zip“; или инструментът Git, свързан с акаунта ви в GitHub, с автоматичната синхронизация.
4. v0: свържете GitHub от менюто на проекта („Settings“, после „GitHub“) или експортирайте кода.

Кодът не съдържа нито съдържанието на базата, нито файловете, качени от потребителите ви. При Lovable базата се експортира от проекта като файл .backup, който се възстановява с pg_restore, а файловете от хранилището се изтеглят отделно. При Bolt базата може да се свърже със собствения ви акаунт в Supabase (планове Pro и Teams).

От какво е направено приложението ви

Отворете файла package.json: той показва на какво се крепи приложението и следователно какво трябва да изпълнява сървърът ви.

С Vite всяка променлива, чието име започва с VITE_, се вгражда в кода, изпратен до браузъра, в момента на build: всеки посетител може да я прочете, а промяната на стойността ѝ изисква нов build. Това е предвидено за публичния ключ на Supabase (sb_publishable_… или старият anon), направен за браузъра и ограничен от правилата за сигурност на ниво ред (RLS). Тайният ключ (sb_secret_… или старият service_role) заобикаля тези правила: той остава на сървъра, без префикс VITE_.

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

Включете RLS за всяка таблица преди пускането онлайн: именно неговите правила защитават данните ви, докато публичният ключ циркулира в браузъра.

Преместване на собствен сървър, стъпка по стъпка

На VPS с Linux пускането онлайн винаги следва един и същ ред. Lovable препоръчва Node.js 22 за изграждане и изпълнение на своите приложения.

1. Build: клонирайте хранилището на сървъра, след това изпълнете npm install и npm run build. Приложение с Vite генерира статични файлове в dist/; приложение с TanStack Start се изгражда с NITRO_PRESET=node-server npm run build и стартира с node .output/server/index.mjs, на порт 3000; приложение с Next.js стартира с npm run start.
2. Процесът: за приложение със сървър услуга на systemd го стартира заедно с машината и го рестартира, ако спре.
3. Уеб сървърът: Nginx или Caddy приема посетителите. За приложение с Vite той връща index.html за всеки непознат адрес, иначе опреснена страница отговаря с 404; за приложение със сървър той предава заявките на процеса на Node.js.
4. Домейнът: DNS запис A (и AAAA за IPv6) сочи към сървъра.
5. HTTPS: сертификат от Let's Encrypt, безплатен. Caddy го получава и подновява сам; с Nginx това поема Certbot.
6. Тайните: във файл на средата, четим само от потребителя на приложението, извън Git хранилището.
7. Базата данни: оставете бекенда при неговия доставчик или го инсталирайте на сървъра си. Приложение със Supabase има нужда освен от базата PostgreSQL и от удостоверяване, хранилище, реално време и функции: самостоятелно хостваният Supabase ги обединява.
8. Адресите за пренасочване: добавете домейна си към разрешените URL адреси на удостоверяването, както и при Google или GitHub, ако бекендът смени адреса си.
9. Резервните копия: базата и файловете всяка нощ, копирани извън сървъра, и от време на време пробно възстановяване.

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

Какво е нужно, за да издържи

Приложението онлайн живее: зависимостите му получават корекции, базата му расте, трафикът му се променя. Това, което го поддържа бързо и сигурно, се събира в една рутина:

Тази рутина е занаят на системния администратор и може да бъде поверена. С управляван VPS (Managed VPS) хостинг доставчикът поддържа сървъра актуален, наблюдава го денем и нощем и се намесва, без да чака обаждането ви. Той следи проактивно и приложението ви (грешки, забавяния, ресурсоемки заявки, дисково пространство) и ви препоръчва корекцията: прилагате я с вашия AI асистент, както сте изградили приложението, и кодът остава във вашите ръце.