.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
Nextcloud AIO leads a strange double life. It sits in the official docs as the recommended install method, and it's also the most argued-about container in r/selfhosted, where every thread about it splits into two camps within ten replies. One camp got Talk, Office and encrypted backups running in an afternoon and can't understand the complaints. The other camp watched a mastercontainer claim their Docker host and fight their reverse proxy for a whole weekend. Both camps are right. They're running different servers, and which one yours resembles is the entire decision.
My own instance is a manual install, Apache with PHP-FPM, MariaDB and Redis on a 4 GB VPS, running since around version 24. I'd still hand AIO to a friend who wants files synced and runs nothing else on the box. Holding both opinions at once takes some explaining, so here's the long version.
What Nextcloud AIO means
All-in-One is a mastercontainer. You start one Docker container, hand it the Docker socket, and it pulls and manages the rest of the stack for you: Nextcloud itself, PostgreSQL, Redis with APCu and notify_push for fast file change notifications. Then come the optional containers you toggle from its web interface, and this list is where AIO gets attractive: Talk with its own TURN server, Collabora for document editing, Borg-based backups, Imaginary for fast previews, ClamAV scanning, a whiteboard and Elasticsearch full text search. The AIO readme documents every container and flag, and it's genuinely good documentation, if long.
The mastercontainer serves its own admin interface on port 8080 (self-signed certificate) or 8443 with a valid one, the bundled Apache container takes 443 and Talk wants 3478. Read that port list again. AIO expects to be the thing answering on your server's web ports.
What AIO does well
Updates first. The AIO interface has a button that updates every container in the correct order, database included, and it works. Compare that with a manual major upgrade: release notes, a PHP version check, occ upgrade and a nervous eye on the log until it finishes.
Second, Talk. Getting Nextcloud Talk working on a manual install means running coturn yourself, opening its ports and then debugging why calls connect on office WiFi and die on mobile data. AIO ships Talk with TURN already wired. For a family that wants video calls with their files, that alone can justify the whole model.
Third, backups. Flip a switch, set a passphrase, point it at a second disk, and AIO runs BorgBackup for the entire stack: deduplicated, encrypted and restorable from the same interface. Keep that passphrase somewhere off the server, since a Borg archive without it is a paperweight.
And a smaller fourth: sane defaults everywhere. Redis caching, background jobs, preview handling and the database config all arrive already set the way the docs recommend, which quietly removes the top five mistakes I see in fresh manual installs.
Where AIO bites
Everything above assumes AIO owns the box. The moment it doesn't, friction starts, and it starts early: during setup the mastercontainer validates that your domain actually reaches it on the expected port. On a clean VPS with a public IP and correct DNS, that check passes in seconds. Behind NAT, behind a CDN proxy or on a LAN with split DNS, it fails in ways that keep the project's issue tracker busy. The escape hatch is SKIP_DOMAIN_VALIDATION=true as an environment variable on the mastercontainer, and it exists precisely because enough people needed it.
The bigger collision is an existing reverse proxy. If nginx, Caddy or Traefik already answers on 443 for your other services, AIO's Apache container can't have the port, so you start the mastercontainer with APACHE_PORT=11000 and APACHE_IP_BINDING=0.0.0.0 (or 127.0.0.1 when the proxy is local) and point your proxy at that port. This works, I've set it up for someone else's server, but the AIO reverse proxy documentation deserves a slow, complete read before you type anything. Half the broken AIO-behind-proxy setups I've seen trace back to someone skimming that page and improvising the headers.
There's also the philosophical bite. AIO manages containers through the Docker socket, decides their names and networks, and assumes its own update flow. If you're the kind of person who wants to know why a container restarted, you'll spend time learning AIO's logic on top of Docker's (I did, and it's coherent logic, but it's an extra layer of it).
What manual and compose give you instead
Control, mostly, plus the ability to share a server. With a manual install, which I've covered step by step in installing Nextcloud on Ubuntu, you know every layer because you placed it there: the Apache vhost, the PHP-FPM pool, the MariaDB database, the Redis socket. When something 500s at 2 AM there's no abstraction between you and the config file. You also get choices AIO doesn't offer. MariaDB instead of PostgreSQL is the one I care about, since it's what the docs default to and what most guides assume, though the Postgres people have a fair point about its query planner. The official source installation page is the reference for the manual path.
Compose sits in between, and for a Docker host that runs other things it's my default answer. My Nextcloud Docker Compose guide builds the stack from the official image: standard tooling, a normal docker compose pull update path and peaceful coexistence with every other container behind your existing reverse proxy. Nothing claims the Docker socket. Nothing validates your domain for you. It's boring in the way infrastructure should be boring.
Updates: the button vs apt vs an image bump
The three update models are honestly the clearest lens for this decision. AIO gives you one button (or a scheduled daily window) that updates containers in dependency order. Manual gives you apt for the OS layer plus occ upgrade for Nextcloud itself, which is more work and more visibility in equal measure. Compose gives you an image tag bump and a recreate, with the entrypoint running the upgrade routine on first start. All three work. The difference is what happens when an update goes wrong: on AIO you're reading someone else's orchestration logs, on manual you're reading your own upgrade log with full context, on compose you're somewhere in between with the option of pinning the previous image tag while you think. After losing a Sunday to a stuck upgrade at version 32, I'll take the visibility.
Backups: Borg vs your own dump and rsync
AIO's Borg integration backs up everything it manages, verified and encrypted, and for a stock deployment that's a real advantage over the nothing that most self-hosters actually run. The catch is scope. It backs up AIO's world specifically, in AIO's format, and restoring means restoring through AIO. My manual box runs maintenance mode, a MariaDB dump and restic to offsite storage, which is more moving parts to own but restores anywhere a shell exists. I've written the full routine for both directions in the Nextcloud backup and restore playbook. Pick either model, but pick one you've actually test-restored. An untested backup is a mood, and moods don't survive disk failures.
Resource use on a 2 to 4 GB VPS
With only the core containers, AIO idles at roughly the same RAM as an equivalent manual stack, somewhere around 1 to 1.5 GB, since underneath it's running the same software plus a mastercontainer that mostly sleeps. The optional containers change the math fast. ClamAV alone wants around a gigabyte for its signature database, Collabora adds hundreds of megabytes and Talk with recording pushes further. A 2 GB VPS handles core AIO or a lean manual install fine. It doesn't handle AIO with three toggles switched on, and the failure mode is an OOM killer picking the database at a bad moment. On 4 GB you can run AIO with Talk and Collabora, or a manual stack with room for previews of a large photo library. Past that, add RAM before you add features.
Which one to pick
Nextcloud owns the whole box and you want Talk or Office working this weekend: AIO, without hesitation. That's the server it was designed for and it's excellent there. The box runs other containers, or you want standard Docker tooling you already know: compose, and let your existing proxy keep its job. You want to understand every layer, need a nonstandard stack (specific PHP modules, MariaDB, an odd storage layout) or you're the one who answers when it breaks: manual. And if you're starting from zero and want to skip the assembly entirely, the one-click Nextcloud template on Ubuntu 22.04 is a fourth path, picked during ordering, that hands you a working instance in seconds.
Still torn? Run this test: list everything else that runs, or will ever run, on the server. If the list is empty, install AIO tonight. If it has one entry, it'll have four by spring, so pick compose now and thank yourself later.
