Kamal: revolución en el despliegue, o cómo salir de la esclavitud en la nube

En los últimos diez años la industria del despliegue de aplicaciones web ha recorrido el camino desde scripts FTP y rsync hasta sistemas de orquestación muy complejos. Hoy en día los desarrolladores y los equipos pequeños se enfrentan cada vez más a una decisión difícil:

• o bien pagar una prima considerable por la comodidad de las plataformas PaaS (Heroku, Render, Fly.io),
• o bien sumergirse en la complejidad cognitiva y operativa de Kubernetes.

Kamal ofrece una tercera vía: la comodidad de los servicios en la nube modernos — en su propio servidor.

Qué es Kamal

Kamal es una herramienta CLI de código abierto de la compañía 37signals (creadores de Basecamp y Ruby on Rails), diseñada para desplegar aplicaciones web sobre Docker sin Kubernetes.

La idea clave de Kamal es simple:

el servidor es solo una plataforma para contenedores, y el despliegue debe ser reproducible, predecible y barato.

Inicialmente Kamal se creó para aplicaciones Rails, pero hoy es completamente agnóstico al lenguaje. Si una aplicación puede empaquetarse en una imagen Docker — Kamal podrá desplegarla.

Escenarios soportados:

• bare metal;
• VPS en cualquier nube (AWS, DigitalOcean, Hetzner, Yandex Cloud);
• configuraciones híbridas;
• migraciones entre proveedores.

Analogía explicativa

Imaginemos el despliegue como una vivienda:

• PaaS (Heroku) — una habitación en un hotel caro. Todo incluido, pero pagas por cada detalle y no puedes cambiar nada.
• Kubernetes — la construcción de un rascacielos. Control total, pero necesitas un equipo de ingenieros solo para mantener la infraestructura.
• Kamal — una casa modular moderna. Se puede colocar en cualquier parcela (servidor) y, si hace falta, trasladarla entera.

Cómo se ve en la práctica

A diferencia de Kubernetes con sus decenas de manifiestos YAML, la configuración de Kamal cabe en un solo archivo config/deploy.yml.

Ejemplo de configuración mínima pero real:

# Nombre del servicio
service: my-app

# Imagen Docker
image: user/my-app

# Lista de servidores
servers:
  web:
    - 192.168.0.1
    - 192.168.0.2

# Registro de contenedores
registry:
  server: ghcr.io
  username: user
  password:
    - KAMAL_REGISTRY_PASSWORD

# Variables de entorno
env:
  secret:
    - RAILS_MASTER_KEY
    - DB_PASSWORD

Ejecución del despliegue:

kamal deploy

Qué hace Kamal durante el despliegue

Detrás de un solo comando hay un proceso claro y transparente:

1. Build — construcción de la imagen Docker.
2. Push — subida de la imagen al registro de contenedores.
3. Pull — descarga de la imagen por los servidores.
4. Boot & Switch — arranque del nuevo contenedor y conmutación atómica del tráfico.

Resultado — despliegue sin tiempo de inactividad sin balanceadores, controladores Ingress ni esquemas complejos.

Características técnicas clave

1. Despliegue sin tiempo de inactividad y kamal-proxy

A partir de la versión 2.0 Kamal utiliza su propio proxy — kamal-proxy, abandonando Traefik.

Esto proporciona:

• retención de conexiones activas;
• conmutación del tráfico solo después del healthcheck;
• ausencia de dependencias externas de ingress.

Para el usuario la actualización pasa completamente desapercibida.

2. Provisionamiento automático de servidores

Comando:

kamal setup

Automáticamente:

• instala Docker;
• configura dependencias;
• prepara el servidor para el despliegue.

Requisitos mínimos:

• Ubuntu limpia;
• acceso SSH mediante clave.

3. Accessories: bases de datos y servicios cercanos

Kamal puede administrar servicios auxiliares — bases de datos, Redis, colas.

Ejemplo MySQL:

accessories:
  db:
    image: mysql:8.0
    host: 192.168.0.1
    env:
      MYSQL_ROOT_PASSWORD: <%= ENV["DB_PASSWORD"] %>

Esto es útil para:

• proyectos personales;
• MVP;
• las primeras etapas de una startup.

Para sistemas de alta carga, las bases de datos es mejor externalizarlas.

Kamal vs el resto del mundo

Por qué Kamal es mejor que Capistrano

Capistrano fue durante mucho tiempo el estándar en el mundo Ruby, pero Kamal resuelve sus problemas sistémicos:

• las dependencias ya no viven en el servidor;
• no hace falta gestionar versiones de lenguajes;
• el servidor se convierte en un recurso efímero.

Cuándo Kamal no es adecuado

Kamal no es una bala de plata.

No es la mejor opción si:

• se requiere autoescalado agresivo;
• la carga varía por órdenes de magnitud;
• se necesita una arquitectura compleja de service-mesh.

En esos casos Kubernetes sigue estando justificado.

Conclusión: filosofía de independencia

Kamal no es solo una herramienta de despliegue. Es un manifiesto de independencia:

• gastos mínimos;
• control total;
• ausencia de dependencia con el proveedor;
• migración sencilla entre nubes.

Un VPS por 50 € en Hetzner en lugar de 300 € en AWS — sin pérdida de comodidad.