TL;DR

• Open Lovable v3 es una aplicación de Next.js autoalojada que captura una página de origen autorizada, pide a un modelo de IA que genere código y ejecuta el resultado en un sandbox de Vercel o E2B.
• La aplicación anfitriona utiliza actualmente Next.js 15 y React 19, mientras que su andamiaje de vista previa generado aún usa Vite y React 18; tratarlos como una sola pila conduce a soluciones engañosas.
• El repositorio oficial requiere una clave de Firecrawl, al menos un proveedor de IA y un proveedor de sandbox. "Código abierto" no significa que los servicios dependientes sean gratuitos o autoalojados.
• Un clon es una implementación inicial, no prueba de precisión visual, comportamiento responsivo, accesibilidad, dependencias limpias o permiso para reutilizar el diseño de otra persona.
• Nstproxy Crawl puede servir como la capa de captura y validación en un fork personalizado, pero no es un reemplazo directo para las rutas específicas de Firecrawl actuales de Open Lovable.

---

Introducción: Open Lovable tiene tres sistemas para operar

Open Lovable solo funciona cuando la captura de páginas, la generación de IA y la ejecución en sandbox están de acuerdo en un contrato utilizable. La demostración pulida oculta esos límites: un scraper debe devolver suficiente contexto de origen, el modelo debe emitir código compilable y el sandbox debe instalar y ejecutar ese código. Nstproxy Crawl puede reemplazar la capa de captura en un fork, pero cambiar un nombre de variable de entorno no reconfigurará la aplicación.

Este tutorial usa la instantánea del repositorio oficial en el commit 69bd93b, cuyo último commit está etiquetado como v3. Instalamos sus dependencias bloqueadas, construimos la aplicación de Next.js, iniciamos el servidor de desarrollo y solicitamos la página de inicio antes de escribir los pasos a continuación.

¿Qué es Open Lovable?

Open Lovable es una aplicación de ejemplo con licencia MIT del equipo de Firecrawl que convierte una URL de origen y instrucciones de chat en una interfaz React generada. El repositorio oficial de Open Lovable lo describe como un constructor de aplicaciones React asistido por IA, no como un sistema de migración de producción.

La arquitectura actual tiene cuatro capas distintas:

La distinción es importante porque un raspado exitoso no prueba que el proyecto generado funcione. Igualmente, una vista previa de sandbox puede compilar mientras aún falta comportamiento interactivo, puntos de ruptura responsivos, fuentes, análisis o estado del backend. Para obtener más información sobre la captura de páginas renderizadas, consulta la explicación de navegador sin cabeza.

¿Por qué usar Open Lovable en lugar de Lovable.dev?

Open Lovable es útil cuando deseas visibilidad de fuente y control sobre la aplicación anfitriona; Lovable.dev es un producto gestionado para construir y operar aplicaciones a través de un flujo de trabajo alojado. Sus nombres similares no los hacen intercambiables.

La elección práctica se trata de la propiedad. Open Lovable te da más código e infraestructura para inspeccionar; Lovable.dev elimina más configuración. Ninguno de los caminos convierte un lenguaje visual copiado en propiedad intelectual reutilizable automáticamente.

## Tutorial Detallado

El flujo de trabajo más seguro de Open Lovable verifica cada límite por separado antes de que pidas al modelo que recree una página autorizada.

Método 1: Ejecutar el repositorio oficial de Open Lovable v3

Paso 1: Confirmar la cadena de herramientas local

Utiliza una versión LTS de Node.js que esté actualmente soportada en lugar de la antigua recomendación de Node.js 18 que se encuentra en algunos tutoriales; Node.js ahora marca la versión 18 como fuera de soporte en su página oficial de descargas. También necesitas Git y un gestor de paquetes. Verificamos el repositorio con Node.js 24, pnpm 11 y Git 2.39.

node --version
pnpm --version
git --version

Paso 2: Clonar el repositorio y respetar el archivo de bloqueo

Clona la fuente oficial, luego instala el gráfico de dependencias exacto registrado por el repositorio.

