Nextcloud 30 timeout on VPS: fix PHP-FPM, Redis locking, cron, MariaDB, and reverse proxy mistakes so your stack stays stable more than just 3 months

If your Nextcloud 30 VPS feels fine for the first week and then starts throwing timeouts, slow syncs, stuck background jobs, or random 502 and 504 errors, the problem is usually not “Nextcloud is bad.” The problem is the stack around it. The production-safe pattern is simple: run Nextcloud 30 on PHP 8.3-FPM, MariaDB 10.11 or PostgreSQL, Redis for locking and distributed cache, APCu for local cache, a real cron runner every 5 minutes, and a reverse proxy that is configured for long uploads and the correct FPM socket. That is the combination that stays stable after the honeymoon period.

The real reason Nextcloud starts timing out after a few weeks

Fresh Nextcloud installs lie to you. Day 1 looks clean because the database is tiny, previews are barely generated, background jobs have not piled up, file locking is light, and you probably have one user. Month 3 is where the real system shows up. Thumbnails exist. Mobile clients are hammering WebDAV. Activity cleanup jobs are overdue. A few large folders are syncing. Maybe Talk or Office got enabled. Maybe someone left the instance on AJAX background jobs because the UI worked and nobody looked again.

In our experience managing production Linux servers, the common failure pattern looks like this:

• PHP-FPM is still on a default pool that is too small for concurrent requests.
• Redis is missing, so transactional file locking falls back to the database.
• Background jobs are still on AJAX or Webcron, so cleanup and maintenance lag behind.
• MariaDB is running, but with defaults that are safe for booting, not for sustained concurrency.
• NGINX or the reverse proxy is fine for a brochure site, but wrong for large WebDAV uploads and long-running PHP requests.
• Preview generation, antivirus scanning, or office integrations were added without revisiting RAM, CPU, and cron windows.

That is why this article is not another “install Nextcloud in 10 minutes” post. That content already exists on the web, and you already have an older install guide at ServerSpan. This one is about making a VPS survive daily use.

The stack we would actually trust on a single production VPS

For a small business, family cloud, or internal team instance that must stay online without babysitting, this is the baseline we would start with:

• Debian 12 or Ubuntu 24.04 on a KVM VPS, not a bargain shared environment that hides the storage and CPU story.
• NGINX in front of PHP 8.3-FPM.
• MariaDB 10.11 for a single-node deployment, or PostgreSQL if your team prefers it and knows it well.
• Redis on a UNIX socket for locking and distributed cache.
• APCu for local cache.
• System cron every 5 minutes, or a systemd timer that runs cron.php every 5 minutes.
• Data directory outside the web root.
• No SQLite for production. It is fine for testing. It is the wrong choice for a real multi-user VPS.

For sizing, stop trying to run a “serious” Nextcloud on scraps. A lab box is one thing. A production instance with desktop sync, thumbnails, large uploads, and multiple users is another. On a small dedicated Nextcloud deployment, 4 GB RAM is where life gets less stupid. Once you add Office, Talk, heavy photo libraries, external storage scans, or antivirus, you should expect to move higher.

If you need the infrastructure layer ready first, ServerSpan virtual servers give you full root access and room to tune the stack properly. If you do not want to own the Linux side forever, that is where Linux administration becomes the sane handoff.

The PHP-FPM pool that stops the “works fine until two people click at once” problem

Official Nextcloud guidance is blunt here: default PHP-FPM settings can cause excessive load times and sync issues. That matches what we see in real deployments. The stock pool is often tuned for “PHP exists,” not for a WebDAV-heavy app that fans out concurrent requests.

On a 4 GB VPS dedicated mainly to Nextcloud, this is a safe starting point for a dedicated pool in /etc/php/8.3/fpm/pool.d/nextcloud.conf:

[nextcloud]
user = www-data
group = www-data

listen = /run/php/php8.3-fpm-nextcloud.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660

pm = dynamic
pm.max_children = 12
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 4
pm.max_requests = 500

request_terminate_timeout = 300s
request_slowlog_timeout = 10s
slowlog = /var/log/php8.3-fpm/nextcloud-slow.log

php_admin_value[memory_limit] = 768M
php_admin_value[upload_max_filesize] = 10G
php_admin_value[post_max_size] = 10G
php_admin_value[max_execution_time] = 3600
php_admin_value[max_input_time] = 3600
php_admin_value[output_buffering] = 0

Why these values? Because you need enough parallel workers to absorb sync bursts, and you need hard evidence when one request goes rogue. The slowlog matters. It tells you whether the bottleneck is PHP code, an external storage mount, preview generation, or a database wait. Most people skip it. That is dumb.

After reloading PHP-FPM, watch real pressure instead of guessing:

systemctl reload php8.3-fpm
journalctl -u php8.3-fpm -n 100 --no-pager
tail -f /var/log/php8.3-fpm/nextcloud-slow.log
ps --no-headers -o "rss,cmd" -C php-fpm8.3 | sort -nr | head

