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 coincida con la configuración de producción tanto como sea posible. Después, publica cada cambio significativo primero en staging, recorre los flujos importantes y solo publica en producción cuando staging esté bien.

Si eres nuevo en la idea, qué es un entorno de staging explica el concepto. Esta guía es 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

La mayoría de las apps pequeñas necesitan tres entornos, aunque el primero sea solo la vista previa de tu constructor:

La idea de staging es que se comporte como producción —mismo código, mismo stack, mismo tipo de configuración—, pero un error allí no le hace daño a nadie.

Paso 1: decide qué debe coincidir con staging

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.
• El mismo stack y las mismas versiones: framework, runtime, 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, staging tiene ambas.

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

Paso 2: crea la copia

La forma más sencilla: un segundo despliegue del mismo proyecto, en una URL distinta, como staging.tuapp.com o tuapp-staging.ejemplo.com.

Cómo lo haces depende de tu host:

• Hosts con despliegues de vista previa o staging integrados pueden crear uno automáticamente para una rama de Git.
• Hosts 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 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 a 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 borra registros borra registros reales.

• Crea una base de datos separada para staging.
• Rellénala con datos de semilla: registros falsos pero realistas que la IA puede generar por ti.
• Si necesitas una copia de los datos de producción, elimina o aleatoriza antes los nombres, correos y cualquier dato personal.

Escribe un script de semilla 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 obviamente 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 ese ajuste? Muéstrame el nombre de la variable, no la contraseña.

Paso 4: usa claves de prueba y ajustes separados

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

• Pagos en modo de prueba (claves de prueba de Stripe, por ejemplo), para que no se cobre ninguna tarjeta real.
• Email 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 ejecuta. Para más información, consulta cómo mantener seguras las claves de API.

Paso 5: mantén staging privado

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 noindex o una cabecera X-Robots-Tag.
• No lo enlaces desde tu sitio público.
• Haz que se vea distinto: un banner de "STAGING" en color llamativo evita probar en la pestaña equivocada.

Añade un banner amarillo brillante en la parte superior de cada página con el texto "STAGING: solo datos de prueba" cuando la variable de entorno APP_ENV valga "staging". Añade también una etiqueta meta noindex en ese caso.

Paso 6: establece una rutina de publicación

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, cualquier cosa que toque el cambio.
4. Si algo se rompe, corrígelo y vuelve a publicar en staging.
5. Publica la misma versión en producción.
6. Comprueba producción rápidamente: los mismos flujos, brevemente.

Escribe los flujos clave como un breve guion de pruebas. Consulta cómo probar tu app antes del lanzamiento para saber qué incluir.

Paso 7: maneja 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 staging se gana su lugar.

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

Ejemplos de prompts

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

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

Escribe una lista breve 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. Staging siempre tiene la suya.
• Claves reales en staging. Cargos reales, correos reales a clientes reales.
• Staging se desvía de producción. Versiones o ajustes distintos hacen que staging deje de detectar problemas.
• Un sitio de staging público e indexado que aparece en los resultados de búsqueda junto a tu sitio real.
• Saltarse staging en cambios "pequeños". Los cambios pequeños también rompen cosas.
• Probar en la pestaña equivocada. Un banner visible lo evita.

Lista de comprobación

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

Staging en Mythex

La función Publish de Mythex te da una URL en vivo por app; no hay un interruptor separado para staging. 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. Con esto basta para muchos proyectos individuales. Consulta Vista previa y código.
• Un segundo proyecto como staging. En Pro, exporta el proyecto e impórtalo en un proyecto nuevo, dale a ese proyecto su propia base de datos y secretos de claves de prueba, y publícalo con su propio slug. Publica en él antes de publicar el proyecto de producción.

En cualquiera de los dos casos, pregunta al agente a qué base de datos se conectan la vista previa y la app publicada antes de probar nada destructivo, y usa los checkpoints 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