git clone https://github.com/firecrawl/open-lovable.git
cd open-lovable
pnpm install --frozen-lockfile

En un corredor que bloquea scripts de construcción de dependencias, pnpm puede marcar paquetes como sharp o un resolutor nativo. No apruebes todos los scripts de forma global. Revisa el paquete nombrado, su versión bloqueada y por qué el proyecto necesita su gancho de instalación, luego aprueba solo los scripts necesarios según la política de tu organización.

Paso 3: Crear un archivo de entorno mínimo

Copia .env.example a .env.local, pero mantén solo una ruta configurada para la primera ejecución. La fuente actual acepta una clave de AI Gateway o credenciales individuales de Anthropic, OpenAI, Gemini o Groq. También incluye ediciones opcionales asistidas por Morph.

FIRECRAWL_API_KEY=TU_CLAVE_FIRECRAWL

ANTHROPIC_API_KEY=TU_CLAVE_ANTHROPIC

SANDBOX_PROVIDER=vercel
VERCEL_OIDC_TOKEN=TU_TOKEN_VERCEL_OIDC

Nunca cometas .env.local. Mantén las claves del proveedor en el lado del servidor y evita pegar cookies de producción, páginas privadas o datos de clientes en un aviso de recreación.

Paso 4: Elegir explícitamente el sandbox

Configura SANDBOX_PROVIDER=vercel o SANDBOX_PROVIDER=e2b; no te bases en un valor por defecto implícito. El README y .env.example llaman a Vercel como el valor por defecto, mientras que una fábrica de sandboxes compartida en la fuente probada aún recurre a E2B cuando la variable está ausente. Un valor explícito elimina esa ambigüedad.

Para la autenticación de desarrollo de Vercel, el repositorio te instruye a vincular el proyecto y obtener la configuración del entorno. Para E2B, proporciona E2B_API_KEY en su lugar; la documentación oficial de E2B confirma que su SDK crea sandboxes aislados usando esa variable de entorno.

Paso 5: Compilar antes de abrir la interfaz de usuario

Una construcción de producción detecta importaciones faltantes, problemas de tipo y fallos de compilación de rutas del servidor antes que un trabajo de generación interactivo.

pnpm build
pnpm dev

Luego verifica la shell local por separado:

curl -I http://127.0.0.1:3000/

Nuestra ejecución limpia devolvió HTTP 200 y un título HTML de Open Lovable v3. Una construcción restringida falló inicialmente porque next/font no pudo acceder a Google Fonts; permite esa salida, aloja las fuentes tú mismo, o reemplaza la configuración de fuentes remotas en CI restringido.

Paso 6: Recrear un objetivo autorizado y limitado

Comienza con una página que poseas, un fixture de staging, o un diseño explícitamente licenciado para reutilización. Elige una página de aterrizaje en lugar de una aplicación autenticada. Envía la URL HTTPS completa, deja que Open Lovable cree la vista previa inicial, y mantén el primer aviso limitado: preserva la jerarquía de contenido, recrea el diseño adaptable y evita inventar un comportamiento de backend.

No juzgues el resultado a partir de una sola captura de pantalla de escritorio. Prueba el viewport más pequeño y el más grande soportados, la navegación por teclado, menús, formularios, carga de imágenes, enlaces internos, y cualquier animación que comunique el estado.

Paso 7: Exportar código y aplicar puertas de aceptación

Trata el código exportado como una entrada generada no confiable. Inspecciona package.json, llamadas de red, acceso a variables de entorno, scripts en línea, activos remotos, licencias, y comandos de construcción antes de ejecutarlo o desplegarlo. Reemplaza la marca, el contenido, las imágenes, y el código de seguimiento de la fuente con activos que estás autorizado a usar.

Ejecuta una construcción de producción y una auditoría automática de la página después de tus ediciones. La documentación de Lighthouse de Google cubre auditorías de rendimiento, accesibilidad, mejores prácticas y SEO, pero la prueba manual de teclado y funcional sigue siendo necesaria.

Método 2: Usa Nstproxy Crawl en un fork personalizado de Open Lovable

Paso 1: Mantener la frontera de integración honesta

