Skip to content
EuroVPSEuroVPS

Why Nextcloud feels slow, and what actually fixes it

A slow Nextcloud is rarely short of hardware. Background jobs, caching, locking, indices and the office editor, checked in order, with exact settings.

By EuroVPS Engineering

5 min read
Why Nextcloud feels slow, and what actually fixes it

When a Nextcloud instance feels sluggish, the first instinct is to give it more CPU and memory. Usually that changes nothing, because the time is going somewhere else: background jobs that run in the wrong place, a cache that is not configured, file locks hitting the database, a table missing an index. This is the order we check things in, with the settings that fix each one. Everything here applies whether Nextcloud runs on a plain server or in containers.

Start with what Nextcloud already tells you

Nextcloud ships its own health checks. Run them before changing anything:

sudo -u apache php occ setupchecks
sudo -u apache php occ status

Use the web server's user (apache, www-data or nginx, depending on your system). The same results appear under Administration settings, Overview. Every warning there is a real finding. Fix them first; several of the items below will appear in that list.

Background jobs must not ride on page loads

Nextcloud has housekeeping to do: file scans, previews, notifications, cleanup, activity expiry. By default, in AJAX mode, it runs one job each time a user loads a page. Users pay for housekeeping with their own page loads, and on a quiet instance the jobs fall behind.

Switch to system cron:

sudo -u apache php occ background:cron

Then run cron.php every five minutes. A systemd timer is cleaner than a crontab entry because it logs failures:

# /etc/systemd/system/nextcloud-cron.service
[Service]
Type=oneshot
User=apache
ExecStart=/usr/bin/php -f /var/www/nextcloud/cron.php

# /etc/systemd/system/nextcloud-cron.timer
[Timer]
OnBootSec=5min
OnUnitActiveSec=5min
[Install]
WantedBy=timers.target

Enable it with systemctl enable --now nextcloud-cron.timer. While you are there, set a maintenance window so heavy jobs run at night:

sudo -u apache php occ config:system:set maintenance_window_start --type=integer --value=1

The value is an hour in UTC; heavy jobs will run in the four hours that follow.

Caching and file locking

Without a memory cache, Nextcloud asks the database for the same things over and over. Without a proper locking backend, every file operation takes a lock in the database too. Configure both in config.php:

'memcache.local' => '\OC\Memcache\APCu',
'memcache.distributed' => '\OC\Memcache\Redis',
'memcache.locking' => '\OC\Memcache\Redis',
'redis' => [
  'host' => '/run/redis/redis.sock',
  'port' => 0,
],

APCu is the fast local cache inside each PHP process. Redis holds shared state and file locks. Use a Unix socket if Redis is on the same machine, and make sure the web server's user can open it.

APCu also needs enabling for the command line, or occ will complain:

; /etc/php.d/40-apcu.ini
apc.enable_cli=1

PHP itself: OPcache and the FPM pool

Nextcloud is a large PHP application. Without enough OPcache, PHP recompiles parts of it on every request. Typical starting values:

opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=32
opcache.max_accelerated_files=20000
opcache.revalidate_freq=60

setupchecks will tell you if the interned strings buffer is too small. Then size the PHP-FPM pool to the memory you actually have: pm.max_children multiplied by the typical memory of one PHP worker must fit in RAM with room left for the database and Redis. Measure a worker's real memory under load before choosing, rather than copying a number from a forum.

The database: indices and big integers

Upgrades sometimes add indices and columns that existing installations do not get automatically, because creating them on a big table takes time. Nextcloud leaves that step to you:

sudo -u apache php occ db:add-missing-indices
sudo -u apache php occ db:add-missing-columns
sudo -u apache php occ db:add-missing-primary-keys
sudo -u apache php occ db:convert-filecache-bigint

Run these after every major upgrade, in a maintenance window, because they can lock large tables. A missing index on the file cache table is one of the most common reasons a large instance feels slow when browsing folders.

Previews: generate them ahead of time

Thumbnails are generated the first time someone opens a folder. A folder of high-resolution photos means a slow first visit for whoever gets there first. Two things help. Limit preview sizes:

sudo -u apache php occ config:system:set preview_max_x --value=2048 --type=integer
sudo -u apache php occ config:system:set preview_max_y --value=2048 --type=integer

And, if your users store a lot of images, use the Preview Generator app to create previews in the background job instead of on demand.

The office editor is its own workload

Browser editing with Collabora runs as a separate service. Nextcloud sends it the document, and Collabora renders and edits it. When people say "Nextcloud is slow" while editing, the bottleneck is usually Collabora, not Nextcloud. Watch its CPU and memory separately, while several people edit large spreadsheets at once, and size it from those measurements.

Two configuration points matter for both speed and safety. Point Nextcloud at Collabora over a path that is fast and close. And restrict which servers may talk to Collabora's WOPI interface:

sudo -u apache php occ config:app:set richdocuments wopi_allowlist --value="10.0.0.0/24"

Use your own Nextcloud server's address range there, so only your Nextcloud can open documents through your editor.

Pin what runs

If you run Nextcloud in containers, pin every image (Nextcloud, database, Redis, Collabora) to a tag you chose.

The order, in short

  1. occ setupchecks and fix every warning.
  2. System cron through a timer, plus a maintenance window.
  3. APCu locally, Redis for locking and shared cache.
  4. OPcache sized properly and an FPM pool sized from measurements.
  5. Missing indices, columns and keys added after each upgrade.
  6. Previews limited and generated in the background.
  7. Collabora measured and sized as its own service, with a WOPI allow list.
  8. Every component pinned to a version you chose.

Only after all of that does adding hardware tell you anything useful. We run Nextcloud with Collabora this way for our customers on dedicated instances, and we are happy to look at yours.

Talk to an engineer

Published 22 October 2026.

All field notes