Which Server for Nextcloud? Sizing RAM, CPU and Storage

Nextcloud sizing usually starts with a single number: how many users. That number alone is not enough, because 50 users running desktop sync behave very differently from 50 users editing documents in Nextcloud Office. This tutorial converts user count, concurrency and enabled apps into concrete vCPU, RAM and disk figures, and shows the commands that confirm the sizing on a running instance.

What server do you need for Nextcloud?

A server for Nextcloud needs roughly 2 vCPU and 4 GB RAM for up to 5 concurrent users, 4 vCPU and 8 GB for 25, and 8 vCPU with 16 GB for around 100 concurrent users.

The decisive input is concurrent users, not registered accounts. In typical office use, 10 to 20 percent of registered accounts are active at the same moment. A 500-account instance with normal working hours therefore behaves like a 50 to 100 user system, and that is the number you size against.

User data is sized separately from the system disk. Keep the Nextcloud data directory on its own volume so it can grow without touching the root filesystem.

Prerequisites

• A Linux host with root or sudo access, for example Debian 12 or Ubuntu 24.04
• Nextcloud 30 or newer, installed with PHP-FPM (PHP 8.2 or 8.3; PHP 8.3 is the current recommendation)
• MariaDB 10.11 or newer, or PostgreSQL 14 or newer. SQLite is only acceptable for single-user test instances
• Redis for distributed caching and file locking, plus the APCu extension for the local cache
• A separate block volume or partition for the data directory

All figures below assume a virtual machine whose resources you can change later. On a scalable Cloud-VPS you can raise vCPU and RAM after the first month of real usage data instead of guessing high on day one.

How much RAM does Nextcloud need per user?

Nextcloud needs about 80 to 120 MB of RAM per active PHP-FPM worker, plus 1 GB for the operating system and 1 to 4 GB for the database, so 8 GB covers roughly 25 concurrent users.

RAM is not consumed per registered account. It is consumed per request in flight, and each in-flight request occupies one PHP-FPM child process. The sizing question is therefore how many children you can afford:

pm.max_children = (total RAM - OS - database - Redis) / average worker RSS

On an 8 GB machine with MariaDB on the same host, that works out as 8192 MB minus 1024 MB for the OS, 2048 MB for MariaDB and 256 MB for Redis, leaving 4864 MB. At 100 MB per worker that allows about 48 children. Round down to leave headroom:

; /etc/php/8.3/fpm/pool.d/nextcloud.conf
pm = dynamic
pm.max_children = 40
pm.start_servers = 8
pm.min_spare_servers = 4
pm.max_spare_servers = 12
pm.max_requests = 500
php_admin_value[memory_limit] = 512M

The memory_limit of 512M is the value Nextcloud expects. It is a per-request ceiling, not the steady-state consumption, and only preview generation or large occ runs come close to it.

Caching removes a large share of that memory pressure. Without APCu and Redis, every request re-reads configuration and app metadata, and file locking falls back to the database:

<?php
$CONFIG = array (
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'memcache.distributed' => '\\OC\\Memcache\\Redis',
  'memcache.locking' => '\\OC\\Memcache\\Redis',
  'redis' => array (
    'host' => '/run/redis/redis-server.sock',
    'port' => 0,
  ),
);

Size the CPU

Budget one vCPU per 6 to 10 concurrent sync users. Every Nextcloud request is handled by a single-threaded PHP process, so throughput scales with core count, not with clock speed alone.

Three workloads dominate CPU usage and each of them needs its own allowance:

• Background jobs. cron.php runs every 5 minutes and handles file scans, notifications and cleanup. On instances above 100 accounts, reserve at least one core for it.
• Preview generation. Generating thumbnails for images and video is the single most expensive operation on a file server. The previewgenerator app moves this work into cron instead of the request path.
• Nextcloud Office. Collabora Online is a separate process tree. Plan 1 vCPU and 2 GB RAM per roughly 20 concurrently open documents, and run it on its own host once you pass that point.

Shared-CPU instances are adequate for the 1–25 user tiers, where load is bursty and idle most of the day. Above 25 concurrent users, or whenever Collabora and full-text search run on the same machine, use dedicated CPU so preview jobs do not compete for cycles with interactive requests.

Size the storage

Calculate Nextcloud storage as quota times user count, then add 30 to 50 percent for file versions and trash, 5 to 15 percent for previews, and roughly 1 GB of database per million stored files.

