¿Tu app de Replit funciona en la vista previa pero falla al publicarla? Checklist para founders

Pruebas la app en Replit, le envías el enlace a alguien y enseguida te dicen que el login, el guardado o el checkout no funcionan. Antes de pedirle a Agent que reconstruya esas funcionalidades, usa esta checklist de despliegue en producción para Replit. Una diferencia entre los dos entornos puede explicar el fallo sin necesidad de una nueva implementación.

¿Por qué una app puede funcionar en la vista previa de Replit y fallar en producción?

La vista previa de Replit y la app publicada son entornos separados. La app en vivo puede tener una URL, una configuración, unos datos y un comportamiento en tiempo de ejecución distintos de los del proyecto que estás editando.

La guía de publicación de Replit explica que publicar crea un despliegue de producción y que las ediciones posteriores no lo modifican hasta que vuelvas a publicar. Primero confirma que estás probando la versión correcta. Anota la URL pública, la hora de la última publicación, la acción que falla y si el fallo también ocurre en una sesión nueva del navegador.

No reúnas cinco capturas de pantalla sin relación entre sí para pedirle a Agent que arregle toda la app. Elige un solo fallo: por ejemplo, un cliente nuevo recibe un error después de pulsar Guardar. Anota el resultado esperado, el resultado real y la hora. Así tendrás algo concreto que comparar con los logs de la aplicación publicada.

¿La app usa el tipo de despliegue adecuado?

El despliegue debe soportar el tipo de programa que ejecuta tu app. Un conjunto de archivos estáticos y una aplicación full-stack tienen requisitos de hosting diferentes.

A octubre de 2026, la documentación sobre tipos de despliegue de Replit distingue entre despliegues Autoscale, Static, Reserved VM y Scheduled. Comprueba el tipo de despliegue en la configuración de Publishing y compáralo con lo que la aplicación necesita realmente.

Esa misma documentación indica que Static no es compatible con apps creadas con Replit Agent, porque esas apps necesitan un backend. Si la aplicación se ha personalizado, pide a un desarrollador que confirme los comandos de build y de ejecución. Contratar una máquina más grande no arreglará una ruta de servidor que falta ni un comando de arranque incorrecto.

¿Están realmente disponibles los secretos de producción necesarios?

Revisa las credenciales y la configuración que usa la app publicada, incluidos sus nombres y el entorno al que están destinadas. Que una clave esté disponible durante el desarrollo no demuestra que la integración en vivo esté bien configurada.

La guía de Secrets de Replit te indica ir a Publishing → Adjust settings → Production app secrets. También distingue los secretos sensibles de los valores de configuración no sensibles. Revisa ahí las entradas necesarias, sin copiar sus valores en un prompt de depuración.

1. Pide una lista de los nombres de variables necesarias, dónde se lee cada una y si se usa en tiempo de build o de ejecución.
2. Comprueba que las entradas de producción coinciden exactamente con esos nombres y pertenecen a las cuentas de proveedor correctas.
3. Mantén las credenciales de servidor en el servidor; una variable de frontend o el bundle del navegador no son un almacén de secretos.
4. Vuelve a publicar cuando la plataforma o el proceso de build lo requiera y luego repite la acción original en la URL pública.

¿La app publicada lee la base de datos correcta?

Identifica la base de datos en vivo antes de tratar la ausencia de registros en producción como un fallo de la interfaz. Los datos de ejemplo visibles en desarrollo pueden no ser los datos que lee la app de tus clientes.

La guía de bases de datos de desarrollo y producción de Replit describe entornos separados y procesos de configuración distintos para la infraestructura actual y la heredada. Revisa la selección de producción en la herramienta Database y la configuración de publicación que aplica a tu app. No des por hecho que un tutorial pensado para otra generación de proyectos coincide con el tuyo.

Piensa en una app de directorio hipotética. La vista previa muestra diez negocios, pero el sitio en vivo no muestra ninguno. Antes de reconstruir el componente de la lista, comprueba si producción contiene algún registro de negocio aprobado. Quizá lo que falta es una importación de datos deliberada o un paso de inicialización. Copia solo datos aptos para uso en vivo y protege los registros de clientes existentes antes de cualquier importación o cambio de esquema.

Si falla una escritura, recoge la operación y el error saneado. Pide a un desarrollador que distinga entre un fallo de conexión, una tabla que falta, una restricción o un problema de autorización. Cambiar la cadena de conexión una y otra vez puede ocultar el problema original y hacer que, sin querer, el trabajo de desarrollo apunte a los datos equivocados.

¿Funcionan los archivos y los callbacks externos en el dominio público?

Comprueba dónde se guardan los archivos subidos y a qué dominio llaman los servicios externos. Ambas cosas pueden parecer correctas en la vista previa y, aun así, no ser adecuadas para la aplicación publicada.

Para las subidas de archivos, Replit App Storage ofrece almacenamiento de objetos persistente. Revisa la implementación actual en lugar de suponer que los archivos escritos en una carpeta del runtime tienen la persistencia y los controles de acceso que necesita tu producto. Prueba a subir, recuperar y restringir un archivo después de una publicación controlada.

Para proveedores de login, webhooks de pago y enlaces de email, revisa con cada proveedor los orígenes permitidos, los endpoints registrados y las URL de retorno. Deben apuntar al dominio publicado correcto cuando sea necesario. Prueba el recorrido completo: salir de tu app, completar la acción en el proveedor y volver a una pantalla útil.

Mantén un pequeño inventario de integraciones: servicio, entorno, ruta pública de callback, nombre del secreto y persona responsable. El inventario contiene datos de configuración, no valores secretos. Facilita mucho la revisión de futuros cambios de dominio y traspasos.

¿Cómo verificar la corrección en producción?

Reproduce la acción original en la URL pública y luego revisa la evidencia correspondiente en producción. Una publicación correcta significa que el lanzamiento se completó; no demuestra que todos los flujos de los clientes funcionen.

La guía de monitorización de Replit explica los estados de las peticiones, la duración de las respuestas, el uso de recursos y los logs de la aplicación. Usa la marca de tiempo de la acción fallida para acotar la investigación. Un uso elevado de recursos y un error de la aplicación son hallazgos distintos, así que diagnostica antes de cambiar la capacidad.

1. Usa una cuenta nueva en el dominio publicado y repite exactamente el recorrido que falla.
2. Confirma que el registro o el resultado de la integración esperado existe después de recargar la página.
3. Revisa la petición o el log de servidor correspondiente y luego prueba con seguridad un caso de fallo cercano.
4. Repite el recorrido principal en un móvil y verifica que lo que antes funcionaba sigue funcionando.

¿Y si el despliegue todavía necesita trabajo de desarrollo?

Si las comprobaciones de configuración no resuelven el fallo, acota el trabajo de desarrollo al punto concreto que está roto. Aporta una reproducción, la configuración del despliegue, los errores saneados y un mapa de los servicios implicados.

Usa la checklist más amplia para llevar un MVP hecho con IA a producción antes de ampliar tu audiencia, o la guía sobre bucles de corrección si los prompts repetidos están generando regresiones. Si quieres ayuda para revisar y lanzar la siguiente versión, reserva una llamada sobre tu app de Replit. Podemos determinar si necesitas una corrección de configuración, un cambio de código acotado o un plan de lanzamiento más amplio.