How much RAM for a Nextcloud VPS: sizing for 10, 50 and 200 users

Anyone spinning up a Nextcloud instance on a VPS almost always starts with the wrong figure. The official Nextcloud documentation doesn't specify a minimum RAM requirement for the server: memory requirements for running a Nextcloud server vary significantly depending on the number of users, apps, files and activity volume. Nextcloud requires a minimum of 128 MB of RAM per process, with a typical recommendation of 512 MB of RAM per process. That's a per-process figure for PHP-FPM, not for the entire system. If you interpret it as "512 MB total is enough" you'll undersise the server the moment the first user starts uploading photos from their phone.

Below are the configuration tiers that work in practice, starting from Ubuntu 24.04 LTS, which is listed as a supported operating system in the official documentation, which recommends Ubuntu 26.04 LTS and lists Ubuntu 24.04 LTS among supported options.

RAM allocation for 10, 50 and 200 users

Active users	VPS RAM	vCPU	Notes
10	2–4 GB	2	Apache/nginx + PHP-FPM + MariaDB/PostgreSQL on the same machine, without Collabora/OnlyOffice
50	8 GB	4	Redis + APCu enabled, database on NVMe storage, moderate preview generation
200	16 GB	8	PHP-FPM in static mode with multiple workers, database and cache sized separately, consider splitting across machines if adding Collabora/Talk

For 10 users a "bare" instance (without document editors or video conferencing) runs comfortably on 2 GB of RAM according to documentation from hosting providers who work daily with Nextcloud VPS deployments: plain Nextcloud is lightweight—one PHP pool, one database, Redis, a web server—and a small instance fits comfortably in 2 GB. With 50–200 users the bottleneck is almost never Nextcloud's "RAM" itself but the number of PHP-FPM workers you can keep open in parallel, because each request is handled by one worker process from a PHP-FPM pool that owns the request from start to finish, and memory_limit is a per-request cap, not an allocation.

PHP parameters to adjust after installation

The official documentation is clear on one point: memory_limit should be at least 512 MB. Set it in all relevant php.ini files (web server and CLI), because memory_limit can be configured in multiple php.ini files—for example, one for the web server and one for the CLI used by Nextcloud's cron jobs.

For file uploads larger than 512 MB (the default limit), the official guide recommends setting upload_max_filesize to 16G and post_max_size to 16G in the corresponding php.ini file. Be careful with Apache though: since version 2.4.53, LimitRequestBody (which was unlimited by default in Apache HTTP Server up to 2.4.53) now defaults to 1 GiB, limiting non-chunked client uploads to 1 GiB. If you raise upload_max_filesize but forget LimitRequestBody, large uploads will fail anyway.

On nginx the equivalent parameter to check is client_max_body_size, and if the instance is behind a reverse proxy or load balancer, downloads will be limited to 1 GB by default due to proxy_buffering and proxy_max_temp_file_size on the frontend: buffering should be disabled or the limit raised on the frontend.

MySQL/MariaDB or PostgreSQL: what changes after installation

Nextcloud supports, on Ubuntu 24.04 according to updated documentation, Ubuntu 24.04 LTS, Ubuntu 22.04 LTS, and among databases MariaDB in current versions and PostgreSQL. A technical requirement to not overlook for MySQL/MariaDB users: the InnoDB storage engine is required (MyISAM is not supported) and transaction isolation level must be "READ COMMITTED".

Caching: APCu and Redis are not optional above 10 users

Above ten active users, local caching stops being optional. The official documentation recommends, for organisations with a single server, using Redis for everything except local cache: memcache.local on APCu, memcache.distributed and memcache.locking on Redis. One parameter that almost always needs raising is apc.shm_size: the default value is 32 MB, usually too low for Nextcloud; a good starting point is 128 MB, to be increased further with many users or many installed apps. That memory needs to be counted in your VPS RAM budget—it's not free.

For those working with sized PHP-FPM pools, a realistic configuration for 50+ user instances sets memory_limit to 512 MB and calculates worker count based on available RAM after subtracting database and cache: with a memory_limit of 512 MB and real average consumption of roughly 180 MB per process, on 16 GB total RAM you can safely run 50–60 PHP-FPM workers while leaving headroom to avoid triggering the OOM killer.

Commands to monitor real consumption

Before changing VPS tier, measure—don't guess.

• htop to see in real time how much RAM is used by php-fpm processes, the database and Redis/APCu, and whether the system is swapping.
• sudo -u www-data php occ files:scan --all to force a complete scan of files on the filesystem and verify that indexing isn't accumulating background work (useful after restoring from backup or migrating).
• php --ini to check which php.ini is actually loaded by CLI, useful when memory_limit or upload_max_filesize values seem not to apply: the official documentation notes that you need to verify you're configuring the right php.ini, since the web server and the CLI used by Nextcloud's cron jobs can read different files.
• free -h to get the complete picture of free RAM, cache and swap before deciding whether you need more memory or just tuning.

In summary

There is no single RAM figure "for Nextcloud": the official documentation states this explicitly by talking about per-process requirements, not per-server. The tiers in the table are a verifiable starting point; the real number for your instance comes from measuring with htop and occ after a few weeks of real usage, then adjusting memory_limit, apc.shm_size and PHP-FPM worker count accordingly.