Cómo elegir un VPS para Docker: mide los recursos de tu aplicación

Una aplicación creada con IA puede terminar siendo una web estática, una API, varios contenedores o una base de datos con tareas en segundo plano. El nombre del framework y el número de servicios de Docker Compose no bastan para saber qué servidor comprar. Mide una carga parecida a la real y usa el resultado para escoger RAM, CPU y disco; no existe un tamaño universal para «una app Docker».

Si aún necesitas preparar la pila y el proxy, consulta primero la guía para desplegar Docker Compose en un VPS. Este artículo se centra en decidir la capacidad del servidor.

Si tu proyecto es una aplicación Django convencional con Gunicorn y Nginx, sigue la guía de Django para VPS, que cubre el entorno Python, el servicio systemd y los controles de producción. Para una aplicación Flask, consulta la guía de Flask con Gunicorn y Nginx; para una API ASGI, la guía de FastAPI con Uvicorn.

Haz inventario de lo que va a ejecutarse

Anota cada servicio permanente: aplicación, workers, proxy, base de datos, cola, caché y monitorización. Añade procesos del sistema operativo, Docker, tareas de mantenimiento y trabajos puntuales como una compilación o una migración. Una compilación de Next.js, por ejemplo, puede tener un pico distinto del servidor cuando atiende visitas; mide ambas fases si vas a ejecutarlas en el mismo VPS.

Separa además lo que solo publica archivos estáticos de lo que necesita un proceso activo. Si tu resultado es estático, compara Hostbrid Projects antes de administrar un VPS. Un VPS da acceso root y control del sistema; también te deja a cargo de Docker, actualizaciones, firewall, copias y recuperación.

Un bot de Discord que debe permanecer conectado también necesita un proceso activo: consulta esta guía para ejecutar un bot de Discord 24/7 en un VPS.

Mide durante una prueba representativa

Arranca la versión de prueba y reproduce las tareas que importan: tráfico esperado, consultas a la base, cargas de archivos, workers, tareas programadas y una actualización. Una lectura mientras todo está inactivo no representa el pico. Registra el consumo al arrancar, durante la carga y al terminar los trabajos; comprueba también los tiempos de respuesta y los errores.

docker compose ps
docker stats --no-stream
free -h
df -h
docker system df -v

docker stats --no-stream toma una muestra; docker stats mantiene el flujo abierto para observar cambios mientras ejecutas la prueba. La columna de memoria de Docker en Linux descuenta parte de la caché y no sustituye la observación del host. Contrasta la memoria disponible del sistema con el conjunto completo de servicios. docker system df -v ayuda a revisar objetos de Docker; df -h muestra el espacio de los sistemas de archivos. Los comandos de estadísticas de Docker y la documentación de sus límites de recursos explican qué refleja cada vista.

Elige RAM, CPU y disco por separado

Para RAM, observa los picos concurrentes de toda la máquina, no solo el promedio de cada contenedor. Deja capacidad para el sistema y para variaciones de carga. Docker no limita automáticamente la memoria de cada contenedor: si defines límites en Compose, el total debe dejar margen al host y los límites no deben ser menores que lo que necesita realmente cada servicio. Una restricción demasiado baja puede terminar el proceso por falta de memoria; añadir swap no convierte el disco en RAM rápida.

Para CPU, revisa el uso sostenido junto con la latencia y los trabajos que se acumulan. Un proceso de compilación puede necesitar CPU durante unos minutos sin que la aplicación en reposo la necesite igual. Para disco, suma sistema, imágenes que coexistirán durante actualizaciones, datos persistentes, cargas, registros y espacio temporal. No cuentes una copia guardada en el mismo VPS como respaldo ante la pérdida del servidor.

No traduzcas «tres contenedores» a una talla concreta. La base puede dominar la memoria; las ejecuciones de una automatización pueden llenar el disco; y una app que llama a una API de IA externa tiene requisitos distintos de un modelo ejecutado localmente. Elige después de medir la carga y vuelve a medir cuando cambie el tráfico, los datos o la arquitectura.

Compara el resultado con el catálogo

Cuando tengas una prueba útil, compara CPU, RAM, almacenamiento y tráfico con las tallas VPS disponibles. La ficha de contratación confirma el precio final, la IPv4, la disponibilidad y las condiciones vigentes. Si prevés que necesitarás otra talla más adelante, confirma con soporte qué cambios admite tu servicio y en qué condiciones antes de depender de ellos en producción.

Si estás comparando tarifas y extras entre proveedores, consulta también la guía para calcular el coste total de un VPS económico.

Si tu proyecto es un agente siempre activo como OpenClaw, revisa también sus requisitos y el acceso seguro desde un VPS; alojarlo no significa publicar su Gateway en Internet.

Si no puedes reproducir la carga o no sabes distinguir una compilación temporal de un servicio permanente, documenta el framework, los contenedores, la base de datos y el consumo observado y consúltanos antes de elegir. No envíes claves, contraseñas ni datos reales de usuarios.