App de Bolt.new a producción: qué corregir antes de lanzar

Bolt.new es una forma rápida de tener una app web funcionando: usted describe lo que quiere y genera un proyecto full-stack en el navegador, con vista previa en vivo y publicación con un clic. Para una demo, es notable. Para clientes reales, la brecha rara vez está en las pantallas. Está en todo lo que las rodea: dónde vive el código, cómo se despliega, quién es dueño de la base de datos y qué ocurre cuando algo falla de noche.

Esta guía trata del paso de "un proyecto en una pestaña del navegador" a un pipeline de entrega propiamente dicho, por lo que dejar una app de Bolt.new lista para producción tiene tanto de operaciones como de código. Si quiere una primera señal rápida, ejecute nuestro AI App Health Check gratuito. Para una visión más amplia del lanzamiento, consulte nuestra lista de 20 puntos para dejar una app lista para producción; aquí profundizamos en los detalles de cómo llevar una app de Bolt a producción.

Las plataformas cambian con rapidez. Las funciones, opciones de exportación e integraciones que se describen a continuación son patrones generales; revise la configuración de su proyecto y la documentación vigente de Bolt antes de fiarse de cualquier detalle.

Por qué un proyecto de Bolt necesita un pipeline real

Un constructor en el navegador optimiza la velocidad de la primera versión. Un sistema de producción optimiza la repetibilidad: cualquier persona del equipo puede compilarlo, desplegarlo, revertirlo y entender qué cambió. Si su única copia de la app vive dentro del constructor, tiene un punto único de fallo y ningún historial de decisiones.

El objetivo de los pasos siguientes es sencillo: su código en un repositorio que usted controle, compilado mediante un proceso automatizado, ejecutándose en entornos que usted domine, con datos de los que pueda hacer copia de seguridad y restaurar.

Paso 1: sea dueño de su código y de su repositorio

Antes que nada, lleve el proyecto a un repositorio Git bajo una cuenta u organización que controle su empresa, no el acceso personal de un freelance o de un antiguo compañero. Los proyectos de Bolt suelen poder exportarse o conectarse a GitHub; revise la configuración de su proyecto para ver las opciones actuales.

• Confirme el estado actual como punto de partida y etiquételo. Esa es su referencia conocida.
• Añada un .gitignore adecuado para que los archivos de entorno, los resultados de compilación y las cachés locales nunca lleguen al repositorio.
• Revise el historial en busca de secretos. Si alguna vez se subió una clave, rotarla importa más que borrar el archivo.
• Proteja la rama principal y exija una pull request, aunque el único revisor sea un segundo par de ojos.
• Escriba un README breve con cómo instalar, ejecutar, compilar y desplegar. Si no puede hacerlo, ese vacío es su primer hallazgo.

Paso 2: alojamiento y entornos

Publicar con un clic es cómodo, pero producción necesita más control: dominio propio, HTTPS, reversiones predecibles y entornos separados. Como mínimo, conviene tener tres.

Local, staging y producción

Local es donde trabajan los ingenieros. Staging es una copia de producción con datos ficticios, que sirve para probar cada cambio antes de publicarlo. Producción es el único lugar donde existen clientes y datos reales. Cada uno debería tener su propia base de datos, sus propias claves y su propio dominio o subdominio. Si las pruebas se hacen contra la base de datos real, tarde o temprano los clientes recibirán correos y registros de prueba.

Elegir un proveedor de alojamiento

La mayoría de las apps de Bolt centradas en el front end pueden ejecutarse en un alojamiento estático o serverless gestionado. Las apps con código de servidor de larga duración, tareas en segundo plano o websockets necesitan un alojamiento preparado para ello. La elección correcta depende de lo que la app haga realmente, así que decídala después de leer el código, no antes. Sea cual sea su elección, los despliegues deben salir del repositorio, no de una subida manual.

Paso 3: variables de entorno y secretos

Aquí es donde las apps generadas filtran información con más frecuencia. Todo lo que se empaqueta en el código del navegador es público, sea cual sea su nombre. Repase lo siguiente.

• Separe lo público de lo privado. Los valores que son seguros en el navegador (por ejemplo una clave publicable o una URL pública de API) son distintos de las claves secretas, que solo deben vivir en un servidor.
• Busque en el resultado compilado. Abra su bundle de JavaScript de producción y busque prefijos de claves y nombres de servicios. Si hay un secreto, considérelo comprometido y rótelo.
• Use el almacén de secretos del alojamiento para los valores de producción y un archivo de ejemplo documentado para la configuración local. No comparta nunca secretos en mensajes de chat ni en tickets.
• Use claves distintas por entorno, con privilegios mínimos y límites de gasto, sobre todo para cualquier clave de API de modelos de lenguaje que llame su app.
• Traslade al servidor las llamadas que requieren secretos. Si el navegador habla ahora directamente con una API de pago de terceros con una clave, añada un endpoint de backend ligero que guarde la clave y aplique límites por usuario.

Paso 4: backend, base de datos y migraciones

Las apps de Bolt suelen combinar un front end con una base de datos alojada y un servicio de autenticación, y a veces con funciones serverless. La pregunta para producción no es "cuál", sino "quién lo controla y si puede reconstruirse".

Haga reproducible el esquema

Si las tablas solo existen porque un prompt las creó, no puede recrearlas de forma fiable. Exporte el esquema a archivos de migración bajo control de versiones, aplíquelos a una base de datos nueva y confirme que la app funciona. A partir de ahí, los cambios futuros pasan por migraciones, revisadas como código, y nunca por ediciones manuales en un panel.