If individual FPM workers are consuming far more memory than expected, do not “solve” it by cranking pm.max_children upward until the OOM killer joins the conversation. Fix the workload first. Your old PHP-FPM vs. OOM killer guide is relevant here too.

The cache and locking setup that removes pointless database pain

Nextcloud’s own documentation recommends APCu plus Redis on single-server installs, and specifically notes that database-backed file locking puts significant load on the database. This is one of the biggest “month 3” killers because the system looks functional without Redis, but it ages badly under real sync activity.

Install the packages first:

apt update
apt install -y redis-server php8.3-redis php8.3-apcu

Then prefer the UNIX socket because Redis is on the same machine:

grep -E '^(port|unixsocket|unixsocketperm)' /etc/redis/redis.conf

usermod -a -G redis www-data
systemctl restart redis-server
systemctl restart php8.3-fpm

And put this in config/config.php:

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

Also fix CLI APCu so cron runs do not complain or behave differently:

echo 'apc.enable_cli=1' > /etc/php/8.3/cli/conf.d/99-nextcloud-apcu.ini
php -i | grep apc.enable_cli

That small detail is missed constantly. Then people wonder why the web UI is fine but cron jobs complain about cache or background execution.

The database baseline that keeps concurrency from turning ugly

Nextcloud 30 officially supports MariaDB 10.6, 10.11, and 11.4, while SQLite is only recommended for testing and minimal instances. For a real VPS deployment, run MariaDB 10.11 or PostgreSQL and configure the basics correctly. If you are on MariaDB or MySQL, Nextcloud also requires the READ COMMITTED isolation level and either disabled binary logging or BINLOG_FORMAT = ROW.

This is a sane MariaDB baseline for a single Nextcloud node on a 4 GB VPS in /etc/mysql/mariadb.conf.d/60-nextcloud.cnf:

[mysqld]
transaction_isolation = READ-COMMITTED
binlog_format = ROW

innodb_buffer_pool_size = 1G
innodb_log_file_size = 256M
max_connections = 100

character-set-server = utf8mb4
collation-server = utf8mb4_general_ci

Then restart and verify:

systemctl restart mariadb
mysql -e "SHOW VARIABLES LIKE 'transaction_isolation';"
mysql -e "SHOW VARIABLES LIKE 'binlog_format';"
mysql -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';"

Do not blindly run full occ files:scan --all every time the database feels slow. That command is useful in the right context. It is also one of the fastest ways to create extra work on a box that is already in pain.

The background-job runner that stops maintenance from rotting silently

Nextcloud’s official recommendation is cron, not AJAX and not Webcron, for any real instance. AJAX is the least reliable option, and Webcron is only suitable for very small setups. That lines up with reality. If your instance is used daily, background jobs must not depend on page visits.

You can use classic cron. You can also use a systemd timer that runs cron.php every 5 minutes. For Linux VPS work, we prefer the systemd route because logs and status are cleaner.

# /etc/systemd/system/nextcloudcron.service
[Unit]
Description=Nextcloud cron.php job

[Service]
User=www-data
ExecCondition=php -f /var/www/nextcloud/occ status -e
ExecStart=/usr/bin/php -f /var/www/nextcloud/cron.php
KillMode=process

# /etc/systemd/system/nextcloudcron.timer
[Unit]
Description=Run Nextcloud cron.php every 5 minutes

[Timer]
OnBootSec=5 min
OnUnitActiveSec=5 min
Unit=nextcloudcron.service

[Install]
WantedBy=timers.target

systemctl daemon-reload
systemctl enable --now nextcloudcron.timer
systemctl list-timers --all | grep nextcloud
journalctl -u nextcloudcron.service -n 100 --no-pager

Also set a maintenance window so non-time-sensitive jobs stay out of working hours:

sudo -u www-data php /var/www/nextcloud/occ config:system:set maintenance_window_start --type=integer --value=1

That uses 01:00 UTC as the start of the maintenance window. Adjust it to your real quiet period. On a Romanian business instance, that matters because the default “whenever” approach lets heavy background work collide with actual daytime use.

The reverse proxy and NGINX settings that stop fake “timeouts”

Plenty of “Nextcloud timeout” tickets are really reverse-proxy mistakes. Wrong FPM socket. Missing trusted proxy settings. Too-small upload limits. Broken /.well-known handling. A global dotfile deny rule that kills large uploads because Nextcloud uses a URL ending in /.file. These are boring mistakes, but they are common.

Start from the official Nextcloud NGINX example, then verify these parts first:

upstream php-handler {
    server unix:/run/php/php8.3-fpm-nextcloud.sock;
}

server {
    listen 443 ssl http2;
    server_name cloud.example.com;
    root /var/www/nextcloud;

    client_max_body_size 10G;
    client_body_timeout 300s;
    send_timeout 300s;
    fastcgi_buffers 64 4K;
    client_body_buffer_size 512k;
}

