O Windmill é uma plataforma open source para programadores que transforma scripts em webhooks, fluxos de trabalho, tarefas agendadas e interfaces internas - posicionada frente ao Retool e ao Temporal, não frente a um alojamento de sites estáticos. A edição comunitária está licenciada sob AGPL-3.0 e a empresarial atrás de uma chave de licença.
Dimensioná-lo não se assemelha a dimensionar uma aplicação web comum, porque a unidade de capacidade é o worker e não a aplicação.
A arquitetura que decide as suas especificações
O docker-compose.yml oficial arranca sete serviços:
| Serviço | Imagem | Função |
|---|---|---|
db | postgres:16 | Base de dados e fila de tarefas |
windmill_server | ghcr.io/windmill-labs/windmill:main | API e interface web, porta 8000 |
windmill_worker | mesma imagem, MODE=worker | Executa as tarefas |
windmill_worker_native | mesma imagem, NATIVE_MODE=true | Apenas tarefas leves |
windmill_indexer | mesma imagem, MODE=indexer | Pesquisa de texto integral sobre tarefas |
windmill_extra | ghcr.io/windmill-labs/windmill-extra:latest | Servidores de linguagem para o editor |
caddy | ghcr.io/windmill-labs/caddy-l4:2.11.4-1 | Proxy inverso na porta 80 |
Dois pontos dessa tabela pesam mais do que os restantes.
Não existe Redis. O Windmill usa o PostgreSQL como fila. Inúmeros guias de terceiros acrescentam um contentor Redis e uma REDIS_URL; o ficheiro Compose oficial não tem nem um nem outra, e copiar um guia desses deixa-o a correr um serviço com o qual o Windmill nunca fala.
Os workers são o centro de custo. O servidor fica comparativamente parado. Aquilo que realmente paga é capacidade de worker.
RAM e CPU: dimensionar por worker
A regra prática é um worker por vCPU, 1-2 GB de RAM cada, mais folga para o Postgres e o servidor.
| Montagem | vCPU / RAM | O que lhe dá |
|---|---|---|
| Ensaio, um worker | 2 / 2 GB | Funciona, mas uma tarefa de cada vez e sem folga para uma grande instalação de dependências |
| Pilha predefinida, 1-2 workers | 2-4 / 4 GB | O mínimo praticável para uso real |
| Várias tarefas em simultâneo | 4 / 8 GB | O objetivo confortável para uma equipa pequena |
Os workers nativos são a exceção que convém conhecer: executam tarefas leves com cerca de 0,1 CPU e 128 MB, e é por isso que a pilha predefinida inclui um a par de um worker padrão sem reclamar outro núcleo.
A variável que ninguém prevê é a instalação de dependências. Uma tarefa em Python que puxa o pandas, ou uma em TypeScript com um ficheiro de bloqueio grande, dispara a memória bem acima do valor em repouso. Se as tarefas falham apenas na primeira execução e depois passam, está a assistir à construção da cache de dependências com pouca RAM.
Armazenamento: o crescimento está na cache de dependências
A base de dados mantém-se modesta durante muito tempo - metadados de tarefas, scripts, fluxos e registos são texto. O volume que cresce é o worker_dependency_cache, onde ficam guardados cada wheel de Python e cada pacote npm importados pelas suas tarefas, para que as execuções seguintes dispensem a instalação.
Comece com 40 GB. Vigie o volume da cache em vez da base de dados quando ponderar aumentar, e prefira NVMe ou SSD: aqui o Postgres faz de fila além de armazenamento e é sensível à latência de entrada/saída.
Planos de VPS que correspondem a estes requisitos
| Fornecedor | Plano | vCPU / RAM / Disco | Preço | Veredicto | Ligação |
|---|---|---|---|---|---|
| Contabo | Cloud VPS 4 | 4 / 8 GB / 100 GB SSD | 5,50 EUR/mês s/ IVA | Espaço para quatro workers ao preço de um plano de entrada | Contabo |
| Hetzner Cloud | CX23 | 2 / 4 GB / 40 GB NVMe | 5,49 EUR/mês s/ IVA | Adequado à pilha predefinida de dois workers | Hetzner |
| DigitalOcean | Basic 4 GB | 2 / 4 GB / 80 GB SSD | 24 USD/mês | Mesmas especificações do CX23, quatro vezes o preço | DigitalOcean |
| Vultr | Regular 4 GB | 2 / 4 GB / 80 GB SSD | 20 USD/mês | A maior escolha de regiões | Vultr |
| Linode | Linode 4 GB | 2 / 4 GB / 80 GB SSD | 24 USD/mês | Desempenho previsível, API sólida | Linode |
O Windmill é uma das poucas aplicações auto-alojadas em que um plano de 1 GB não fica excluído à partida: um único worker nativo cabe mesmo lá. Mas não consegue correr aí um worker padrão, o que exclui qualquer tarefa em Python ou TypeScript com dependências. É uma demonstração, não uma instalação.
Crescer
O Windmill escala horizontalmente acrescentando contentores worker, e não engordando um processo. Para duplicar o débito, acrescente um segundo serviço windmill_worker a apontar para a mesma DATABASE_URL e dê mais um núcleo à máquina.
Isso tem uma consequência prática na escolha do VPS: aqui mais núcleos ganham a núcleos mais rápidos. Os 4 vCPU da Contabo por 5,50 EUR sem IVA compram paralelismo para quatro workers, ao passo que o CX23 da Hetzner compra dois por um preço praticamente igual. Se a sua carga é feita de muitas tarefas pequenas em vez de poucas pesadas, essa proporção é toda a decisão.
- Observe com
docker statsqual o worker saturado antes de aumentar. - Agrupe os workers por etiquetas, para que as tarefas pesadas caiam na máquina dimensionada para elas.
- O Postgres carrega a fila: dê-lhe disco rápido antes de lhe dar mais RAM.
Para uma visão mais ampla dos planos disponíveis, veja a nossa comparação completa de VPS.
Frequently asked questions
De quanta RAM precisa uma instância do Windmill auto-alojada?
Dimensione por worker em vez de por aplicação. A regra prática é um worker por vCPU com 1-2 GB de RAM cada, além do Postgres e do processo servidor. Uma instância com um único worker corre em 2 GB, a pilha Compose predefinida com dois workers fica folgada em 4 GB, e 8 GB com 4 vCPU são o objetivo sensato assim que várias tarefas correm em paralelo.
Quantos núcleos de CPU devo atribuir ao Windmill?
Comece com 2 vCPU e acrescente um núcleo por cada worker adicional, uma vez que um worker padrão executa apenas uma tarefa de cada vez. Os workers nativos são a exceção: tratam tarefas leves com cerca de 0,1 CPU e 128 MB, razão pela qual a pilha predefinida inclui um a par do worker padrão sem exigir outro núcleo.
O Windmill precisa de Redis ou de outro intermediário de mensagens?
Não. O Windmill usa o PostgreSQL como base de dados e também como fila de tarefas. É invulgar e vale a pena saber, porque muitos guias de terceiros acrescentam um serviço Redis que o ficheiro Compose oficial não contém. O PostgreSQL 14 ou superior é o único armazenamento de dados necessário, e acrescentar Redis só rende um contentor desperdiçado.