Reglas de acceso, copias de seguridad y restauraciones

Compruebe que cada tabla con datos de usuarios tiene reglas de acceso, y demuestre el aislamiento entre inquilinos con dos cuentas de prueba. Si usa Supabase, nuestra guía sobre los errores de Row Level Security en apps creadas con IA cubre las trampas habituales. Active las copias de seguridad y pruebe después una restauración en una base de datos de pruebas. Una copia de seguridad que nunca ha restaurado es una esperanza, no un plan.

Paso 5: refuerzo de autenticación y pagos

La autenticación generada suele funcionar en el camino feliz. Producción necesita también los caminos desfavorables.

• Autorización aplicada en el servidor, no solo ocultando botones.
• Roles almacenados donde los usuarios no puedan editarlos.
• Verificación de correo, restablecimiento de contraseña con enlaces de un solo uso que caducan, y límites de frecuencia en el inicio de sesión y el registro.
• Autenticación multifactor para las cuentas de administración.

En cuanto a los pagos, la página de éxito es solo una redirección del navegador. El acceso de pago debe derivarse de eventos de webhook verificados e idempotentes, con los modos de prueba y real totalmente separados. Repasamos los modos de fallo en webhooks y suscripciones de Stripe en apps creadas con IA. Compruebe renovaciones, pagos fallidos, cancelaciones y reembolsos antes del lanzamiento, no después del primer correo enfadado.

Paso 6: CI e higiene de dependencias

La integración continua (CI) es una tarea automatizada que se ejecuta con cada cambio. Incluso una pequeña se amortiza.

1. Instale desde el lockfile para que las compilaciones sean repetibles.
2. Ejecute lint, comprobaciones de tipos y la compilación en cada pull request.
3. Añada algunas pruebas en torno al dinero y al acceso: registro, inicio de sesión, una acción de pago y un intento de acceso entre cuentas que debe fallar.
4. Despliegue automáticamente en staging, y en producción tras la aprobación.

En cuanto a las dependencias, los proyectos generados suelen incorporar paquetes que resultaron cómodos para un prompt y ya no hacen falta. Elimine los que no se usan, actualice los paquetes con avisos de seguridad conocidos y fije las versiones. Menos dependencias significa una superficie menor que mantener.

Paso 7: rendimiento y monitorización

Una demo con diez filas de datos se siente rápida. Producción, no. Revise lo básico:

• Páginas pesadas. Fíjese en el tamaño del bundle, las imágenes sin optimizar y los datos que se piden en cada renderizado.
• Consultas a la base de datos. Vigile los listados que cargan todo de golpe y añada índices en las columnas por las que filtra y ordena.
• Monitorización de errores y alertas de disponibilidad que lleguen a una persona que actúe. Si lo primero que sabe de una caída es por un cliente, falta monitorización.
• Logs sin secretos ni datos personales, conservados el tiempo suficiente para investigar un incidente.

¿Parchear o reconstruir? Decídalo sección por sección

Rara vez la pregunta es "reconstruir toda la app". Evalúe cada área por separado.

Normalmente merece la pena parchear

Las pantallas y flujos que los usuarios entienden, las integraciones que funcionan y un modelo de datos que se corresponde con su negocio. Contienen decisiones reales de producto, y reescribirlos tira por la borda lo aprendido.

A menudo merece la pena reconstruir

La autenticación y la autorización añadidas por capas, la lógica de pagos dispersa por el front end y un diseño de base de datos que choca con cada nueva funcionalidad. Son las partes en las que una implementación limpia y probada suele salir más barata que capas de arreglos. Nuestro artículo sobre cuándo dejar de usar prompts y contratar a un ingeniero enumera las señales de que ha llegado a ese punto.

Un camino de rescate, en orden

1. Congele las funcionalidades. Deje de añadir cosas mientras estabiliza.
2. Tome el control. Lleve el código a su repositorio y anote quién tiene acceso al alojamiento, la base de datos, el dominio y los pagos.
3. Referencia e inventario. Haga una lista de cada servicio, clave y entorno. Ejecute el AI App Health Check gratuito para detectar carencias evidentes.
4. Rote los secretos expuestos y traslade al servidor las llamadas privadas.
5. Haga reproducible la base de datos, active las copias de seguridad y pruebe una restauración.
6. Refuerce el acceso y los pagos, demostrándolo con dos cuentas y pagos de prueba.
7. Añada CI y un entorno de staging.
8. Añada monitorización y un plan de reversión con un responsable designado.
9. Lance primero a un grupo reducido y amplíe después.

Cómo encaja UnlockLive

Si prefiere no hacerlo solo, nuestros dos servicios siguen el mismo camino. La auditoría técnica de apps con IA (AI App Technical Audit) revisa el código, los datos, la autenticación, los pagos, la infraestructura y los riesgos, y le entrega una lista priorizada de qué corregir y en qué orden. El servicio AI App Repair and Launch ejecuta después las correcciones y construye el pipeline de despliegue, de modo que la app salga a producción en una infraestructura de su propiedad. Nuestros ingenieros trabajan desde Toronto y desde nuestro centro de ingeniería en Dhaka, con la gestión de proyectos en el lado de Toronto.

¿Listo para llevar su app de Bolt a producción?

Empiece con el AI App Health Check gratuito para ver cómo está su app y decida después si necesita una auditoría, una reparación o simplemente unas tardes de trabajo concentrado. La mayor parte de lo que separa un prototipo de Bolt de un producto fiable se puede arreglar sin empezar de cero, siempre que lo encuentre antes que sus clientes.