Nstproxy Crawl es un servicio de captura gestionado que puede renderizar JavaScript y devolver artefactos en Markdown, HTML, JSON, enlaces y PDF. Es útil cuando un equipo desea acceso potenciado por proxy, descubrimiento limitado y salidas de página repetibles sin operar trabajadores de navegador. El uso se factura por URL rastreada con éxito. Open Lovable no expone actualmente un interruptor genérico de proveedor de captura, por lo que Nstproxy Crawl no es un reemplazo directo de la variable de entorno; un fork debe adaptar las rutas del servidor relevantes y los campos de respuesta.

Paso 2: Reemplazar el contrato de captura, no la etiqueta

El repositorio probado llama a su proveedor de captura desde rutas para un scraping de URL mejorado, capturas de pantalla, extracción de estilo de marca, scraping de sitios web y búsqueda. Un adaptador creíble debe mapear cada consumidor en lugar de parchear solo la primera ruta de scraping.

• Fuente renderizada: Solicitar HTML limpio u otro formato que preserve el DOM para la generación de código; solo Markdown puede descartar señales de diseño que la solicitud necesita.
• Evidencia visual: Capturar una captura de pantalla o PDF para revisión lado a lado en lugar de asumir que la estructura del DOM generada implica fidelidad visual.
• Descubrimiento limitado: Al recrear más de una página, establecer profundidad explícita, límites de páginas y exclusiones para que las páginas de búsqueda, calendarios y variantes de consultas no amplíen inesperadamente el trabajo.

La guía de lanzamiento de Nstproxy Crawl explica el flujo de trabajo gestionado, mientras que la guía de scraping web con IA cubre cómo el contenido de la página entra en los modelos de tuberías en descenso.

Paso 3: Validar un adaptador con fixtures registrados

Guardar una página de origen autorizada, su respuesta de captura y el objeto normalizado que consume su fork de Open Lovable. Probar campos requeridos y estados de error antes de llamar al modelo. El adaptador debe distinguir entre una solicitud de proveedor que fue aceptada y una página que realmente fue recuperada, y debe preservar el estado HTTP, la URL final y los mensajes de diagnóstico sin filtrar credenciales.

Lo que nuestra verificación en entorno limpio encontró

El repositorio actual de Open Lovable se compila y sirve, pero el camino no es tan fluido como sugiere un inicio rápido de tres comandos. El archivo de bloqueo probado contenía 650 entradas e instaló 600 paquetes. Un envoltorio de política de paquetes detuvo la primera instalación porque los scripts de construcción nativos no estaban aprobados; después de revisar ese límite y restaurar los paquetes bloqueados, la compilación de producción de Next.js se completó.

La compilación también intentó descargar Inter y Roboto Mono a través de next/font. Con DNS saliente bloqueado, la compilación falló; con acceso a fuentes permitido, generó 33 páginas estáticas o rutas y se completó con éxito. ESLint informó que no pudo resolver eslint-plugin-react-hooks, sin embargo, Next.js continuó y devolvió el código de salida cero. Eso significa que "la compilación pasó" no es suficiente para una puerta de liberación: captura y falla en los diagnósticos de lint por separado.

Finalmente, el servidor de desarrollo se volvió listo en aproximadamente dos segundos, compiló la primera página a demanda y devolvió HTTP 200. No se probó la captura, generación de IA o creación de sandbox porque esas operaciones requieren credenciales de propiedad del usuario y servicios externos facturables. Este es el límite honesto entre verificar el shell de código abierto y verificar un clon completo.

Solución de problemas de Open Lovable por límite de falla

Los errores de Open Lovable son más fáciles de solucionar cuando se identifica cuál de los tres sistemas externos falló.

Evite registrar claves API o encabezados completos de proveedores mientras depura. Registre identificadores de solicitud no secretos, URL objetivo, elección del proveedor, marcas de tiempo y estados de error terminales. Para una visión más amplia de los límites de respuesta de API, consulte el glosario de API de Nstproxy.

Limites y uso responsable

