Autohospedar Windmill en 2026: workers, PostgreSQL, aislamiento y actualizaciones seguras
Un seguimiento actualizado y orientado a producción que convierte la documentación de los proveedores en controles operativos, decisiones de migración y criterios de despliegue verificables.
Qué ha cambiado en 2026
Retomamos este tema porque los límites operativos han cambiado. Los principios duraderos siguen siendo útiles, pero las versiones actuales hacen que algunos atajos anteriores sean incompletos o arriesgados. Este seguimiento parte de la documentación oficial disponible el 14 de julio de 2026, separa los hechos de las decisiones locales y trata cada cambio de configuración como una intervención controlada en producción.
Fuentes primarias actuales
Cómo utilizar esta actualización
Primero consultamos las fuentes primarias, registramos las versiones realmente desplegadas y definimos el resultado observable antes de modificar un ajuste. La intervención reversible más pequeña se prueba en un entorno representativo. Un comando ejecutado con éxito no es un criterio de aceptación: sí lo son la salud del servicio, la integridad de los datos, la latencia, los límites de seguridad y el tiempo de reversión. La secuencia de diagnóstico del artículo anterior que aún resulta útil se conserva como base operativa; los ejemplos dependientes de una versión deben contrastarse con la documentación vigente.
Antes del despliegue guardamos el diff de configuración, una copia o instantánea cuya restauración ya se haya probado y los comandos necesarios para revertir la intervención. Una persona observa la primera ventana de producción y otra autoriza la escalada si los indicadores acordados avanzan en la dirección equivocada. Las alertas deben describir el riesgo visible para el usuario, no solo el componente que las emite. Durante el periodo de comprobación comparamos las tasas de error, la profundidad de las colas, la saturación de recursos, la latencia de procesamiento y la integridad de los datos con la línea base. Revisamos tanto promedios como valores extremos, pues un promedio estable puede ocultar fallos que afectan a una parte pequeña pero importante del trabajo. El cambio solo se cierra cuando terminan los trabajos diferidos, reintentos, tareas programadas y exportaciones posteriores. Toda acción manual de recuperación se documenta; si no figura en el runbook, este aún no está completo.
- La Decisión de Autoalojar: Cuándo el SaaS Cuesta Más que Tu Propia Infraestructura
- Recuperación ante Desastres para Servicios Autoalojados: Nuestra Estrategia de Copias de Seguridad
- Construir para Escalar Desde el Principio: Lecciones de Arquitectura Temprana
Base operativa
Las plataformas de automatización de flujos de trabajo son esenciales para los equipos de desarrollo modernos, pero las soluciones en la nube como Windmill Cloud pueden resultar costosas a medida que crece el uso. Le mostraremos cómo configurar su propia instancia de Windmill en Ubuntu con Docker Compose e integración con Traefik, superando los problemas críticos de autenticación de PostgreSQL que pueden descarrilar su instalación.
Lo que Construirá
Al finalizar este tutorial, tendrá:
- Instalación de Windmill completamente funcional con HTTPS
- Certificados SSL automáticos mediante Let's Encrypt a través de Traefik
- Base de datos PostgreSQL lista para producción con autenticación adecuada
- Configuración de workers optimizada en recursos
- Integrada con la infraestructura Docker existente
- Configuración lista para producción para automatización profesional de flujos de trabajo
Costo mensual: 4,51EUR (servidor CX11) + costos de dominio -- la misma infraestructura que puede manejar múltiples herramientas de automatización
Requisitos Previos
- Servidor Ubuntu 24.04 LTS con Docker y Docker Compose instalados
- Configuración existente de proxy inverso Traefik (consulte nuestra guía de configuración de n8n para la configuración de Traefik)
- Nombre de dominio apuntando a la IP de su servidor
- Al menos 4GB de RAM y 2 vCPUs recomendados
- Acceso SSH y conocimientos básicos de línea de comandos
Comprendiendo Windmill
Windmill es un motor de flujos de trabajo de código abierto que proporciona:
- Editor visual de flujos de trabajo con soporte para TypeScript/Python/Go
- Programación de tareas y gestión de ejecución
- Capacidades de integración con APIs
- Funciones de colaboración en equipo
- Autoalojable sin límites de uso
A diferencia del enfoque basado en nodos de n8n, Windmill se centra en flujos de trabajo orientados al código con un potente entorno de desarrollo.
Paso 1: Preparación del Servidor y Estructura de Directorios
Primero, preparemos nuestro entorno de servidor. Usaremos una convención de nombres basada en comidas para las instancias de Windmill para evitar conflictos:
Convención de Nombres: Use nombres simples de comidas para múltiples instancias de Windmill:
- Primera instancia: pizza
- Instancias adicionales: pasta, salad, soup, burger, etc.
- Esto evita conflictos y facilita la gestión
Paso 2: Configuración del Entorno
Cree un archivo de entorno seguro con credenciales adecuadas:
Crítico: Reemplace windmill.yourdomain.com con su dominio real.
Paso 3: Configuración de Docker Compose
Cree la configuración principal de Docker Compose:
Importante: Actualice el dominio en las etiquetas de Traefik para que coincida con su configuración.
Paso 4: El Problema de Contraseñas de PostgreSQL (Problema Crítico)
Aquí es donde la mayoría de las instalaciones de Windmill fallan, y requirió una considerable resolución de problemas para identificar la causa raíz:
El Problema: Caracteres Especiales en las Contraseñas
Al usar openssl rand -base64 32 para generar contraseñas, frecuentemente se obtienen caracteres especiales como =, @, #, %, etc. Estos caracteres causan fallos de autenticación de PostgreSQL en entornos Docker, incluso cuando se escapan correctamente.
Ejemplo de una contraseña problemática:
La Solución: Contraseñas Solo Hexadecimales
Use contraseñas solo hexadecimales que no contengan caracteres especiales:
Problemas Adicionales de Configuración de PostgreSQL
- Configuración de Usuario: Use postgres como usuario predeterminado, no usuarios personalizados como windmill_user
- Persistencia de Volúmenes: PostgreSQL ignora las variables de entorno POSTGRES_PASSWORD cuando los volúmenes de datos existentes contienen credenciales diferentes
- Formato de URL: Incluya ?sslmode=disable en la URL de la base de datos para entornos Docker
Paso 5: Instalación e Inicio
Ahora instalemos Windmill con nuestra configuración corregida:
Debería ver una salida como:
Paso 6: Resolución de Problemas Comunes
Problema 1: Fallos de Autenticación de PostgreSQL
Síntomas:
Solución:
Problema 2: El Contenedor No Inicia
Síntomas:
- El contenedor se cierra inmediatamente
- Errores de asignación de recursos
Solución:
Problema 3: Problemas con Certificados SSL
Síntomas:
- HTTPS no funciona
- Errores de certificado
Solución:
Paso 7: Acceso y Configuración Inicial
Una vez completada la instalación:
- Acceda a Windmill: https://windmill.yourdomain.com
- Credenciales predeterminadas:
Email: [email protected]
- Contraseña: changeme
- Complete la configuración:
Cambie la contraseña de administrador
- Configure la URL base
- Configure las cuentas de usuario
Paso 8: Optimización de Recursos
Asignación de Memoria (para servidor de 8GB)
Nuestra configuración asigna recursos de manera eficiente:
- Servidor Windmill: ~800MB
- Worker Windmill: 2GB (limitado)
- PostgreSQL: ~500MB
- Reserva del Sistema: ~4,7GB
Asignación de CPU (para servidor de 4 vCPU)
- Worker: 1 vCPU (limitado)
- Otros servicios: 3 vCPUs (compartidos)
Regla de escalado: 1 worker por vCPU con 1-2GB de RAM cada uno
Paso 9: Endurecimiento para Producción
Crear Script de Copia de Seguridad
Configurar Monitoreo
Configurar Actualizaciones Automatizadas
Paso 10: Configuración Avanzada
Integración con SMTP Existente
Si tiene un servidor de correo (como el de nuestra configuración de n8n), intégrelo:
Múltiples Instancias de Windmill
Para equipos que requieren entornos aislados:
Consideraciones de Seguridad
Aislamiento de Red
- PostgreSQL solo accesible dentro de la red Docker
- Sin puertos de base de datos externos expuestos
- Terminación HTTPS a nivel de Traefik
Límites de Recursos
- Los contenedores de workers tienen límites de CPU y memoria
- Previene ataques de agotamiento de recursos
- Configurable según la capacidad del servidor
Seguridad SSL
- Certificados automáticos de Let's Encrypt
- Redirecciones de HTTP a HTTPS
- Configuración TLS moderna
Monitoreo y Mantenimiento
Verificaciones Semanales de Salud
Mantenimiento Mensual
Desglose de Costos y Comparación
Costos Mensuales
Configuración autoalojada:
- Hetzner CX21 (4GB RAM): 8,46EUR/mes
- Costos de dominio: ~1EUR/mes
- Total: ~9,50EUR/mes
Comparación con Windmill Cloud:
- Plan de equipo: $30/mes por usuario
- Ahorro: $250+ anuales para equipos pequeños
Beneficios de Rendimiento
Ventajas del autoalojamiento:
- Ejecuciones de flujos de trabajo ilimitadas
- Sin límites de velocidad externos
- Control total de los datos
- Integraciones personalizadas
- Flexibilidad de escalado de recursos
Referencia de Resolución de Problemas
Diagnóstico Rápido
Patrones de Error Comunes
- "password authentication failed" -- Use contraseñas hexadecimales, limpie los volúmenes
- "connection refused" -- Verifique la configuración de red
- "certificate errors" -- Verifique DNS y la configuración de Traefik
- "out of memory" -- Ajuste los límites de recursos del worker
Escalando su Infraestructura Windmill
Escalado Horizontal
Para entornos de alto volumen:
Escalado Vertical
Actualice los recursos del servidor:
- CX31 (8GB RAM): 16,07EUR/mes para cargas pesadas
- CX41 (16GB RAM): 29,75EUR/mes para uso empresarial
Integración con Infraestructura Existente
Trabajando con n8n
Si ya está ejecutando n8n (de nuestros tutoriales anteriores):
- Windmill maneja flujos de trabajo orientados al código
- n8n maneja automatizaciones visuales y simples
- Ambos comparten el mismo proxy Traefik
- Bases de datos separadas previenen conflictos
Servicios Compartidos
Aproveche la infraestructura existente:
- Traefik: Gestiona SSL para todos los servicios
- Servidor de correo: SMTP compartido para notificaciones
- Monitoreo: Registro y métricas unificados
- Copias de seguridad: Estrategia de respaldo centralizada
Conclusión
El autoalojamiento de Windmill proporciona automatización de flujos de trabajo de nivel empresarial a una fracción de los costos de alojamiento en la nube. La clave del éxito es comprender los requisitos de autenticación de PostgreSQL y usar contraseñas solo hexadecimales para evitar problemas de caracteres especiales que pueden descarrilar las instalaciones.
Beneficios Clave de esta Configuración
- Rentable: Ahorre cientos anualmente comparado con soluciones en la nube
- Listo para producción: Maneja cargas de trabajo empresariales de manera fiable
- Seguro: HTTPS, redes aisladas y límites de recursos
- Escalable: Fácil de agregar workers y recursos según sea necesario
- Privado: Su código y datos nunca abandonan su infraestructura
Esta configuración ha sido probada en entornos de producción y proporciona la fiabilidad necesaria para la automatización de flujos de trabajo críticos de negocio. Los pasos de resolución de problemas abordan problemas del mundo real encontrados durante la implementación, particularmente los problemas de autenticación de PostgreSQL que afectan a muchas instalaciones autoalojadas.
Para requisitos complejos de flujos de trabajo o implementaciones empresariales, considere la consulta profesional para optimizar su caso de uso específico y asegurar una asignación óptima de recursos del servidor.
Próximos Pasos
- Explore las técnicas de resolución de problemas de webhooks que se aplican a Windmill
- Revise la optimización de carga útil para el manejo de grandes conjuntos de datos
- Considere la integración con instalaciones existentes de n8n
Acerca de tva
tva garantiza la gestión integral de infraestructura de sistemas de bases de datos, entornos en la nube y cadenas de suministro globales. Nuestro enfoque metódico combina protocolos de seguridad rigurosos con optimización del rendimiento, mientras que los servicios de asesoría estratégica permiten la coordinación precisa tanto de capacidades digitales como de activos físicos, manteniendo los más altos estándares de excelencia operativa y cumplimiento normativo en todos los compromisos.
Visite tva.sg para más información sobre nuestros servicios y tutoriales adicionales de automatización.
De la configuración a una decisión operativa
La cuestión práctica no es si una plataforma se puede configurar. El equipo debe poder explicar la responsabilidad, detectar desviaciones, recuperar el servicio sin improvisar y demostrar el resultado previsto. Por eso asociamos cada cambio con un responsable, una línea base, una ruta de reversión y un periodo de comprobación. Así, una corrección puntual se convierte en una capacidad operativa fiable. Ese mismo registro ofrece al siguiente responsable un punto de partida fiable y convierte la optimización posterior en una decisión medida, no en otra ronda de conjeturas.