Self-Hosting Nextcloud: What I Set Up Differently From the Defaults

Nextcloud comes up regularly with clients who want a self-hosted alternative to Dropbox or Google Drive, usually for a mix of cost (per-seat cloud storage pricing adds up with a team) and data residency reasons (keeping company files on infrastructure they control). The install itself is straightforward, a web installer handles most of it. What separates a Nextcloud instance that works from one that people actually keep using instead of quietly going back to whatever they used before is a handful of settings that aren't wrong by default, just not tuned for real use.

Cron, not AJAX

By default, Nextcloud's background jobs (file scanning, notifications, cleanup tasks) run via AJAX, triggered by page loads in the browser. This works, technically, but it means background jobs only run when someone happens to have the web UI open, and can make page loads feel sluggish since they're doing extra work. Switching to a system cron job (or better, a systemd timer) running every five minutes is a config change in the admin settings plus one line:

# crontab for the web server user
*/5 * * * * php -f /var/www/nextcloud/cron.php

After this change, background jobs run reliably on schedule regardless of whether anyone's using the web interface, and page loads no longer carry that extra work.

Memory caching: APCu and Redis

Nextcloud's performance, especially for the web UI and for clients syncing many small files, depends heavily on caching being configured. Without it, every request re-reads configuration and file-locking state from the database. The recommended setup uses both: APCu for local memory caching, and Redis for file locking (which needs to be shared across requests, and across multiple app servers if there's more than one):

// config/config.php
'memcache.local' => '\OC\Memcache\APCu',
'memcache.locking' => '\OC\Memcache\Redis',
'redis' => [
    'host' => '127.0.0.1',
    'port' => 6379,
],

The difference this makes is most noticeable in the web UI, folder navigation and file listing go from "noticeably waiting" to close to instant, because the metadata Nextcloud needs is coming from memory instead of round-tripping to the database and filesystem on every request.

Upload limits live in three places

"I can't upload files larger than X" is one of the most common Nextcloud issues, and the reason is that the upload size limit needs to agree across PHP, the web server, and Nextcloud's own setting, whichever is smallest wins:

; php.ini
upload_max_filesize = 16G
post_max_size = 16G

# nginx
client_max_body_size 16G;

// config/config.php
'upload_max_filesize' => '16G',

Missing any one of these means uploads fail at whatever the lowest limit happens to be, often with an error message that doesn't make it obvious which of the three layers is the actual culprit. Setting all three consistently, even generously, avoids a confusing troubleshooting session the first time someone tries to upload a large video file.

Trusted domains, before anyone hits a wall

Nextcloud refuses to load if accessed via a hostname not in its trusted_domains list, a security measure, but one that produces a confusing error for the first person who tries the "wrong" URL (an internal hostname, an IP address, a new domain after a migration):

// config/config.php
'trusted_domains' => [
  'cloud.example.com',
  '10.0.0.5',
],

Adding every hostname or IP that should reasonably reach the instance, including internal ones used for health checks or admin access, up front avoids this being the first thing anyone has to debug.

Sizing expectations and backups

For a small team (a handful to a few dozen users), Nextcloud runs comfortably on the same kind of VPS that runs a small WordPress site, the load per user is modest unless people are doing a lot of simultaneous large file operations. The thing that grows is storage, obviously, and that's the part worth planning for: the data directory needs backup just like a database does, and for a service whose entire purpose is "the place where files live," restoring it correctly (file permissions, the data directory structure, the database, and the config all need to match) is worth testing once, the same way restoring a database backup is worth testing once, before the day it's needed for real.

None of these changes are difficult, and none of them are things the installer gets wrong, exactly. They're just the difference between a Nextcloud instance that technically works on day one and one that still feels fast and reliable a year in, after real usage, real file volumes, and real upload sizes have had a chance to find every default that wasn't quite tuned for them.