Windmill es una plataforma open source para desarrolladores que convierte scripts en webhooks, flujos de trabajo, tareas programadas e interfaces internas, situada frente a Retool y Temporal, no frente a un alojamiento de sitios estáticos. La edición comunitaria está bajo licencia AGPL-3.0 y la empresarial detrás de una clave de licencia.
Dimensionarla no se parece a dimensionar una aplicación web corriente, porque la unidad de capacidad es el worker, no la aplicación.
La arquitectura que decide tus especificaciones
El docker-compose.yml oficial levanta siete servicios:
| Servicio | Imagen | Función |
|---|---|---|
db | postgres:16 | Base de datos y cola de tareas |
windmill_server | ghcr.io/windmill-labs/windmill:main | API e interfaz web, puerto 8000 |
windmill_worker | misma imagen, MODE=worker | Ejecuta las tareas |
windmill_worker_native | misma imagen, NATIVE_MODE=true | Solo tareas ligeras |
windmill_indexer | misma imagen, MODE=indexer | Búsqueda de texto completo sobre tareas |
windmill_extra | ghcr.io/windmill-labs/windmill-extra:latest | Servidores de lenguaje para el editor |
caddy | ghcr.io/windmill-labs/caddy-l4:2.11.4-1 | Proxy inverso en el puerto 80 |
Dos elementos de esa tabla pesan más que el resto.
No hay Redis. Windmill usa PostgreSQL como cola. Abundan las guías de terceros que añaden un contenedor Redis y una REDIS_URL; el fichero Compose oficial no tiene ninguno de los dos, y copiar una guía así te deja ejecutando un servicio con el que Windmill nunca habla.
Los workers son el centro de coste. El servidor está comparativamente ocioso. Lo que realmente pagas es capacidad de worker.
RAM y CPU: dimensionar por worker
La regla práctica es un worker por vCPU, 1-2 GB de RAM cada uno, más margen para Postgres y el servidor.
| Montaje | vCPU / RAM | Qué te da |
|---|---|---|
| Prueba, un worker | 2 / 2 GB | Funciona, pero una tarea a la vez y sin margen para una instalación grande de dependencias |
| Pila por defecto, 1-2 workers | 2-4 / 4 GB | El mínimo practicable para uso real |
| Varias tareas simultáneas | 4 / 8 GB | El objetivo cómodo para un equipo pequeño |
Los workers nativos son la excepción que conviene conocer: ejecutan tareas ligeras con unos 0,1 CPU y 128 MB, por eso la pila por defecto puede incluir uno junto a un worker estándar sin reclamar otro núcleo.
La variable que nadie prevé es la instalación de dependencias. Una tarea de Python que descarga pandas, o una de TypeScript con un fichero de bloqueo grande, dispara la memoria muy por encima del valor en reposo. Si las tareas fallan solo en la primera ejecución y luego pasan, estás viendo cómo se construye la caché de dependencias con demasiada poca RAM.
Almacenamiento: la caché de dependencias es lo que crece
La base de datos se mantiene modesta durante mucho tiempo: metadatos de tareas, scripts, flujos y registros son texto. El volumen que crece es worker_dependency_cache, donde se guarda cada wheel de Python y cada paquete npm que importan tus tareas, para que las ejecuciones posteriores se salten la instalación.
Empieza con 40 GB. Vigila el volumen de caché antes que la base de datos al plantearte una ampliación, y prefiere NVMe o SSD: aquí Postgres hace de cola además de almacén y es sensible a la latencia de entrada/salida.
Planes de VPS que encajan con estos requisitos
| Proveedor | Plan | vCPU / RAM / Disco | Precio | Veredicto | Enlace |
|---|---|---|---|---|---|
| Contabo | Cloud VPS 4 | 4 / 8 GB / 100 GB SSD | 5.50 EUR/mes sin IVA | Margen para cuatro workers al precio de un plan de entrada | Contabo |
| Hetzner Cloud | CX23 | 2 / 4 GB / 40 GB NVMe | 5.49 EUR/mes sin IVA | Adecuado para la pila por defecto de dos workers | Hetzner |
| DigitalOcean | Basic 4 GB | 2 / 4 GB / 80 GB SSD | 24 USD/mes | Mismas especificaciones que el CX23, cuatro veces el precio | DigitalOcean |
| Vultr | Regular 4 GB | 2 / 4 GB / 80 GB SSD | 20 USD/mes | La mayor elección de regiones | Vultr |
| Linode | Linode 4 GB | 2 / 4 GB / 80 GB SSD | 24 USD/mes | Rendimiento predecible, API sólida | Linode |
Windmill es de las pocas aplicaciones auto-hospedadas en las que un plan de 1 GB no queda descartado de entrada: un único worker nativo cabe de verdad. Pero ahí no puedes ejecutar un worker estándar, lo que excluye cualquier tarea de Python o TypeScript con dependencias, así que es una demostración y no un despliegue.
Escalar hacia arriba
Windmill escala horizontalmente añadiendo contenedores worker, no haciendo más grande un proceso. Para duplicar el rendimiento, añade un segundo servicio windmill_worker apuntando a la misma DATABASE_URL y dale otro núcleo a la máquina.
Eso tiene una consecuencia práctica al elegir VPS: aquí más núcleos ganan a núcleos más rápidos. Los 4 vCPU de Contabo por 5.50 EUR sin IVA compran paralelismo para cuatro workers, mientras que el CX23 de Hetzner compra dos por prácticamente el mismo precio. Si tu carga son muchas tareas pequeñas en vez de unas pocas pesadas, esa proporción es toda la decisión.
- Vigila con
docker statsqué worker está saturado antes de ampliar. - Agrupa los workers con etiquetas para que las tareas pesadas caigan en la máquina dimensionada para ellas.
- Postgres lleva la cola: dale disco rápido antes que más RAM.
Para una visión más amplia de los planes disponibles, consulta nuestra comparativa completa de VPS.
Frequently asked questions
¿Cuánta RAM necesita una instancia de Windmill auto-hospedada?
Dimensiona por worker en lugar de por aplicación. La regla práctica es un worker por vCPU con 1-2 GB de RAM cada uno, además de Postgres y el proceso servidor. Una instancia con un solo worker funciona con 2 GB, la pila Compose por defecto con dos workers va holgada con 4 GB, y 8 GB con 4 vCPU son el objetivo sensato cuando varias tareas se ejecutan a la vez.
¿Cuántos núcleos de CPU debo asignar a Windmill?
Empieza con 2 vCPU y suma un núcleo por cada worker adicional, ya que un worker estándar ejecuta una sola tarea a la vez. Los workers nativos son la excepción: atienden tareas ligeras con unos 0,1 CPU y 128 MB, por lo que la pila por defecto incluye uno junto al worker estándar sin exigir otro núcleo.
¿Necesita Windmill Redis o algún otro intermediario de mensajes?
No. Windmill usa PostgreSQL como base de datos y también como cola de tareas. Es poco habitual y conviene saberlo, porque muchas guías de terceros añaden un servicio Redis que el fichero Compose oficial no contiene. PostgreSQL 14 o superior es el único almacén de datos necesario, y añadir Redis solo aporta un contenedor desaprovechado.