Quanta RAM serve per un VPS Nextcloud: dimensionamento per 10, 50 e 200 utenti

Chi mette su un'istanza Nextcloud su un VPS parte quasi sempre dal dato sbagliato. La documentazione ufficiale di Nextcloud non dà un minimo di RAM per il server: la memoria richiesta per eseguire un server Nextcloud varia molto a seconda del numero di utenti, app, file e volume di attività, e Nextcloud richiede un minimo di 128 MB di RAM per processo, con un consueto consigliato di 512 MB di RAM per processo. È un valore per processo PHP-FPM, non per l'intero sistema. Se lo si legge come "bastano 512 MB in totale" si sottodimensiona il server al primo utente che carica foto dal telefono.

Di seguito le taglie che reggono in pratica, partendo da Ubuntu 24.04 LTS, indicata come sistema operativo supportato nella documentazione ufficiale, che elenca Ubuntu 26.04 LTS come raccomandato e Ubuntu 24.04 LTS tra le opzioni supportate.

Quanta RAM per 10, 50 e 200 utenti

Utenti attivi	RAM VPS	vCPU	Note
10	2-4 GB	2	Apache/nginx + PHP-FPM + MariaDB/PostgreSQL sulla stessa macchina, senza Collabora/OnlyOffice
50	8 GB	4	Redis + APCu attivi, database su disco NVMe, preview generation moderata
200	16 GB	8	PHP-FPM in modalità static con più worker, database e cache dimensionati separatamente, da valutare split su macchine diverse se si aggiungono Collabora/Talk

Per 10 utenti un'istanza "nuda" (senza editor documenti né videoconferenza) sta comoda in 2 GB di RAM secondo la documentazione pubblica dei provider che lavorano quotidianamente su VPS Nextcloud: plain Nextcloud è leggero: un pool PHP, un database, Redis, un web server, e un'istanza piccola sta comoda in 2 GB. Con 50-200 utenti il collo di bottiglia non è quasi mai la RAM "di Nextcloud" ma il numero di worker PHP-FPM che si possono tenere aperti in parallelo, perché ogni richiesta è gestita da un processo worker di un pool PHP-FPM che possiede la richiesta dall'inizio alla fine, e memory_limit è un tetto per richiesta, non un'allocazione.

Parametri PHP da regolare dopo l'installazione

La documentazione ufficiale è netta su un punto: memory_limit dovrebbe essere di almeno 512MB. Da impostare in tutti i php.ini pertinenti (web server e CLI), perché il valore di memory_limit può andare configurato in più di un file php.ini, ad esempio per il web server e per la CLI usata dai cron job di Nextcloud.

Per l'upload di file superiori a 512 MB (il limite di default), la guida ufficiale indica di impostare upload_max_filesize a 16G e post_max_size a 16G nel file php.ini corrispondente. Attenzione però ad Apache: dalla versione 2.4.53 LimitRequestBody, che in Apache HTTP Server fino alla 2.4.53 era di default illimitato, ora ha un default di 1 GiB, limitando gli upload dei client non a chunk a 1 GiB. Se si alza upload_max_filesize ma si dimentica LimitRequestBody, gli upload grandi falliscono comunque.

Su nginx il parametro equivalente da controllare è client_max_body_size, e se l'istanza è dietro un reverse proxy o un load balancer per default i download saranno limitati a 1GB a causa di proxy_buffering e proxy_max_temp_file_size sul frontend: va disabilitato il buffering o alzato il limite sul frontend.

MySQL/MariaDB o PostgreSQL: cosa cambia dopo l'installazione

Nextcloud supporta su Ubuntu 24.04, secondo la documentazione aggiornata, Ubuntu 24.04 LTS, Ubuntu 22.04 LTS, e tra i database MariaDB nelle versioni correnti e PostgreSQL. Un requisito tecnico da non ignorare per chi usa MySQL/MariaDB: è richiesto il motore di storage InnoDB (MyISAM non è supportato) e il livello di isolamento delle transazioni "READ COMMITTED".

Cache: APCu e Redis, non sono opzionali sopra i 10 utenti

Sopra la decina di utenti attivi la cache locale smette di essere un optional. La documentazione ufficiale raccomanda, per organizzazioni con un singolo server, di usare Redis per tutto tranne la cache locale: memcache.local su APCu, memcache.distributed e memcache.locking su Redis. Un parametro che in pratica va quasi sempre alzato è apc.shm_size: il valore di default è 32M, di solito troppo basso per Nextcloud; un buon punto di partenza è 128M, da aumentare ulteriormente con molti utenti o molte app installate. Quella memoria va conteggiata nel bilancio RAM del VPS, non è gratis.

Per chi lavora con pool PHP-FPM dimensionati, una configurazione realistica per istanze da 50 utenti in su prevede memory_limit a 512M e un numero di worker calcolato sulla RAM disponibile dopo aver sottratto database e cache: con un memory_limit di 512 MB e un consumo medio reale di circa 180 MB per processo, su 16 GB di RAM totali si possono far girare in sicurezza 50-60 worker PHP-FPM, tenendosi larghi per non far scattare l'OOM killer.

Comandi per monitorare il consumo reale

Prima di cambiare taglia di VPS conviene misurare, non indovinare.

• htop per vedere in tempo reale quanta RAM occupano i processi php-fpm, il database e Redis/APCu, e se il sistema sta andando in swap.
• sudo -u www-data php occ files:scan --all per forzare una scansione completa dei file sul filesystem e verificare che l'indicizzazione non stia accumulando lavoro in background (utile dopo un ripristino da backup o una migrazione).
• php --ini per controllare quale php.ini è effettivamente caricato da CLI, utile quando i valori di memory_limit o upload_max_filesize sembrano non applicarsi: la documentazione ufficiale segnala che occorre verificare se si sta configurando il php.ini giusto, visto che il server web e la CLI usata dai cron job di Nextcloud possono leggere file diversi.
• free -h per avere il quadro totale di RAM libera, cache e swap prima di decidere se serve più memoria o solo tuning.

In sintesi

Non esiste un numero unico di RAM "per Nextcloud": la documentazione ufficiale lo dice esplicitamente parlando di requisiti per processo, non per server. Le taglie in tabella sono un punto di partenza verificabile; il numero vero per la propria istanza si ottiene misurando con htop e occ dopo le prime settimane di uso reale, e regolando memory_limit, apc.shm_size e numero di worker PHP-FPM di conseguenza.