Alojar una aplicación creada con IA: de Lovable o Bolt a su servidor

Dónde funciona hoy su aplicación

Lovable, Bolt y Replit publican la aplicación en su propia infraestructura, con un clic. Esto es lo que dice su documentación, consultada en octubre de 2026:

v0 publica en un proyecto de Vercel y genera una aplicación Next.js (React, TypeScript, Tailwind CSS); el código se exporta, o se sincroniza con GitHub en ambos sentidos. Cursor es un editor y un agente de programación instalado en su ordenador: el código ya está ahí, y el hosting queda por completo a su elección.

Estos hostings integrados están pensados para publicar rápido. Tanto en Lovable como en Replit, la versión en línea es una instantánea que se renueva con cada publicación, y el coste sigue al uso de la plataforma (en Lovable, unos créditos cubren la actividad del backend y la IA; en Replit, el plan Starter incluye una aplicación publicada, que caduca a los 30 días y se vuelve a publicar). Se pasa a un servidor propio para tener un dominio y unos datos bajo su control, recursos reservados, tareas permanentes en segundo plano o requisitos de cumplimiento normativo.

Recuperar el código y los datos

Lo más seguro es vincular el proyecto a un repositorio de GitHub: cada modificación llega a él como un commit, con todo el historial. En Lovable, la sincronización funciona en ambos sentidos: usted sigue construyendo en Lovable mientras su servidor sirve la aplicación.

1. Lovable: vincule el proyecto a GitHub, GitLab o Bitbucket, o descargue el archivo .zip del código (suscripción de pago).
2. Bolt: conecte GitHub, o haga clic en el título del proyecto, arriba a la izquierda, y después en «Download».
3. Replit: menú de tres puntos en la parte superior del árbol de archivos y, después, «Download as zip»; o la herramienta Git, vinculada a su cuenta de GitHub, con la sincronización automática.
4. v0: conecte GitHub desde el menú del proyecto («Settings» y después «GitHub»), o exporte el código.

El código no contiene ni el contenido de la base de datos ni los archivos enviados por sus usuarios. En Lovable, la base de datos se exporta desde el proyecto en un archivo .backup, que se restaura con pg_restore, y los archivos del almacenamiento se descargan aparte. En Bolt, la base de datos puede vincularse a su propia cuenta de Supabase (planes Pro y Teams).

De qué está hecha su aplicación

Abra el archivo package.json: indica en qué se basa la aplicación y, por tanto, qué debe ejecutar su servidor.

Con Vite, toda variable cuyo nombre empiece por VITE_ se integra en el código enviado al navegador, en el momento del build: cualquier visitante puede leerla, y cambiar su valor exige un nuevo build. Es lo previsto para la clave pública de Supabase (sb_publishable_…, o la antigua anon), hecha para el navegador y regida por las reglas de seguridad a nivel de fila (RLS). La clave secreta (sb_secret_…, o la antigua service_role) se salta esas reglas: se queda en el servidor, sin prefijo VITE_.

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

Active RLS en cada tabla antes de la puesta en línea: son sus reglas las que protegen sus datos mientras la clave pública circula por el navegador.

Llevarla a su propio servidor, paso a paso

En un VPS con Linux, la puesta en línea sigue siempre el mismo orden. Lovable recomienda Node.js 22 para construir y ejecutar sus aplicaciones.

1. El build: clone el repositorio en el servidor y ejecute npm install y npm run build. Una aplicación Vite genera archivos estáticos en dist/; una aplicación TanStack Start se construye con NITRO_PRESET=node-server npm run build y arranca con node .output/server/index.mjs, en el puerto 3000; una aplicación Next.js arranca con npm run start.
2. El proceso: para una aplicación con servidor, un servicio systemd la arranca con la máquina y la vuelve a lanzar si se detiene.
3. El servidor web: Nginx o Caddy recibe a los visitantes. Para una aplicación Vite, devuelve index.html ante cualquier dirección desconocida; si no, una página recargada responde 404. Para una aplicación con servidor, transmite las peticiones al proceso Node.js.
4. El nombre de dominio: un registro DNS A (y AAAA para IPv6) apunta al servidor.
5. El HTTPS: un certificado de Let's Encrypt, gratuito. Caddy lo obtiene y lo renueva por sí mismo; con Nginx, se encarga Certbot.
6. Los secretos: en un archivo de entorno que solo pueda leer el usuario de la aplicación, fuera del repositorio Git.
7. La base de datos: mantenga el backend en su proveedor, o instálelo en su servidor. Una aplicación Supabase necesita, junto a su base PostgreSQL, la autenticación, el almacenamiento, el tiempo real y las funciones: Supabase autoalojado los reúne.
8. Las direcciones de redirección: añada su dominio a las URL autorizadas de la autenticación, y en Google o GitHub si el backend cambia de dirección.
9. Las copias de seguridad: la base de datos y los archivos cada noche, copiados fuera del servidor, y una restauración de prueba de vez en cuando.

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

Lo que hace falta para que se mantenga

Una aplicación en línea está viva: sus dependencias reciben parches, su base de datos crece, su tráfico cambia. Lo que la mantiene rápida y segura cabe en una rutina:

Esta rutina es el oficio de un administrador de sistemas, y se puede confiar. Con un VPS administrado, el proveedor mantiene el servidor al día, lo supervisa día y noche e interviene sin esperar su llamada. También sigue su aplicación de forma proactiva (errores, lentitud, consultas costosas, espacio en disco) y le recomienda la corrección: usted la aplica con su propio asistente de IA, igual que construyó la aplicación, y conserva el control de su código.