Cómo manejar ambientes: desarrollo, staging y producción

Publicado el 2026-09-12 por frfrand

Para qué sirve cada uno, qué tienen que compartir y qué nunca, cómo tener staging sin pagar un segundo servidor, y el error con los datos que se comete siempre.

"Ambiente" suena a jerga y describe algo bastante simple: una copia del sistema corriendo con otra configuración y otros datos, para responder una pregunta distinta.

Qué pregunta responde cada uno

Desarrollo responde "¿esto que estoy escribiendo funciona?". Corre en tu máquina, se reinicia en segundos, tiene los logs al máximo y los datos son de mentira. Está pensado para romperse todo el tiempo.

Staging responde "¿esto va a funcionar allá?". Es el ensayo general: configurado lo más parecido posible a producción, con las mismas versiones y las mismas variables. Es donde se prueban las migraciones antes de que toquen datos reales.

Producción responde "¿los usuarios están bien?". Es el único que importa de verdad.

Cuando alguien se salta staging, no está ahorrando un paso: está moviendo la pregunta "¿va a funcionar allá?" a producción, con usuarios adentro.

La regla que no se negocia

Las bases de datos son separadas. Siempre.

Suena obvio hasta que aparece la tentación concreta: "para probar bien necesito los datos reales, apunto staging a la base de producción un ratito". Y entonces una migración de prueba corre sobre datos reales, o un script de limpieza borra lo que no era.

Si hace falta probar con datos parecidos a los reales, la respuesta es una copia anonimizada, no la base viva. Cuesta una tarde armar el script que la genera y se amortiza el primer día que evita un desastre.

Lo que sí debería ser igual

Esto es lo que hace útil a staging, y donde suele fallar:

• Las mismas versiones. De lenguaje, de base de datos, de dependencias. Un staging con otra versión de Postgres no prueba nada sobre las migraciones.
• La misma forma de configurar. Si producción lee variables de entorno, staging también, con otros valores.
• El mismo camino de despliegue. Si a staging se sube a mano y a producción por la tubería automática, staging no está probando el despliegue, que es justamente una de las cosas que más se rompe.

No hace falta pagar dos servidores

Una idea que se repite es que tener staging implica duplicar la infraestructura. Para la mayoría de los proyectos, no.

Alcanza con, en el mismo VPS:

• Dos carpetas, una por rama.
• Dos servicios de systemd, con puertos distintos.
• Dos dominios o subdominios (app.midominio.com y staging.midominio.com).
• Dos bases de datos en el mismo motor.

Cada push a la rama de desarrollo actualiza staging; cada push a la rama de producción actualiza el sitio real.

Lo único que no comparten es la base. Eso no se negocia ni siquiera acá.

Dos precauciones que evitan sustos

Que se note dónde estás. Una barra de color, un prefijo en el título, algo visible. Editar datos creyendo que estás en staging es un clásico, y es barato de prevenir.

Que no se pueda indexar ni notificar. Staging con un archivo robots que bloquee todo, y con el envío de correos apagado o redirigido. Mandarle un correo real a un cliente desde una prueba es una anécdota que a nadie le causa gracia.

Cuándo alcanza con dos

Para un proyecto de una persona con pocos usuarios, desarrollo y producción pueden ser suficientes. Staging empieza a pagarse cuando hay más de una persona tocando el código, cuando hay migraciones frecuentes, o cuando una caída tiene costo real.

En ArduMaker el mismo repositorio se puede desplegar dos veces en el mismo VPS, cada despliegue con su rama, su dominio y su servicio. Es literalmente la configuración de arriba, sin tener que armarla a mano.