Desarrollo, staging y producción en un único VPS: aislamiento práctico
Publicado el 2026-11-14 por frfrand
Cómo separar datos, secretos, dominios, despliegues y límites sin pagar tres servidores.
Tres entornos no tienen por qué significar tres servidores
En proyectos pequeños puede ser razonable compartir un VPS para desarrollo, staging y producción. El ahorro de infraestructura tiene un precio: todos comparten CPU, memoria, disco, red y un punto único de fallo. La separación lógica reduce accidentes, pero nunca equivale al aislamiento físico.
Define el propósito de cada entorno
Desarrollo admite cambios frecuentes, pruebas y datos ficticios. Staging debe parecerse al despliegue de producción tanto como el presupuesto permita, para comprobar versiones y cambios de configuración. Producción contiene tráfico y datos reales: sus cambios requieren controles más estrictos.
Usa nombres, dominios y servicios explícitos: dev.ejemplo.com, staging.ejemplo.com y ejemplo.com. Si dev o staging no deben ser públicos, protéjalos por VPN, autenticación o listas de acceso, y exclúyalos de indexación; robots.txt no es una medida de seguridad.
Separa el estado antes que el código
Nunca hagas que staging escriba en la base de producción. Utiliza bases o instancias diferenciadas, usuarios exclusivos con mínimos permisos, buckets distintos y credenciales de integración específicas. Si copias datos productivos para probar, anonimiza información personal antes de exponerla en un entorno de menor confianza.
Para cada servicio, cree su propio archivo de configuración fuera de Git, cuenta de ejecución, volumen persistente y política de copias de seguridad. Puede utilizar Docker Compose con proyectos y redes diferenciados o servicios systemd con usuarios y directorios separados. La opción concreta depende del stack y del nivel de acceso del equipo.
Recursos: evite que una prueba derribe la producción
El error clásico consiste en iniciar una compilación pesada que consume toda la RAM. Defina límites efectivos de CPU y memoria; controle el número de procesos, las conexiones de PostgreSQL, el espacio en disco, la rotación de registros y el consumo de los workers. Los límites de Compose dependen del modo de implementación y de la implementación: compruebe los parámetros admitidos en su versión antes de asumir que se aplicaron.
Reserve capacidad para picos de producción. Programe tareas de pruebas pesadas fuera de los horarios críticos o ejecútelas en un ejecutor externo. Supervise el uso de memoria, swap, almacenamiento y reinicios.
Implementaciones con permisos diferentes
Un desarrollador puede publicar en dev y staging sin tener acceso completo a producción. Configure identidades por entorno y controles de aprobación para versiones de producción. En GitHub Actions, utilice entornos separados y considere credenciales temporales en lugar de copiar una contraseña SSH de administrador en todos los repositorios.
Checklist de puesta en marcha
1. Inventariar cada servicio y su dependencia. 2. Crear dominio, datos, variables y credenciales exclusivas por entorno. 3. Probar una actualización en staging, incluyendo migraciones y rollback. 4. Verificar que un fallo inducido en desarrollo no interrumpe producción.
La guía existente sobre ambientes de desarrollo, staging y producción explica los conceptos generales. Este esquema añade una propuesta concreta para presupuestos que solo permiten un VPS. Puedes gestionar el despliegue desde GitHub y administrar el servidor con herramientas de ArduMaker, verificando previamente qué funciones soporta tu configuración.
Preguntas frecuentes
### ¿Cuándo separar producción en otro VPS? Cuando el impacto de una caída o una fuga de datos justifique la inversión, o cuando los recursos compartidos sean insuficientes. ### ¿Puedo clonar la base productiva? Solo tras aplicar controles de seguridad y anonimización apropiados. ### ¿Staging debe tener el mismo dominio que producción? No: debe tener un nombre propio y acceso restringido.