location ~ \.php(?:$|/) {
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_param PATH_INFO $path_info;
    fastcgi_param HTTPS on;
    fastcgi_param modHeadersAvailable true;
    fastcgi_param front_controller_active true;
    fastcgi_pass php-handler;
    fastcgi_intercept_errors on;
    fastcgi_request_buffering on;
    fastcgi_read_timeout 600s;
}

location ^~ /.well-known {
    location = /.well-known/carddav { return 301 /remote.php/dav/; }
    location = /.well-known/caldav  { return 301 /remote.php/dav/; }
    return 301 /index.php$request_uri;
}

location ~ /\.(?!file).* {
    deny all;
}

The important operational point is this: make NGINX and PHP-FPM agree on the same listener. If NGINX points to /run/php/php8.3-fpm-nextcloud.sock and your pool is still listening on 127.0.0.1:9000, you did not deploy a stack. You deployed a 502 generator.

If you are behind a reverse proxy or TLS terminator, fix Nextcloud’s detection explicitly:

'trusted_domains' => ['cloud.example.com'],
'overwrite.cli.url' => 'https://cloud.example.com',
'overwriteprotocol' => 'https',
'trusted_proxies' => ['127.0.0.1'],

Change the proxy IPs to match your real path. Do not cargo-cult this section. Wrong proxy trust settings create their own security and logging problems.

The OPcache settings worth changing, and the ones you should leave alone

Enable OPcache and keep comments enabled. That part is straightforward. What is not straightforward is over-tuning revalidation because someone on a forum wanted a benchmark screenshot.

opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.save_comments=1

For most single-node VPS deployments, leave timestamp validation on and keep the default revalidation behavior unless you have a reason to change it. Nextcloud’s own docs warn that aggressive OPcache revalidation tuning can cause odd behavior after upgrades or config changes if you forget to restart PHP-FPM. That warning is real. Do not optimize yourself into ghosts.

The two things people enable that change the hardware question completely

Nextcloud Talk and office or preview-heavy workloads change the project.

Large photo libraries generate preview pressure. Talk adds real-time traffic and session behavior. Rich document editing adds more moving pieces. If your use case includes those, be honest about it. A 4 GB VPS may still work, but your margin disappears faster. Nextcloud’s docs point to Imaginary for faster previews, but that is another service to run and it is incompatible with server-side encryption. That is not a reason to avoid Nextcloud. It is a reason to stop pretending every deployment is “just files and folders.”

The production triage checklist when the timeout has already started

• Check whether background jobs are really running: journalctl -u nextcloudcron.service -n 100 --no-pager
• Check PHP-FPM slowlog and recent service errors.
• Check Redis socket permissions and whether www-data can use it.
• Check NGINX error log for upstream timeout, bad gateway, or body-size failures.
• Check Nextcloud log at /var/www/nextcloud/data/nextcloud.log
• Check admin warnings for cache, database isolation, or reverse proxy issues.
• Check whether someone left debug enabled in config.php.

tail -f /var/www/nextcloud/data/nextcloud.log
tail -f /var/log/nginx/error.log
journalctl -u php8.3-fpm -u redis-server -u mariadb -n 200 --no-pager
sudo -u www-data php /var/www/nextcloud/occ status
sudo -u www-data php /var/www/nextcloud/occ config:list system

If the box is swapping, fix that first. Nextcloud’s own tuning guidance says swap usage should be prevented by all means. That sounds dramatic, but on a small VPS it is accurate. A swapping Nextcloud stack is a timeout machine.

When this stops being a tuning issue and becomes a sizing issue

Be honest about the boundary. If your users are syncing huge media libraries, if multiple people are hammering WebDAV all day, if previews never finish, or if Office and Talk are part of the business workflow, there comes a point where “tune harder” is just denial. You need more RAM, faster storage, or a split architecture.

That is also why we do not recommend starting a serious production Nextcloud on the smallest possible plan just because it boots. A lab instance and a relied-on daily cloud are different categories of system.

The practical answer

If Nextcloud 30 on your VPS keeps timing out, stop blaming the app first and audit the stack. Move background jobs to real cron or a systemd timer. Put file locking on Redis. Use APCu for local cache. Give PHP-FPM a real pool and a slowlog. Run MariaDB with the transaction and binary-log settings Nextcloud expects. Fix the reverse proxy. Then size the VPS like a production system, not like a toy.

If you want the base install steps, your older Nextcloud on your VPS guide still covers the setup path. If you are planning which features to keep lean, your 2026 Nextcloud apps guide is the right follow-up. If you are building a broader self-hosted stack around this box, your self-hosted Git server tutorial fits the same operational bucket.

If you want a VPS that gives you full control over this stack, start with ServerSpan VPS hosting. If you want someone else to tune, repair, and keep this Linux stack alive after the install tutorial ends, use ServerSpan Linux administration.