Cómo configurar un entorno de staging para tu app

Para configurar un entorno de staging, despliega una segunda copia de tu app en su propia URL privada, dale su propia base de datos y sus claves de API de prueba, y haz que su configuración coincida con la de producción todo lo posible. Después, publica primero en staging cada cambio importante, recorre los flujos principales y solo publica en producción cuando el staging esté bien.

Si es la primera vez que oyes el concepto, qué es un entorno de staging lo explica. Esta guía trata la configuración práctica, pensada para personas que construyen con herramientas de IA y no para un equipo de DevOps.

Desarrollo, staging y producción

Las apps pequeñas suelen necesitar tres entornos, aunque el primero sea solo la vista previa de tu constructor:

La idea del staging es que se comporte como producción —mismo código, misma pila, mismo tipo de configuración—, pero que un error allí no perjudique a nadie.

Paso 1: Decide qué debe coincidir con producción

El staging solo es útil si los problemas aparecen allí antes que en producción. Haz que coincidan:

• El mismo código, publicado de la misma forma.
• La misma pila y las mismas versiones: framework, entorno de ejecución, tipo de base de datos.
• El mismo tipo de configuración: los mismos nombres de variables de entorno, con valores de prueba.
• Los mismos servicios: si producción tiene una web y una API, el staging también las tiene.

Puede diferir en tamaño (una máquina más pequeña está bien) y en los datos.

Paso 2: Crea la copia

El enfoque más sencillo: un segundo despliegue del mismo proyecto, en otra URL como staging.tuapp.com o tuapp-staging.ejemplo.com.

Cómo lo haces depende de tu proveedor de alojamiento:

• Los proveedores con despliegues de vista previa o staging integrados pueden crear uno automáticamente para una rama de Git.
• Los proveedores sin esa función: crea una segunda app o proyecto a partir del mismo código y despliégalo por separado.
• Código en Git: mantén una rama staging o main que se despliegue en staging, y despliega en producción desde una versión publicada. Consulta cómo usar Git con una app creada con IA.

Paso 3: Dale al staging su propia base de datos

Este es el paso que te protege. Si staging y producción comparten base de datos, una prueba que borre registros borra registros reales.

• Crea una base de datos separada para el staging.
• Llénala con datos de ejemplo (seed): registros falsos pero realistas que la IA puede generarte.
• Si necesitas una copia de los datos de producción, elimina o anonimiza antes los nombres, los correos y cualquier dato personal.

Escribe un script de seed que rellene una base de datos vacía con datos de prueba realistas: 20 clientes, 50 pedidos en distintos estados y dos usuarios administradores. Usa nombres evidentemente falsos y direcciones de correo de example.com.

Antes de fiarte de la configuración, confirma a qué base de datos se conecta cada copia. Pregunta directamente:

¿A qué base de datos se conecta esta app y de dónde sale esa configuración? Muéstrame el nombre de la variable, no la contraseña.

Paso 4: Usa claves de prueba y configuración separada

Todo lo que se comunique con un servicio externo debe usar credenciales de prueba en el staging:

• Pagos en modo de prueba (las claves de prueba de Stripe, por ejemplo), para que no se cobre ninguna tarjeta real.
• Correo enviado a un sandbox o solo a tu propia dirección, para que los clientes nunca reciban un mensaje de prueba.
• IA y otras APIs de pago con una clave separada y un límite de gasto bajo.
• Webhooks apuntando a la URL de staging, no a producción.

Mantén los nombres de las variables iguales en ambos entornos y cambia solo los valores. Así el código no necesita saber dónde se está ejecutando. Para más detalles, consulta cómo mantener seguras las claves de API.

Paso 5: Mantén el staging privado

El staging no debería ser público:

• Ponlo detrás de un inicio de sesión, una contraseña o una lista de correos del equipo permitidos.
• Evita que los buscadores lo indexen con una etiqueta meta noindex o la cabecera X-Robots-Tag.
• No lo enlaces desde tu sitio público.
• Haz que se vea distinto: un banner de color llamativo con «STAGING» evita probar en la pestaña equivocada.

