En el mundo de la automatización interna, cada vez hay más empresas que se mueven entre varias piezas separadas: un motor de flujos por un lado, una herramienta low-code por otro, un sistema de jobs en segundo plano aparte y, además, scripts dispersos que acaban resolviendo tareas concretas sin demasiada estructura. En ese terreno es donde quiere posicionarse Windmill, una plataforma que promete convertir scripts en webhooks, flujos de trabajo, APIs internas y pequeñas interfaces visuales desde un mismo punto de partida.
El proyecto, publicado en GitHub por Windmill Labs, se presenta como una alternativa autohospedable a herramientas como Retool, Pipedream, Superblocks o incluso a enfoques más complejos de orquestación como Temporal. Su propuesta combina ejecución de scripts, construcción de flujos, jobs en segundo plano y creación de interfaces internas, todo ello con un enfoque claramente orientado a desarrolladores y equipos de infraestructura. La idea es sencilla de explicar: escribir una pieza mínima de código, definir sus parámetros y dejar que la plataforma genere una interfaz compartible, la convierta en un paso de un workflow o la exponga como endpoint interno.
Qué ofrece realmente Windmill
Uno de los puntos más atractivos del proyecto es su enfoque práctico. Windmill permite trabajar con varios lenguajes, entre ellos Python, TypeScript, Go, Bash, SQL, GraphQL, PowerShell, Rust, C#, Java y PHP, además de otros runtimes. En lugar de obligar a aprender un lenguaje propio o una sintaxis cerrada, apuesta por usar código relativamente normal y conectarlo después con una capa visual y de automatización.
La plataforma está construida sobre una arquitectura bastante reconocible para cualquier equipo moderno: PostgreSQL como base de datos central, un backend escrito en Rust, frontend en Svelte 5 y un modelo de ejecución basado en API servers sin estado y workers que extraen trabajos desde una cola en Postgres. Para el aislamiento de trabajos, Windmill menciona el uso de nsjail y aislamiento por espacios de nombres de procesos, una parte importante en cualquier herramienta que vaya a ejecutar código de forma automatizada dentro de una organización.
Ese diseño ayuda a entender por qué Windmill intenta ocupar varios espacios a la vez. No quiere ser solo un sustituto visual de Retool ni solo un reemplazo de un orquestador clásico. Aspira a ser una especie de plataforma interna para automatización, donde un mismo script pueda servir como tarea manual, job programado, webhook, endpoint HTTP o paso dentro de un flujo más grande.
También se puede desplegar de varias formas. El proyecto ofrece una instalación básica con Docker Compose, despliegue con Helm sobre Kubernetes y compatibilidad declarada con proveedores como AWS, Google Cloud, Azure, Fly.io, Render, Hetzner o DigitalOcean. En su documentación, Windmill recomienda como regla general 1 worker por cada 1 vCPU y entre 1 y 2 GB de RAM, una orientación útil para quien quiera empezar a dimensionarlo.
Open source, pero con matices en la licencia
Aquí aparece uno de los puntos que conviene tratar con algo de rigor. Windmill se presenta como proyecto open source y buena parte de su código lo es, bajo licencias AGPLv3 y Apache 2.0 según su repositorio. Sin embargo, la propia documentación introduce un matiz importante: la llamada Community Edition distribuida en sus imágenes Docker y binarios oficiales incluye también componentes propietarios y no públicos.
Eso significa que, aunque el repositorio contiene una base abierta compilable sin determinadas funciones enterprise, la edición comunitaria distribuida por la compañía no encaja del todo en una definición estricta de software 100 % abierto en todos sus componentes. Para uso interno, Windmill permite utilizar esa Community Edition sin coste de licencia, pero limita escenarios como la reventa, el uso como servicio gestionado o determinadas integraciones comerciales sin acuerdo adicional. Es un modelo cada vez más habitual en el software de infraestructura: base abierta, producto comercial encima y límites claros cuando entra en juego el negocio de terceros.
Esa precisión importa porque Windmill no compite solo por tecnología, también compite por narrativa. En un mercado donde muchas empresas buscan evitar dependencias excesivas de SaaS cerrados, la promesa open source pesa mucho. Pero en este caso conviene entender bien qué parte es realmente abierta, qué parte depende del binario oficial y qué implicaciones tiene eso si una organización quiere integrarlo en un producto propio o usarlo más allá del ámbito interno.
La gran baza: rendimiento y desarrollo local
Windmill también intenta ganar terreno por rendimiento. La empresa afirma que su motor es el workflow engine autohospedable más rápido y asegura haber obtenido ventajas frente a Airflow, Prefect, Temporal, Kestra y Hatchet en sus propios benchmarks. En algunos materiales públicos llega a hablar de una ventaja de hasta 13 veces frente a Airflow en ciertos escenarios. Ahora bien, ese dato debe entenderse como una afirmación del propio proveedor basada en pruebas publicadas por la empresa, no como una certificación independiente de mercado.
Aun así, más allá del titular comercial, el interés de Windmill está en otra cosa: su apuesta por reducir fricción para equipos técnicos. La plataforma incluye CLI, extensión para VS Code, sincronización bidireccional con Git y soporte para Claude Code como entorno de desarrollo asistido. Esa combinación resulta especialmente llamativa porque encaja con un momento del mercado en el que las herramientas internas ya no solo se diseñan para personas, sino también para agentes y automatizaciones apoyadas en modelos de IA.
Además, el proyecto juega con una idea que puede tener bastante recorrido: que muchos equipos ya no quieren elegir entre low-code y código tradicional. Quieren ambos. Quieren poder escribir un script en TypeScript o Python, conectarlo con secretos y variables, convertirlo en una UI interna sin demasiado esfuerzo y, si hace falta, integrarlo dentro de un flujo mayor con disparadores por horario, correo, Kafka, HTTP o WebSocket.
Ahí es donde Windmill resulta más interesante. No tanto por proclamarse alternativa a media docena de productos a la vez, sino por intentar reunir en una sola capa varias necesidades que hoy están fragmentadas en muchas organizaciones.
Si consigue o no sostener esa ambición dependerá de varios factores: madurez del producto, claridad de licencias, calidad de su experiencia de despliegue y capacidad para convencer a empresas que hoy ya viven entre Retool, Airflow, scripts internos y servicios cloud administrados. Pero como tendencia sí refleja algo muy real: la infraestructura interna se está volviendo más programable, más visual y también más cercana a los flujos de desarrollo modernos.
Preguntas frecuentes
¿Qué es Windmill y para qué sirve?
Windmill es una plataforma para convertir scripts en flujos de trabajo, jobs en segundo plano, webhooks, APIs internas y pequeñas interfaces visuales, con opción de autohospedaje.
¿Windmill es completamente open source?
El repositorio contiene código bajo AGPLv3 y Apache 2.0, pero la Community Edition distribuida por la empresa incluye también componentes propietarios, según su propia documentación.
¿Se puede instalar Windmill en servidores propios o en la nube?
Sí. El proyecto ofrece despliegue con Docker Compose, Kubernetes mediante Helm y compatibilidad con varios proveedores cloud y entornos autogestionados.
¿Es de verdad más rápido que Airflow o Temporal?
Windmill asegura que sí en sus benchmarks públicos, pero esas comparativas proceden de pruebas publicadas por la propia empresa y no deben leerse como una verificación independiente universal.