Capacity is only half of the requirement. Sync clients produce many small random reads and writes, so IOPS matters more than sequential throughput. NVMe-backed volumes are the baseline; spinning disks make the initial occ files:scan of a large dataset take hours.

For datasets beyond a few hundred gigabytes, move the bulk data off the system volume rather than growing the VM disk indefinitely. An external block volume keeps the instance small enough to snapshot quickly, and S3-compatible primary storage removes the size ceiling entirely at the cost of higher per-request latency.

Plan the layout before you deploy

Decide the topology before installing anything. Splitting roles after the fact means migrating the database and re-pointing the data directory, which is far more work than starting with the right layout.

graph TD
  A["Concurrent users"] --> B{"More than 25?"}
  B -- "No" --> C["Single VM: 4 vCPU / 8 GB"]
  B -- "Yes" --> D{"Office or Talk in use?"}
  D -- "No" --> E["Single VM: 8 vCPU / 16 GB"]
  D -- "Yes" --> F["App VM + Collabora / Talk HPB VM"]
  C --> G{"Data over 500 GB?"}
  E --> G
  F --> G
  G -- "No" --> H["Local NVMe volume"]
  G -- "Yes" --> I["Block volume or S3 primary storage"]

Verify the sizing on a running instance

Estimates are a starting point. After two weeks of production use, measure the real numbers and adjust.

Start with the actual activity, not the account list. occ user:report separates registered accounts from users active in the last 24 hours and 7 days:

$ sudo -u www-data php /var/www/nextcloud/occ user:report
+------------------+-----+
| User Report      |     |
+------------------+-----+
| standard account | 128 |
| guest            | 0   |
| total users      | 128 |
+------------------+-----+
| active users     |     |
| last 24 hours    | 21  |
| last 7 days      | 96  |
+------------------+-----+

A daily peak of 21 active users on 128 accounts confirms the 10–20 percent assumption, which places this instance in the 5–25 concurrent tier.

Next, measure the average memory footprint of a PHP-FPM worker instead of using the 100 MB estimate:

$ ps -o rss= -C php-fpm8.3 | awk '{s+=$1; n++} END {printf "%d workers, avg %.0f MB\n", n, s/n/1024}'
14 workers, avg 96 MB

Check how much memory is genuinely free rather than cached, and how large the database has grown:

$ free -h
$ sudo mysql -e "SELECT ROUND(SUM(data_length+index_length)/1024/1024) AS mb FROM information_schema.tables WHERE table_schema='nextcloud';"

If the available column in free -h stays above 20 percent of total RAM during working hours, the memory sizing holds. If it drops below that, either raise RAM or lower pm.max_children.

Troubleshooting

Sync clients report 504 Gateway Timeout. The PHP-FPM pool has run out of children. Confirm it in the log and either raise pm.max_children if RAM allows, or add RAM:

$ sudo grep -c "server reached pm.max_children" /var/log/php8.3-fpm.log

The web interface is slow while sync runs. This is usually storage, not CPU. Run iostat -x 5 3 from the sysstat package and look at %util and await on the data volume. Sustained utilisation near 100 percent means the volume cannot keep up with the random I/O of sync clients.

occ commands or uploads abort with a memory error. Preview generation on large images is the usual cause. Verify that memory_limit is 512M in the PHP-FPM pool and in /etc/php/8.3/cli/php.ini, and cap preview sizes with preview_max_x and preview_max_y at 2048 in config.php.

Wrap-up

Size against concurrent users, not registered accounts, and derive RAM from pm.max_children times the measured worker footprint rather than a per-user figure. Start one tier above your current concurrency, measure with occ user:report and free -h after two weeks, and move Collabora or bulk storage onto separate resources before the single VM becomes the bottleneck.

Read next

• Back Up and Restore Nextcloud: Data, Database, Config
• Install Nextcloud All-in-One with Docker
• Install Nextcloud on Ubuntu 24.04 with nginx
• Mount Nextcloud via WebDAV on Linux, Windows and macOS
• Nextcloud vs ownCloud vs Seafile: Which One Fits?
• Run Nextcloud with Docker Compose
• Set Up Nextcloud Office: Collabora or OnlyOffice
• Updating Nextcloud: Web Updater, occ and a Rollback Plan
• What Is Nextcloud? Architecture, Components and Use Cases