Open Lovable no puede clonar de manera confiable cada sitio web porque una página visible en el navegador no es toda la aplicación. La autenticación, bases de datos, acciones del servidor, API privadas, lógica de pago, personalización, análisis y configuración de servicios de terceros no se recuperan de manera segura a partir del marcado renderizado. Las interacciones generadas pueden parecer plausibles mientras no hacen nada o llaman al endpoint incorrecto.

La licencia MIT se aplica al código fuente de Open Lovable, no a cada sitio web que se envíe a él. Los derechos de autor, marcas registradas, privacidad, contrato y términos del sitio siguen siendo aplicables al material fuente. Usa páginas que posees o para las que tienes permiso de reproducción, minimiza los datos capturados, elimina el seguimiento de terceros y revisa la guía legal y de cumplimiento de scraping web antes de ir más allá de un prototipo interno.

Conclusión: trata Open Lovable como un generador con contratos verificables

Open Lovable v3 es útil para convertir una referencia visual autorizada en código React editable, siempre que operes las capas de captura, IA y sandbox de manera deliberada. Clava el commit del repositorio, elige proveedores explícitamente, construye antes de la generación y rechaza cualquier exportación que no pase la revisión de dependencias, pruebas funcionales, comparación responsiva o chequeos de accesibilidad.

Comienza con una página que controles y mantén una captura de pantalla más una lista de verificación como base. Si la capa de captura es la carga operativa recurrente, prueba Nstproxy Crawl contra la misma página y mide la completitud antes de escribir un adaptador. Para forks que retienen su propio rastreador pero necesitan enrutamiento y diagnósticos de proxy centralizados, Nstproxy Proxy Manager es la otra capacidad relevante a evaluar.

Prueba la capa de captura antes de la generación de código

Usa una pequeña página autorizada para confirmar el contenido renderizado, artefactos y manejo de errores antes de gastar el uso del modelo y sandbox en una recreación completa.

Prueba Nstproxy gratis →

Preguntas frecuentes

P: ¿Qué es Open Lovable?

Open Lovable es una aplicación Next.js con licencia MIT que captura una página fuente autorizada, envía contexto a un modelo de IA y ejecuta el código React generado en un sandbox aislado. Es una aplicación de ejemplo del equipo de Firecrawl en lugar de la edición de código abierto de Lovable.dev.

P: ¿Es gratuito ejecutar Open Lovable?

El código fuente de Open Lovable está disponible bajo la licencia MIT, pero un flujo de generación funcional utiliza servicios externos de captura, IA y sandbox con su propia facturación basada en uso o suscripción. Operar la aplicación anfitriona también consume tu propio tiempo de cómputo e ingeniería.

P: ¿Puede Open Lovable ejecutarse localmente sin claves API?

La interfaz anfitriona puede iniciarse localmente sin claves de proveedor, como confirmó nuestra verificación HTTP 200, pero la captura de página, la generación de IA y la vista previa del sandbox requieren las credenciales correspondientes. Una página de inicio cargada no es prueba de que el flujo de trabajo de extremo a extremo esté configurado.

P: ¿Por qué menciona Open Lovable tanto a Next.js como a Vite?

El actual anfitrión de Open Lovable utiliza Next.js 15 y React 19, mientras que su ruta de sandbox en Vercel estructura la vista previa generada como una aplicación Vite utilizando React 18. Soluciona problemas del anfitrión y del proyecto generado como gráficos de dependencia separados.

P: ¿Puede Nstproxy Crawl reemplazar Firecrawl en Open Lovable?

Nstproxy Crawl puede reemplazar la capa de captura solo a través de un adaptador personalizado. El código fuente actual de Open Lovable llama a rutas y formas de respuesta específicas de Firecrawl, por lo que configurar un token de Nstproxy bajo FIRECRAWL_API_KEY no funcionará.

P: ¿Es legal clonar cualquier sitio web público con Open Lovable?

No. La accesibilidad pública no otorga permiso para copiar el código protegido, los activos de diseño, el texto, las marcas registradas o los datos personales de un sitio. Limita el uso a sitios que posees, plantillas con licencia, pruebas internas permitidas u otros casos revisados bajo la ley aplicable y los términos.