Requisiti VPS per Windmill: RAM, CPU e Archiviazione

Windmill è una piattaforma open source per sviluppatori che trasforma gli script in webhook, workflow, lavori pianificati e interfacce interne, posizionata contro Retool e Temporal e non contro un hosting per siti statici. L’edizione community è sotto licenza AGPL-3.0, quella enterprise dietro una chiave di licenza.

Dimensionarla non somiglia al dimensionamento di una normale applicazione web, perché l’unità di capacità è il worker, non l’applicazione.

L’architettura che determina le tue specifiche

Il docker-compose.yml ufficiale avvia sette servizi:

Due voci di quella tabella pesano più delle altre.

Non c’è Redis. Windmill usa PostgreSQL come coda. Parecchie guide di terze parti aggiungono un container Redis e una REDIS_URL; il file Compose ufficiale non contiene né l’uno né l’altra, e copiare una guida simile significa far girare un servizio con cui Windmill non parla mai.

I worker sono il centro di costo. Il server resta relativamente inattivo. Quello che paghi davvero è capacità di worker.

RAM e CPU: dimensionare per worker

La regola pratica è un worker per vCPU, 1-2 GB di RAM ciascuno, più margine per Postgres e il server.

I worker nativi sono l’eccezione da conoscere: eseguono lavori leggeri con circa 0,1 CPU e 128 MB, ed è per questo che lo stack predefinito ne include uno accanto a un worker standard senza pretendere un altro core.

La variabile che nessuno prevede è l’installazione delle dipendenze. Un lavoro Python che scarica pandas, o uno TypeScript con un lockfile corposo, fa schizzare la memoria ben oltre il valore a regime. Se i lavori falliscono solo alla prima esecuzione e poi passano, stai guardando la cache delle dipendenze costruirsi con troppa poca RAM.

Archiviazione: la crescita è la cache delle dipendenze

Il database resta contenuto a lungo: metadati dei lavori, script, flow e log sono testo. Il volume che cresce è worker_dependency_cache, dove finiscono ogni wheel Python e ogni pacchetto npm importati dai tuoi lavori, così le esecuzioni successive saltano l’installazione.

Parti da 40 GB. Tieni d’occhio il volume della cache più del database quando valuti un ampliamento, e preferisci NVMe o SSD: qui Postgres fa da coda oltre che da archivio ed è sensibile alla latenza di I/O.

Piani VPS che rispettano questi requisiti

Windmill è una delle poche applicazioni auto-ospitate per cui un piano da 1 GB non è escluso a priori: un singolo worker nativo ci sta davvero. Lì però non puoi far girare un worker standard, il che esclude qualsiasi lavoro Python o TypeScript con dipendenze: è una dimostrazione, non un’installazione.

Crescere

Windmill scala orizzontalmente aggiungendo container worker, non ingrandendo un processo. Per raddoppiare la produttività aggiungi un secondo servizio windmill_worker che punta alla stessa DATABASE_URL e dai alla macchina un altro core.

Questo ha una conseguenza pratica sulla scelta del VPS: qui più core battono core più veloci. I 4 vCPU di Contabo a 5,50 EUR netti comprano parallelismo per quattro worker, mentre il CX23 di Hetzner ne compra due a un prezzo sostanzialmente identico. Se il tuo carico è fatto di molti lavori piccoli invece che di pochi pesanti, quel rapporto è l’intera decisione.

• Osserva con docker stats quale worker è saturo prima di ampliare.
• Raggruppa i worker con i tag, così i lavori pesanti finiscono sulla macchina dimensionata per loro.
• Postgres porta la coda: dagli disco veloce prima che altra RAM.

Per uno sguardo più ampio ai piani disponibili, vedi il nostro confronto VPS completo.