Nextcloud is the file sync and share that people reach for when they want to stop renting the same thing. It comes with calendars, contacts, an office suite and a large application catalogue, which explains both its appeal and its weight compared to the alternatives.

The first decision is not a setting. It is which of two official routes you are taking, and they are not variations on each other.

All-in-one, or the plain image

The all-in-one deployment is the project's own recommendation. You run one master container and it manages the rest — the application, the database, the cache, the office suite — from a small administrative interface. Updates and backups are its job rather than yours.

The plain image is a single service you assemble into a compose file alongside a database and cache you choose and maintain. More work, more control, and it looks like every other service in your stack rather than a system that manages itself.

Neither is wrong, but following instructions for one while running the other causes trouble. It is an easy mistake to make, as both are official, both are current, and search results do not always say which they are describing. If a guide talks about a master container and an administrative interface on its own port, that is the all-in-one; if it hands you a compose file with a database service in it, that is the plain image.

Trusted domains will refuse you

Nextcloud only answers to hostnames on its trusted list. Arrive by any other name and it does not redirect or warn; it refuses, with a message about an untrusted domain.

This surprises people at exactly the moment they put a reverse proxy in front, because the name changes from an address and port to a real hostname and the list still contains the old one. Before you point a proxy at it, set the trusted domains to the names you will actually use. Remember to list every name it needs to answer to; a local name and a public one are two separate entries.

The PHP limits are environment variables, not a file

Large uploads and some maintenance commands need more memory than the default allows, and the instinct is to find a PHP configuration file and edit it.

In these images the limits are set through environment variables instead. This keeps the configuration in one place and prevents edits inside a running container from being lost on the next update. Set them in the compose file where they will survive.

Note that open reports suggest the memory setting does not always apply cleanly in the all-in-one deployment. If a limit appears to be ignored, that is a known issue rather than a mistake you made.

Do not swap image variants over an existing volume

The images come in variants built on different base systems. They are not interchangeable once data exists, because the user that owns the files inside differs between them.

Switch from one to the other over a volume that already has a Nextcloud installation in it and the application arrives unable to write to its own data. The symptom is a wall of permission errors, with nothing that points to the actual cause.

Pick a variant at the start and stay on it. If you must move, expect to correct ownership across the data directory deliberately rather than hoping it sorts itself out.

What it costs to run

More than the other services in this stack. It is a PHP application with a database, a cache and a background job runner, and it wants memory rather than cleverness.

The background jobs are the part people skip. Nextcloud has maintenance work that must run on a schedule, and the default arrangement — triggering it from web requests — is the slowest and least reliable option. Moving background jobs to a proper scheduled task is the single biggest change you can make for responsiveness. Do it on the first day, not after you have already concluded the software is slow.

Where this comes from, and what will date

Composed from the project's own container documentation for both deployment routes together with several independent published setups and community reports, cross-checked against each other on 31 August 2026. The all-in-one deployment changes faster than the plain image, so check its current documentation rather than any article about it, including this one.

The application catalogue is where installations go wrong later. Each addition is more code running with access to your files, and each is maintained by someone. Install what you will use and revisit the list occasionally, because an abandoned application does not announce that it has been abandoned.