Añade un banner amarillo llamativo en la parte superior de cada página que diga «STAGING: solo datos de prueba» cuando la variable de entorno APP_ENV valga «staging». En ese caso, añade también una etiqueta meta noindex.

Paso 6: Establece una rutina de publicación

El staging solo ayuda si lo usas siempre. Una rutina sencilla:

1. Haz el cambio en desarrollo y compruébalo en la vista previa.
2. Publícalo en staging.
3. Recorre tus flujos clave: registro, inicio de sesión, la función principal, pagos, todo lo que toque el cambio.
4. Si algo se rompe, arréglalo y vuelve a publicar en staging.
5. Publica la misma versión en producción.
6. Revisa producción rápidamente: los mismos flujos, brevemente.

Anota los flujos clave en un guion de pruebas corto. Consulta cómo probar tu app antes del lanzamiento para saber qué incluir.

Paso 7: Gestiona con cuidado los cambios en la base de datos

Los cambios en la estructura de la base de datos —añadir una columna, renombrar una tabla— son donde el staging demuestra su valor.

• Ejecuta primero en staging cualquier cambio estructural.
• Comprueba que los datos existentes siguen ahí, no solo que las funciones nuevas funcionan.
• Haz una copia de seguridad de producción antes de aplicar el mismo cambio allí. Consulta cómo hacer copias de seguridad de la base de datos de tu app.
• Prefiere cambios que añadan algo en lugar de renombrar o eliminar, para que la versión anterior siga funcionando si tienes que volver atrás.

Prompts de ejemplo

Explica qué pasaría con los datos existentes si aplicáramos este cambio en la base de datos de producción. ¿Se elimina o renombra algo?

Haz que todos los ajustes específicos de cada entorno —URLs de API, claves, remitente del correo, la propia URL del sitio— vengan de variables de entorno con los mismos nombres en staging y en producción. Enuméralas.

Escribe una lista corta de los flujos que debo probar en staging antes de cada publicación, según lo que hace esta app.

Errores habituales

• Base de datos compartida. El error más dañino. El staging siempre tiene la suya.
• Claves reales en staging. Cargos reales, correos reales a clientes reales.
• El staging se separa de producción. Versiones o ajustes distintos hacen que el staging deje de detectar problemas.
• Un sitio de staging público e indexado que aparece en los resultados de búsqueda junto a tu web real.
• Saltarse el staging en cambios «pequeños». Los cambios pequeños también rompen cosas.
• Probar en la pestaña equivocada. Un banner visible lo soluciona.

Lista de comprobación

• El staging ejecuta el mismo código, pila y servicios que producción.
• El staging tiene su propia base de datos con datos de prueba o anonimizados.
• Pagos, correo y APIs de pago usan claves de prueba en staging.
• Los nombres de las variables coinciden entre entornos; solo cambian los valores.
• El staging está detrás de un inicio de sesión o contraseña y no se indexa.
• Aparece un banner cuando estás en staging.
• Cada publicación pasa primero por staging, con una lista escrita de flujos a revisar.
• Los cambios en la base de datos se aplican primero en staging, con copia de seguridad de producción antes de publicar.

Staging en Mythex

Publicar en Mythex te da una URL en vivo por app; no hay un interruptor de staging independiente. En la práctica tienes dos opciones:

• La vista previa como comprobación previa a la publicación. Cada proyecto se ejecuta en un espacio de trabajo privado en la nube con una vista previa en vivo. /test hace que el agente la recorra como un usuario, y un enlace Compartir permite que un cliente o un compañero revise la vista previa sin publicar. Consulta Vista previa y código. Para muchos proyectos individuales basta con esto.
• Un segundo proyecto como staging. En Pro, exporta el proyecto, impórtalo en un proyecto nuevo, dale a ese proyecto su propia base de datos y sus secretos de claves de prueba, y publícalo en su propio slug. Publica primero ahí antes de publicar el proyecto de producción.

En cualquiera de los dos casos, pregunta al agente qué base de datos usan la vista previa y la app publicada antes de hacer cualquier prueba destructiva, y usa los puntos de restauración para volver atrás ante un cambio malo. Para llevar una app a producción en general, consulta cómo llevar un prototipo de IA a producción.

Preguntas