AIREITERLa promesa de Cursor con el lanzamiento de Build Live Apps del 5 de noviembre es sencilla: que las apps dejen de quedarse en localhost. Tras revisar el changelog, la documentación y las primeras dudas de usuarios, la conclusión es clara: funciona muy bien para herramientas internas y prototipos protegidos por Cursor SSO, pero todavía no es la opción adecuada para backends de producción complejos o sujetos a requisitos de cumplimiento.
Qué incluye Build Live Apps
Build Live Apps es un flujo de trabajo basado en agentes en la nube que convierte una petición en lenguaje natural en una aplicación web desplegada. Cursor anunció la función el 5 de noviembre de 2026 en su changelog, y la documentación de Apps describe el mismo recorrido: pedirle algo a un agente en la nube, previsualizarlo en una bandeja, elegir una URL, superar las comprobaciones de seguridad y publicar un enlace accesible.
La petición debe ser explícita. La documentación de Cursor indica que el prompt debe decirle al agente que cree una app. Puedes empezar desde cero en Cursor Origin, que genera un repositorio nuevo, o partir de un repositorio existente de GitHub para que Cursor lo despliegue. Solo los agentes en la nube pueden crear apps.
Cuando la aplicación necesita almacenamiento, Cursor aprovisiona una base de datos PostgreSQL. El alojamiento se realiza en una cuenta dedicada y aislada para cada usuario o equipo. La autenticación de las apps de equipo es Cursor SSO: los destinatarios deben iniciar sesión en Cursor antes de abrirlas. En los planes individuales también se pueden publicar apps públicas sin inicio de sesión.
Desde el primer día hay varios límites importantes. La compatibilidad con GitLab está prevista, pero todavía no está disponible. Los dominios personalizados tampoco están confirmados. Cursor afirma que quien publica elige un dominio único y la documentación añade que la URL puede cambiarse más adelante, pero ninguna de las dos páginas muestra un flujo para configurar un dominio propio.
Ninguna página detalla los frameworks, runtimes, regiones, versión de Postgres, copias de seguridad, comportamiento del escalado, cuotas de ancho de banda, límites de concurrencia o SLA. Además, el alojamiento está legalmente separado de los servicios de Cursor y se ofrece «tal cual» y «según disponibilidad»; Cursor se reserva el derecho a revocar o suspender un subdominio o una app.
El filtro de publicación: 4 comprobaciones obligatorias más la revisión de IA
Nada se publica hasta que el usuario confirma explícitamente la publicación. Preparar la app no la hace accesible. Cada publicación ejecuta cuatro comprobaciones obligatorias que permanecen activas aunque el equipo desactive la revisión de IA independiente:
- Bloquea la publicación si los archivos de la app contienen una clave API o un token de acceso.
- Bloquea archivos con credenciales, como claves privadas o claves de cuentas de servicio.
- Excluye los archivos
.envdel paquete publicado. - Elimina los mapas de código para impedir que los visitantes reconstruyan el código fuente original desde el navegador.
Si una comprobación falla, Cursor muestra el problema y permite pedirle al agente que lo corrija para volver a intentarlo.
La revisión de seguridad adicional basada en IA analiza los archivos de la aplicación y puede bloquear problemas graves antes de publicar. Los administradores de equipo pueden añadir instrucciones específicas de la organización al prompt de revisión. Esas instrucciones pueden incorporar reglas, pero no eliminar ni debilitar las comprobaciones integradas de Cursor. Los administradores pueden anular algunos bloqueos de publicación, aunque no pueden hacerlo cuando se trata de código malicioso, secretos codificados directamente o credenciales expuestas. Los cambios en estos ajustes aparecen en el registro de auditoría del equipo.
Lo que el filtro no demuestra es más importante que lo que sí detecta:
«El problema: superar las comprobaciones de seguridad no demuestra que tu app dé a las personas adecuadas el nivel de acceso adecuado». — @0node0, usuario real
Cursor menciona como ejemplos los secretos y las credenciales expuestas. No afirma que cada app reciba pruebas de autorización, comprobaciones de permisos por fila, cobertura frente a inyecciones SQL, análisis de dependencias o revisión de la lógica de negocio. El análisis de TechRepublic del 6 de noviembre llega a la misma conclusión: hay que probar con varias cuentas y distintos niveles de permisos, porque no se demuestra que el sistema cubra el caso de un usuario autenticado que lee los registros de otro.
Tres dudas habituales: coste adicional, sustituto de Vercel y secretos
¿El alojamiento cuesta aparte? Cursor no ha publicado un precio independiente para el alojamiento o la base de datos. Build Live Apps no tiene una suscripción propia: está incluido en los planes de pago con acceso a agentes en la nube. Las cifras concretas proceden de la tabla de planes de TechRepublic, no de las páginas de funciones de Cursor:
| Plan | Precio indicado | Acceso a Build Live Apps |
|---|---|---|
| Plus | $8/mes | No, no incluye agentes en la nube |
| Premium | $30/mes | Sí, es el plan individual que da acceso al precio más bajo |
| Super | $100/mes | Sí, con una cuota de uso mayor |
| Ultra | $200/mes | Sí, con la cuota más alta indicada |
| Team | Desde $30/usuario/mes | Sí, añade controles de administración |
| Enterprise | Personalizado | Sí, depende de las políticas |
Cursor utiliza una cuota semanal compartida de uso de IA (desglose de planes de TechRepublic), pero en estas páginas no publica cifras de tokens, peticiones o cómputo para cada nivel. Los modelos de terceros pueden generar cargos adicionales (TechRepublic). Los límites de base de datos, almacenamiento, tráfico y concurrencia no están especificados. Considera los $30 como el precio de entrada, no como el coste operativo total, y confirma las cuotas antes de poner una carga orientada a clientes en el alojamiento integrado.
¿Build Live Apps sustituye a Vercel? Todavía no para backends de producción complejos o sujetos a requisitos de cumplimiento. El flujo integrado encaja con Postgres, SSO y un enlace para compartir. El flujo tradicional, con GitHub conectado a Vercel, Netlify, Railway, Render o un VPS, sigue siendo la opción para arquitecturas personalizadas y datos regulados; la tabla siguiente recoge la división completa por escenario. En los hilos de Reddit sobre alojamiento se repite el mismo criterio: el proveedor depende de si la carga mantiene estado o se ejecuta durante mucho tiempo.
«La mayoría de demos de Cursor que veo en mi timeline se centran en la interfaz… la mayoría no están desplegadas para usuarios reales de pago». — @mayowaoshin, usuario real
¿Dónde se guardan los secretos y puede verlos el agente? La documentación de Cursor afirma que el agente de programación nunca ve los valores de los secretos. Las apps que necesitan conectarse a un almacén de datos o a una API externa piden esos secretos al usuario. En los equipos, normalmente el administrador crea los secretos desde el panel de Apps o los añade más tarde desde ese mismo panel.
Los administradores de equipo pueden ver cada app del equipo y cada secreto del equipo. Es una cuestión de gobierno, pero también un límite de confianza que conviene entender antes de pegar claves de producción. Los clientes automatizados, como scripts, trabajos de CI y Grok Bot, acceden a las apps protegidas mediante una clave en la cabecera (x-cursor-app-token), no mediante cookies ni parámetros de consulta.
Usa el flujo integrado para esto y conserva el tradicional para aquello
| Situación | Live Apps integrado | Despliegue tradicional (Vercel / Railway / VPS) |
|---|---|---|
| Panel interno, seguimiento de registros, portal de onboarding protegido por SSO | La mejor opción y el camino más rápido hasta un enlace para compartir | Excesivo, salvo que la app supere las cuotas |
| Micrositio público de marketing con formulario de correo | Funciona en planes individuales con publicación pública | Usa el flujo tradicional si necesitas dominio personalizado, analítica o caché perimetral |
| App que necesita Postgres, Cursor SSO y despublicación por parte del administrador | Alojamiento nativo y aislado, con publicación explícita y registro de auditoría | Hay que reconstruir a mano la autenticación, la base de datos y los filtros de revisión |
| Autenticación personalizada, SAML/OIDC más allá de Cursor, esquema de Supabase con mucho RLS | Arriesgado: el modelo de permisos no está probado y el administrador puede ver los secretos | Usa el flujo tradicional y controla tú la autenticación y la capa de datos |
| Backend de larga ejecución, workers, cron, WebSockets o almacén distinto de Postgres | No está documentado; no hay especificaciones de runtime ni escalado | Usa el flujo tradicional si necesitas cualquiera de estos elementos |
| Código fuente en GitLab, flujo con agentes locales o residencia/SLA regulados | Bloqueado: solo GitHub u Origin, con agentes en la nube y alojamiento «tal cual» | Usa el flujo tradicional |
| Pagos en producción, webhooks o información personal | Solo para pilotos: supera las comprobaciones y demuestra la autorización por separado | Usa el flujo tradicional con staging, protección de ramas y claves restringidas |
El flujo tradicional mantiene su propia carga de configuración: MCP, credenciales de alojamiento, variables de entorno y refuerzo de RLS, como muestra el recorrido de cuatro semanas de un creador desde una landing hasta Vercel y la autenticación de Supabase.
Antes de compartirla: lista de comprobación para producción
Las comprobaciones de Cursor detectan secretos filtrados y archivos de credenciales. Los riesgos restantes están en los permisos, la configuración del entorno, los efectos secundarios asíncronos y el código que nadie ha revisado. Ejecuta esta lista antes de compartir la app por primera vez, incluso si es una herramienta interna.
- Reconstruye desde cero y lee el diff. Pide al agente que ejecute la compilación real de producción, no el servidor de desarrollo. Abre todos los archivos modificados en las zonas relacionadas con pagos, autenticación y escrituras de datos. Si el proyecto ya ha crecido hasta el punto de que el diff resulta imposible de revisar, restaura un checkpoint y divide la tarea en lugar de seguir escribiendo prompts sobre el desorden.
- Prueba los permisos con dos cuentas. Inicia sesión como administrador y como miembro restringido. Crea un registro como el usuario A e intenta leerlo, editarlo y borrarlo como el usuario B. Que el informe de seguridad se apruebe no demuestra que la propiedad de las filas sea correcta.
- Audita los secretos de principio a fin. Confirma que ninguna clave se incluye en el código del frontend, que no se ha enviado ningún
.envy que cada credencial externa tiene el alcance mínimo necesario para funcionar. Elimina las URL directas de bases de datos de producción del entorno al que puede acceder el agente. Un informe de r/cursor describe cómo Cursor desplegaba directamente en Supabase de producción en lugar de pasar por GitHub. - Prueba los flujos asíncronos. Envía un webhook real, repítelo y termina su ejecución a mitad de camino. Comprueba el comportamiento del pool de conexiones bajo uso concurrente. Los usuarios afirman descubrir fallos silenciosos de webhooks y pools agotados solo después del lanzamiento.
- Define las actualizaciones y la reversión. Confirma quién puede publicar, quién puede anular una publicación bloqueada, quién puede despublicar y dónde queda el registro de auditoría. Documenta cómo revertir una publicación defectuosa y cómo ejecutar una migración de esquema, porque la documentación explica la publicación, pero no el historial de versiones ni la reversión.
«Cuando una app sale de localhost, sus secretos salen con ella». — @1PasswordDev, usuario real sobre el aislamiento de secretos por app
Si alguno de los pasos anteriores no tiene respuesta —por ejemplo, no hay proyecto de staging, segunda cuenta de prueba o mecanismo de reversión— mantén la app en un enlace exclusivo para el equipo o en el stack tradicional hasta resolverlo.
Preguntas frecuentes
¿Build Live Apps requiere un plan de Cursor de pago?
Sí. Build Live Apps solo funciona en planes de pago con agentes en la nube activados. Plus, con un precio de $8/mes, no cumple el requisito. Premium, con un precio de $30/mes, es el plan individual más barato que da acceso.
¿Puede Cursor crear una app desde mi repositorio existente?
Sí, desde un repositorio existente de GitHub o desde cero en Cursor Origin. GitLab está previsto, pero todavía no está disponible, y los agentes locales no pueden crear apps.
¿Una app de equipo puede ser pública?
Los planes Team y Enterprise desactivan por defecto la publicación pública. Un administrador puede activarla desde el panel de Apps. Los planes individuales permiten publicar apps públicas directamente.
¿Cursor admite dominios personalizados?
Cursor afirma que quien publica elige un dominio único y puede cambiarlo más tarde, pero ni el changelog ni la documentación confirman la asignación de dominios personalizados. Da por hecho que tendrás una URL gestionada por Cursor hasta que Cursor documente lo contrario.
¿Cómo acceden los scripts o bots a una app privada?
Crea una clave API de Cursor y envíala en cada petición mediante la cabecera x-cursor-app-token. Las claves personales permiten abrir todo lo que pueda abrir su propietario. Las claves de equipo solo permiten abrir las apps de equipo autorizadas explícitamente.
¿Qué ocurre después de despublicar una app?
Los administradores pueden despublicar cualquier app de equipo, y desactivar las apps públicas devuelve las apps públicas existentes a una visibilidad exclusiva para el equipo. Cursor no documenta qué ocurre con la retención, las copias de seguridad o la exportación de datos después de despublicar.
Build Live Apps elimina la configuración del alojamiento que separa un prototipo funcional de un enlace utilizable. Pero no elimina el trabajo de revisión, las pruebas de permisos ni la responsabilidad sobre la propiedad del sistema que determinan si otras personas pueden usar el resultado de forma segura.
Lecturas relacionadas: Mejor LLM para agentes de programación en 2026 · Análisis de Cursor Projects Beta · Cursor Router explicado