Saltar al contenido
← Volver al blog
infraestructuraproducto

¿Necesitas un entorno de pruebas (staging) para tu app?

Cuándo una app pequeña necesita staging y una configuración simple y barata con un segundo proyecto de Supabase, previews por rama y Stripe en modo de prueba.

Por Equipo Devonauts5 min de lectura
Read in English →
Código en la pantalla de una laptop con un panel de pruebas que indica que todas pasaron, bajo una luz naranja a rayas

Necesitas un entorno de pruebas (staging) en cuanto tu app tiene usuarios reales, pagos reales o datos que no te puedes dar el lujo de perder. Antes de eso, los despliegues de preview alcanzan. Para una app pequeña, staging no tiene que ser complicado: un segundo proyecto de base de datos, una rama que se despliega en su propia URL con sus propias variables y los pagos en modo de prueba cubren casi todo el valor.

Esta guía te ayuda a decidir si ya lo necesitas y después arma una configuración liviana para el stack más común en apps hechas con IA (frontend en Vercel o Netlify, Supabase detrás y Stripe para cobrar), con una rutina de publicación que entra en diez minutos.

¿De verdad necesitas staging ya?

Úsalo como prueba rápida.

Tu situaciónLo que necesitas
Prototipo, sin usuarios reales, solo datos de demoCon los previews alcanza
Algunos usuarios reales, sin pagosUna base de datos aparte para pruebas, con los previews apuntando a ella
Clientes que pagan, o datos personales bajo tu responsabilidadUn staging de verdad y una rutina de publicación
Un equipo de varias personas subiendo cambiosStaging y una regla de que nada llega a producción sin probar

Lo que decide es el riesgo, no el tamaño. Una app chiquita que cobra necesita staging más que una herramienta interna grande con diez usuarios. Los errores más caros que se buscan evitar son una migración que borra una columna en producción, una prueba que le manda un correo a todos los clientes reales o un preview que cobra tarjetas de verdad.

¿Cómo se ve un staging sencillo?

Staging es una copia de producción con datos inventados y claves de prueba. Estas son las piezas.

1. Un segundo proyecto de Supabase

Crea un proyecto con un nombre como tuapp-staging. El plan Free de Supabase permite dos proyectos activos, aunque los proyectos gratis se pausan tras una semana sin actividad; para staging suele estar bien si no te molesta despertarlo. En el plan Pro, cada proyecto adicional suma su propio costo de cómputo: la página de precios de Supabase da el ejemplo de una organización Pro con dos proyectos Micro por USD 35 al mes.

Mantén el esquema igual al de producción aplicando las mismas migraciones en los dos, primero en staging. Lo explicamos en la guía de migraciones con Supabase CLI. Nunca apuntes staging a la base de producción "por ahora".

2. Una rama de staging con sus propias variables

Crea una rama staging en GitHub. Después:

  • En Vercel, agrega variables de Preview limitadas a la rama staging con la URL y las claves del Supabase de pruebas. Los valores por rama reemplazan a los de preview generales. También puedes asignarle a esa rama un dominio como staging.tuapp.com.
  • En Netlify, los branch deploys compilan las ramas con nombre, y las variables de entorno pueden tener un valor Branch para staging.

Si dudas qué variable va en cada lado, la guía de variables de entorno en producción y preview tiene una tabla completa.

3. Stripe en modo de prueba

Usa las claves de prueba de Stripe en staging y crea un endpoint de webhook aparte, en modo de prueba, que apunte a tu URL de staging. Su secreto de firma es distinto del de live, así que necesita su propia variable. Prueba los pagos con las tarjetas de prueba de Stripe, como 4242 4242 4242 4242 con cualquier fecha de vencimiento futura.

4. Autenticación configurada para la URL de staging

En el proyecto de Supabase de staging, configura la URL del sitio y las URL de redirección con tu dominio de staging. Si no, las confirmaciones de registro y los cambios de contraseña en staging mandarán a la gente a producción o a localhost.

5. Datos inventados, no una copia de producción

Carga staging con cuentas de prueba y registros realistas pero inventados: un administrador, dos usuarios normales de organizaciones distintas, una suscripción cancelada. Copiar producción a staging lleva los datos personales de tus clientes a un lugar menos protegido, y casi nunca hace falta para encontrar errores.

6. Que sea privado

Staging no debería ser público ni aparecer en buscadores. En Vercel, Standard Protection cubre todas las URL de despliegue salvo tus dominios de producción, así que puedes exigir que los miembros del equipo entren con Vercel Authentication. En Netlify, revisa qué opciones de control de acceso incluye tu plan para los branch deploys.

¿Cuál debería ser la rutina para publicar?

Que sea tan corta que de verdad la cumplas.

  1. Trabaja cada función en su propia rama; cada push crea un preview.
  2. Fusiona en staging cuando la función esté lista. Aplica cualquier migración nueva a la base de staging.
  3. Recorre el checklist de abajo en la URL de staging.
  4. Fusiona staging en main. Aplica la misma migración en producción y deja terminar el despliegue.
  5. Repite en producción las dos pruebas más importantes.

Un checklist de staging de diez minutos

  • Regístrate con un correo nuevo, confírmalo, cierra sesión y vuelve a entrar.
  • Cambia la contraseña con el flujo de recuperación.
  • Haz un pago con una tarjeta de prueba y confirma que se otorga el acceso.
  • Entra como un segundo usuario y verifica que no ves los datos del primero.
  • Abre en el celular la pantalla que cambiaste.

¿Cuáles son los errores más comunes?

  • Base de datos compartida. Si staging y producción usan el mismo proyecto de Supabase, una prueba puede borrar datos reales.
  • Migraciones primero en producción. Siempre van primero a staging; revisa que la app siga andando y recién ahí a producción.
  • Webhooks olvidados. El webhook de prueba de staging apuntando a producción, o al revés, genera pedidos fantasma.
  • Staging que se desactualiza. Si nadie lo usa durante meses, se desincroniza. Aplica cada migración en los dos, aunque sea chica.

Respuestas rápidas

¿El branching de Supabase reemplaza a un proyecto de staging? Puede hacerlo. Supabase ofrece ramas de base de datos; revisa en su documentación los requisitos de plan y los costos actuales antes de depender de eso.

¿Puedo usar planes gratis para staging? Muchas veces sí. Supabase Free permite dos proyectos activos, pero ojo con la pausa por inactividad. Una app comercial igual necesita un plan de hosting que permita uso comercial.

¿Necesito staging si solo construyo con Lovable o Bolt? Si la app tiene usuarios reales, sí. La vista previa del builder no es un entorno aparte si usa la misma base de datos que producción.

¿Cuánto cuesta un staging? En una app pequeña, normalmente lo que vale un proyecto de base de datos más y nada extra en el hosting. Lo desglosamos en la guía de cuánto cuesta alojar tu app.

¿Te ayudamos a armar tu staging?

Separar entornos toca a la vez la base de datos, el hosting, los pagos y la autenticación, y equivocarse en una pieza es justo lo que staging debe evitar. Nuestros planes de mantenimiento de software pueden configurarlo y mantenerlo sincronizado, y una reestructuración más grande entra en desarrollo de software a medida. También puedes empezar por el chequeo gratuito.

¿Tu app sigue trabada?

Pasa el chequeo gratis con la URL de tu app, o pide la Auditoría de rescate de $299: un ingeniero senior revisa el código y te envía un informe escrito en 2 días hábiles.