VPS para desarrolladores: entornos de pruebas
Un entorno de pruebas sirve para que los errores los encuentre usted y no sus clientes. Debe parecerse al servidor de producción en programas y configuración, pero puede tener la mitad de recursos y existir solo unos días. Veamos cómo hacer que un entorno de pruebas salga barato, cómo mantener varias versiones en un mismo servidor y cómo evitar que la copia de la web aparezca en los buscadores o envíe correos a clientes reales.
En desarrollo suele haber tres entornos. En la máquina local, el programador escribe el código. En el entorno de pruebas (staging), la versión compilada se comprueba en condiciones parecidas a las reales: el cliente revisa la nueva función, el equipo de QA recorre los escenarios y se prueban las migraciones de la base de datos. El servidor de producción atiende a los usuarios reales. A veces se añaden entornos temporales para cada rama: en ellos se muestra una tarea concreta y se eliminan tras la fusión.
Qué debe coincidir con el servidor de producción
- Versiones de los programas. El mismo sistema operativo y las mismas versiones de PHP, Node.js, Python, la base de datos y el servidor web. Los errores que solo aparecen con otra versión son las sorpresas más habituales al desplegar.
- Configuración. La configuración del servidor web, la caché, los límites de subida de archivos, la zona horaria y las variables de entorno, salvo contraseñas y claves.
- Forma de desplegar. El entorno de pruebas se actualiza con el mismo script o pipeline que producción. Así se comprueba también el propio despliegue, no solo el código. Cómo montar ese pipeline se explica en el artículo CI/CD en su propio VPS.
Qué puede ser distinto. Los recursos: a un entorno con uno o dos usuarios le bastan 1–2 núcleos y 2–4 GB de memoria, aunque el servidor de producción necesite 8 núcleos. El volumen de datos: una muestra anonimizada en lugar de la base completa. No tiene sentido medir el rendimiento bajo carga en un entorno reducido: para eso hace falta un servidor con la misma configuración que el de producción. Cómo hacer esa prueba se explica en Pruebas de carga de una web antes del lanzamiento.
Entornos de corta duración: pago por horas e instantáneas
Un entorno para enseñar una tarea o probar una actualización hace falta durante unos días. No es obligatorio pagarlo un mes entero: con el pago por horas, el cargo corre mientras el servidor existe y se detiene al eliminarlo. Según el catálogo de accsly.io a noviembre de 2026, 173 de los 2 248 proveedores con planes VPS ofrecen pago por horas. En ellos, un plan con 1 núcleo y 2 GB de memoria cuesta en la mediana del mercado unos 11 USD al mes, alrededor de 0,015 USD por hora, y una semana de entorno de pruebas sale por unos 2,6 USD. Un entorno con 2 núcleos y 4 GB cuesta unos 24 USD al mes, alrededor de 0,033 USD por hora, y tres días, unos 2,3 USD. Los importes están convertidos de rublos al tipo del 7 de noviembre de 2026 y redondeados. La fórmula de rentabilidad y las trampas se analizan en el artículo Pago por horas: cuándo sale a cuenta; los planes, en la selección VPS con pago por horas.
Una instantánea del disco (snapshot) acelera la creación de entornos. Configure el servidor una vez, haga una instantánea y cree los nuevos entornos a partir de ella en minutos. Antes de eliminar un entorno que volverá a necesitar, haga una instantánea y elimine el servidor: guardar la instantánea suele costar menos que un servidor en marcha, pero tampoco es gratis. Una instantánea en el mismo proveedor no sustituye una copia de seguridad; la diferencia se explica en el artículo Copias de seguridad de un VPS: estrategias y herramientas.
Si el proveedor es nuevo para usted, un entorno de pruebas es una forma cómoda de evaluarlo antes de trasladar la web de producción. Según el catálogo de accsly.io a noviembre de 2026, 247 proveedores ofrecen un periodo de prueba gratuito; sus condiciones y limitaciones se analizan en el artículo Periodo de prueba y devolución del dinero.
Varios entornos en un servidor con Docker Compose
Si los entornos de pruebas se necesitan de forma permanente, sale más barato tener un servidor más grande y ejecutar en él varias versiones en contenedores. Docker Compose lee por defecto compose.yaml y compose.override.yaml, y con la opción -f combina varios archivos en orden (documentación de Docker). La parte común se describe una sola vez, y en compose.staging.yaml van las diferencias del entorno de pruebas: otros puertos, límites de memoria menores, variables de prueba.
Cada entorno se lanza con su propio nombre de proyecto: docker compose -p feature-123 -f compose.yaml -f compose.staging.yaml up -d. Los proyectos con nombres distintos tienen sus propios contenedores, redes y volúmenes, así que los entornos no se estorban entre sí. Desde fuera, un servidor web o un proxy inverso los reparte por subdominios: feature-123.stage.example.com. Cómo preparar el servidor para Docker sin llenar el disco de imágenes se explica en el artículo Docker en un VPS: por dónde empezar.
Cuántos recursos contratar: calcule 1–2 GB de memoria y 5–10 GB de disco por cada entorno con base de datos. Un servidor con 2 núcleos y 4 GB aguanta dos o tres entornos pequeños. Según el catálogo de accsly.io a noviembre de 2026, un plan así cuesta en la mediana del mercado unos 21 USD (unos 18,5 EUR) al mes, y una cuarta parte de los planes cuesta menos de 12,5 USD. Un plan con 1 núcleo y 2 GB para un solo entorno, unos 11 USD (unos 10 EUR), y una cuarta parte, menos de 7 USD. Selecciones: VPS para entorno de pruebas y VPS para Docker.
Cómo ocultar el entorno de pruebas a los buscadores
Una copia de la web en los buscadores supone páginas duplicadas que compiten con la web real y la filtración de lo que aún no se ha publicado. Los métodos, de menos a más fiables:
- robots.txt no protege. Google indica claramente que bloquear en robots.txt no es la forma de excluir una página de los resultados: una dirección enlazada desde otros sitios puede aparecer en ellos aunque el rastreador no la haya visitado.
- noindex. La metaetiqueta
<meta name="robots" content="noindex">o la cabeceraX-Robots-Tag: noindexprohíbe la indexación; la cabecera es más fácil de añadir para todo el entorno en la configuración del servidor web. La admiten tanto Google como Bing. El rastreador tiene que ver esta prohibición, así que no se debe bloquear a la vez el entorno en robots.txt (documentación de Google). - La contraseña es la opción más fiable. La autenticación básica en nginx se activa con dos directivas,
auth_basicyauth_basic_user_file, y el archivo de contraseñas se crea con la utilidadhtpasswd(documentación de nginx). La directivasatisfy anydeja pasar sin contraseña desde las direcciones de la oficina y la pide al resto. El rastreador no verá ni una página.
El nombre del entorno no es secreto. Let's Encrypt publica cada certificado emitido en los registros abiertos de Certificate Transparency, y en ellos se ven todos los subdominios para los que se han emitido certificados. Un certificado para *.stage.example.com oculta los nombres de cada entorno, pero no sustituye la protección con contraseña. Cómo emitir esos certificados y configurar los subdominios se explica en los artículos Certificados SSL: gratuitos y de pago y Dominios y DNS para el propietario de un servidor.
Datos y efectos secundarios
- No copie la base de producción tal cual. Contiene datos personales de los clientes, y el entorno de pruebas está peor protegido que el servidor de producción. Anonimice nombres, teléfonos, direcciones de correo y datos de pago, o prepare un conjunto de datos de prueba. Según el RGPD y las leyes locales de protección de datos, una copia sin anonimizar sigue siendo un tratamiento de datos personales con las mismas obligaciones; más detalles en el artículo El RGPD y la elección del hosting.
- Desactive el envío de correos y SMS. Un entorno con una copia de la base puede enviar notificaciones a clientes reales. Dirija el correo saliente a un buzón de pruebas que lo capture todo o desactívelo.
- Pagos, solo en modo de prueba. Las pasarelas de pago tienen claves y tarjetas de prueba; las claves reales no hacen falta en el entorno de pruebas.
- Revise las tareas programadas. Las exportaciones a marketplaces, la sincronización con el CRM y las llamadas a API externas desde cron deben ir, en el entorno de pruebas, a entornos de prueba o estar desactivadas.
- Claves y contraseñas propias. Al entorno de pruebas acceden contratistas y el equipo de QA; ninguna clave del entorno de pruebas debe abrir el servidor de producción.
Entornos olvidados
Un entorno del que nadie se acuerda cuesta dinero cada mes y con el tiempo se convierte en el punto más vulnerable: no recibe actualizaciones, sus contraseñas son antiguas y la copia de la base sigue accesible para contratistas que hace tiempo dejaron el proyecto. Unas cuantas reglas ayudan a evitarlo:
- cada entorno tiene un responsable y una fecha de eliminación, anotados en su nombre o en una etiqueta del panel del proveedor;
- los entornos temporales de las ramas los elimina, tras la fusión de la rama, el mismo pipeline que los creó;
- el entorno permanente se actualiza junto con el servidor de producción y se protege igual: acceso solo con clave, firewall y actualizaciones de seguridad (Primeros 10 pasos tras comprar un VPS: seguridad);
- una vez al mes, compare la lista de servidores del panel del proveedor con la de entornos necesarios y elimine los que sobren.