Kamal es una herramienta de despliegue que se ejecuta en tu propia máquina o en tu runner de CI, no en el servidor. Así que hablar de «requisitos de VPS para Kamal» es en realidad hablar de la máquina a la que Kamal despliega: tiene que sostener tus contenedores de aplicación, kamal-proxy, los accesorios que hayas declarado y unos días de imágenes antiguas guardadas para los rollbacks.
El coste en recursos de Kamal sobre el host es cero. Dimensiona todo lo demás.
Qué consume recursos en el host
Tras kamal setup, el servidor ejecuta tres cosas:
- kamal-proxy, un proxy HTTP pequeño escrito en Go que ocupa los puertos 80 y 443
- tus contenedores de aplicación, un conjunto por rol en
config/deploy.yml - los accesorios: Postgres, Redis o lo que hayas declarado
Para dimensionar solo cuentan los dos últimos. kamal-proxy es un único binario estático y su huella desaparece frente a cualquier aplicación real.
Memoria
La cifra que pilla desprevenido a mucha gente no es el consumo en régimen normal, sino el solape del despliegue. Kamal arranca el contenedor nuevo mientras el antiguo sigue atendiendo tráfico, y solo detiene el antiguo cuando el nuevo supera su comprobación de salud. El pico es, por tanto, tu consumo habitual más aproximadamente una copia extra del contenedor de aplicación.
- Mínimo práctico: 2 GB, para una aplicación pequeña sin base de datos aparte
- Cómodo: 4 GB, que cubre una aplicación web típica con Postgres y el solape
- Añade swap en hosts de 4 GB. Un host que empieza a hacer swap en mitad de un despliegue puede volverse tan lento que pierda la ventana de la comprobación de salud, y entonces el despliegue vuelve atrás sin motivo aparente.
Si ejecutas Postgres como accesorio de Kamal en lugar de como servicio gestionado, dimensiona explícitamente para él: el mayor consumidor de la máquina no será Kamal, será la base de datos.
CPU
Dos vCPU son el suelo razonable, por un motivo que no tiene que ver con la carga habitual: durante un despliegue el host descarga una imagen, arranca un contenedor, ejecuta comprobaciones de salud y sirve tráfico desde el contenedor antiguo, todo a la vez. Con una sola vCPU esa competencia alarga la ventana de despliegue.
- Mínimo: 1 vCPU, viable para una aplicación con poco tráfico si aceptas despliegues más lentos
- Recomendado: 2 vCPU
- Construir imágenes en el propio VPS es el único caso que realmente pide más. Si tu portátil es arm64 y el VPS es tu única máquina amd64, una construcción usará todos los núcleos que le des.
Almacenamiento
Aquí es donde el comportamiento de Kamal cambia de verdad las cifras. Kamal conserva contenedores e imágenes antiguos en el servidor para que kamal rollback pueda arrancar una versión previa sin descargar del registro, y los limpia a los tres días por defecto.
Así que el disco tiene que albergar:
- Los datos y volúmenes propios de tu aplicación
- La imagen actual más unos tres días de versiones anteriores
- Las capas base compartidas, que se guardan una sola vez sin importar cuántas versiones conserves
Una imagen de 1 GB desplegada un par de veces al día va bien en 40 GB NVMe. Una imagen de 3 GB llena un disco de 25 GB en una semana. Conviene conocer el modo de fallo: un disco lleno rompe el siguiente despliegue, no el que lo llenó, de modo que causa y síntoma quedan separados por días.
Si despliegas a menudo, kamal prune all vacía el acumulado bajo demanda en lugar de esperar a la ventana de tres días.
Proveedores de VPS y precios
| Proveedor | Precio al mes | Aspectos destacados | Enlace de afiliado |
|---|---|---|---|
| Contabo | 5.99 EUR | 400 GB de disco: el historial de imágenes nunca es la limitación | Contabo |
| Hetzner Cloud | 5.49 EUR | 2 vCPU / 4 GB / 40 GB NVMe, snapshots antes de despliegues arriesgados | Hetzner Cloud |
| DigitalOcean | 6 USD | La documentación más clara para la configuración de host que Kamal omite | DigitalOcean |
| Vultr | 5 USD | Elección de regiones, útil si la aplicación debe estar cerca de sus usuarios | Vultr |
| Linode (Akamai Cloud) | 5 USD | Precios predecibles y red sencilla de configurar | Linode |
Para una visión completa de las opciones, revisa la comparativa de VPS.
DigitalOcean es la entrada más fácil, porque Kamal gestiona el host deliberadamente solo hasta Docker: las reglas de firewall, el swap y las actualizaciones automáticas siguen siendo cosa tuya, y la documentación de DigitalOcean cubre las tres. Hetzner te da más RAM y más disco por euro si te sientes cómodo haciendo esa configuración por tu cuenta.
Consejos prácticos
- Deja abiertos en el servidor solo los puertos 22, 80 y 443. kamal-proxy termina TLS por su cuenta, no hace falta nada más accesible.
- Comprueba
kamal app containersantes de confiar en un rollback: el destino tiene que seguir en disco. - Vigila el disco libre con la misma alerta que usas para la memoria. Es el fallo que llega en silencio.
- Desplegar una segunda aplicación en el mismo host está soportado en Kamal 2 (kamal-proxy enruta por nombre de host), pero eso duplica el número de contenedores y el historial de imágenes: dimensiona el disco para ambas.
Conclusión
Para la mayoría de despliegues de una sola aplicación, 2 vCPU, 4 GB de RAM y 40 GB de SSD o NVMe dejan sitio para la aplicación, su base de datos, el solape del despliegue y tres días de imágenes de rollback. Sube antes el disco que la memoria: la presión de memoria se anuncia sola, la acumulación de imágenes no. Para más opciones, explora nuestra comparativa de VPS.
Frequently asked questions
¿Cuánta RAM necesita un VPS como destino de despliegue de Kamal?
La suficiente para tu aplicación, sus accesorios y una copia adicional del contenedor de aplicación. Durante un despliegue conviven el contenedor antiguo y el nuevo, así que el pico es el consumo habitual más un contenedor. En un host de 4 GB con una aplicación de 1 GB va holgado; añade swap si va justo.
¿Consume Kamal CPU o memoria en el servidor?
No. Kamal es una gema que ejecutas desde tu máquina o desde CI, y termina cuando acaba el despliegue. Lo único que se añade de forma permanente al host es kamal-proxy, un proxy HTTP pequeño escrito en Go cuyo consumo es despreciable frente a cualquier aplicación real.
¿Por qué se queda sin disco con el tiempo un host de Kamal?
Kamal conserva contenedores e imágenes antiguos para que un rollback no tenga que descargar del registro, y solo los limpia a los tres días por defecto. Los despliegues frecuentes de una imagen grande se acumulan rápido, y el disco suele llenarse en mitad de un despliegue posterior, no en el que lo causó.