Requisiti VPS per Plane: RAM, CPU e Archiviazione

Plane è una piattaforma open source per la gestione dei progetti, nella stessa categoria di Jira e Linear. La sua Community Edition auto-ospitata è più pesante di quanto lasci intuire l’interfaccia, e dimensionare un VPS a occhio è il modo più comune in cui un’installazione di Plane fallisce.

I requisiti documentati

La documentazione ufficiale di auto-hosting di Plane indica:

Perché la soglia di 4 GB è reale

Plane non è un singolo processo. Lo stack Compose della Community Edition avvia tredici container:

• Applicazione: i frontend web, admin, space e live, più l’api Django
• Background: worker, beat-worker e migrator
• Dati: postgres:15.7-alpine, valkey/valkey:7.2.11-alpine, rabbitmq:3.13.6-management-alpine, minio/minio
• Bordo: il container proxy, proprietario delle porte 80 e 443

Tredici container a riposo consumano gran parte di 4 GB prima che venga creata la prima issue. È per questo che i piani da 1 e 2 GB non funzionano: non perché Plane sia inefficiente, ma perché accanto all’applicazione stai facendo girare un database, un broker di messaggi, una cache e un archivio a oggetti.

RAM: dimensionare in base alla grandezza del team

Se sei indeciso fra due taglie, prendi la maggiore. Con memoria insufficiente Plane cede perché il kernel termina un container nel mezzo di una richiesta, il che assomiglia a errori casuali più che a un messaggio chiaro di memoria esaurita.

CPU: due core bastano davvero

Il lavoro sulle issue procede a raffiche. Qualcuno apre una board, l’API risponde, poi il server torna in silenzio. Due vCPU reggono tutto questo senza sforzo per un team normale.

Quattro core si guadagnano lo stipendio in un caso preciso: l’importazione di un archivio esistente. Durante un’importazione massiva l’API Django, il worker Celery e PostgreSQL si contendono la macchina, e il lavoro finisce sensibilmente prima con più core. È un’operazione una tantum, quindi raramente conviene in permanenza, a meno che il piano con 4 core non sia anche il piano con 8 GB, come accade da Contabo.

Archiviazione: guarda MinIO, non Postgres

Il database resta piccolo. Issue, commenti e voci di attività sono testo, e anche con un team molto attivo il volume Postgres cresce lentamente.

La variabile sono gli allegati. Ogni screenshot e ogni documento caricato su una issue finisce nel volume MinIO, e i team che incollano screenshot con generosità supereranno un disco da 40 GB molto prima che il database conti qualcosa.

Parti da 40 GB, tieni d’occhio il volume MinIO e preferisci NVMe o SSD: le prestazioni di PostgreSQL dipendono dall’I/O e la differenza si vede nelle viste board che aggregano molte issue.

Piani VPS che rispettano questi requisiti

I piani d’ingresso da 1 GB di ciascun provider sono esclusi di proposito. Stanno sotto il minimo documentato da Plane, e nessuna messa a punto cambia questo fatto.

Una nota sulla compilazione dai sorgenti

Il docker-compose.yml nel repository GitHub di Plane costruisce ogni servizio dal proprio Dockerfile invece di scaricare le immagini pubblicate. Compilare i frontend Next.js richiede molta più memoria che eseguirli, e la compilazione manderà in swap o farà fallire un VPS da 4 GB.

Il percorso supportato scarica immagini già compilate:

curl -fsSL https://prime.plane.so/install/ | sh -

Dimensiona il server per far girare Plane, non per compilarlo.

Pianificare la crescita

• Osserva con docker stats prima di decidere un ampliamento: mostra quale container è davvero sotto pressione.
• Fai uno snapshot del VPS prima di ogni aggiornamento di versione: il container migrator applica le modifiche di schema all’avvio.
• Salva insieme il volume PostgreSQL e quello MinIO. Ciascuno da solo ripristina un’istanza incompleta.
• La maggior parte dei provider aumenta la memoria sul posto, quindi passare da 4 GB a 8 GB è un riavvio, non una migrazione.

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

Riferimenti della comunità che vale la pena seguire: la lista awesome-selfhosted e il subreddit r/selfhosted.