# Nextcloud All-in-One: the official Docker deployment, and what it decides for you

> Nextcloud AIO bundles Nextcloud, PostgreSQL, Redis, a backup system and optional services behind a single master container. It is aimed at self-hosters who want the official stack without assembling it, and it asks for the Docker socket in return.

**nextcloud/all-in-one** — 📦 The official Nextcloud installation method. Provides easy deployment and maintenance with most features included in this one Nextcloud instance.

- Repository: https://github.com/nextcloud/all-in-one
- Website: https://nextcloud.com/blog/nextcloud-all-in-one-introduces-automatic-domain-acquisition-dns-setup/
- Stars: 10,515 · Forks: 1,112
- Language: PHP
- License: AGPL-3.0
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/nextcloud-all-in-one

## What Nextcloud All-in-One is for, and who it is not for

Nextcloud AIO is the official installation method for Nextcloud, and the README lists what a single instance includes: Nextcloud itself, Redis and APCu for caching, PostgreSQL as the database, and a high performance backend for Nextcloud Files that handles client push. Optional pieces are switched on later: Nextcloud Office, EuroOffice, the Talk high performance backend and TURN server, the Talk recording server, Imaginary for previews of heic, heif, illustrator, pdf, svg, tiff and webp, ClamAV, full text search, Whiteboard, and a Docker Socket Proxy for the Nextcloud App API.

The audience is the self-hoster who wants the official stack rather than a personal assembly of images. The README states that only one domain is required for everything to work, that automatic TLS is included through Let's Encrypt, and that a free deSEC domain under *.dedyn.io can be registered directly from the AIO interface if you have no domain of your own. Those three points remove the usual first-day obstacles.

The wrong audience is equally clear. Anyone who wants to pick their own web server, database version or reverse proxy configuration will find themselves fighting the design rather than using it. The README does say AIO is ready to sit behind an existing reverse proxy and can run behind a Cloudflare Tunnel or via Tailscale, but the internal topology is not yours to rearrange.

## The mastercontainer and the Docker socket it needs

AIO is not a single container running Nextcloud. It is a mastercontainer that starts and supervises sibling containers. The repository's compose.yaml names that service nextcloud-aio-mastercontainer and pulls ghcr.io/nextcloud-releases/all-in-one:latest, with the comment that you can switch to the :beta tag to help test new releases.

The compose file is explicit about what may not be changed. The container_name is nextcloud-aio-mastercontainer and the volume nextcloud_aio_mastercontainer:/mnt/docker-aio-config, both marked as not allowed to be changed, the second because the built-in backup solution depends on that path. The Docker socket is mounted read-only at /var/run/docker.sock, with a note that this may be changed on macOS, Windows or Docker rootless, and that adjusting it means also setting WATCHTOWER_DOCKER_SOCKET_PATH.

That socket mount is the architectural centre of the project and the main thing to weigh. A container that can talk to the Docker daemon can create and destroy other containers, which is exactly how AIO performs updates and how it brings optional services up and down. The README offers an escape hatch: installation without a container having access to the Docker socket, documented under manual-install. There is also a docker-rootless.md document for running under rootless Docker.

## Installing Nextcloud AIO with Docker Compose

The repository ships compose.yaml at the top level, so the shortest path is to fetch that file and bring it up. The service name, image and volume path below are copied from that file; do not rename the container or the config volume.

```bash
docker compose up -d
```

After that, the mastercontainer is running and the AIO web interface is reachable on port 8080 of the host, where you set the domain and start the instance. The README describes the interface as the place for installation and maintenance, so the first real use is opening it, entering the domain you want Nextcloud served on, and letting it obtain the certificate.

The compose file also shows the hardware acceleration device commented out. If the host has /dev/dri and you want transcoding, uncomment it, but the warning in the file is worth repeating: if that device does not exist on the host, the mastercontainer will fail to start.

```yaml
services:
  nextcloud-aio-mastercontainer:
    image: ghcr.io/nextcloud-releases/all-in-one:latest
    container_name: nextcloud-aio-mastercontainer
    volumes:
      - nextcloud_aio_mastercontainer:/mnt/docker-aio-config
      - /var/run/docker.sock:/var/run/docker.sock:ro
```

If you would rather not expose the socket, the manual-install directory in the repository documents the alternative, and the README notes that AIO can also be installed with Docker Swarm and that a Helm chart lives in nextcloud-aio-helm-chart.

## Backups, restore and the upgrade path

The backup solution is optional and based on BorgBackup. The README states that daily backups can be enabled from the AIO interface, and that the same interface can then update all containers, Nextcloud and its apps automatically afterwards. Restore is described as needing only the archive and the password to bring the whole instance back on a new AIO instance.

That is a stronger claim than most self-hosted setups can make, and it is the feature that justifies the fixed config volume path in compose.yaml. It is also the place where the documentation is thinnest. The README does not describe what happens to a backup schedule when the mastercontainer is stopped for a long period, and manual-upgrade.md exists in the repository, which suggests there are upgrade situations the interface does not cover on its own.

Upgrade cost is otherwise low by design. Because the mastercontainer manages the sibling containers, updates are triggered from the interface rather than by editing image tags. The trade-off is that you are accepting the project's release cadence: the recent releases listed for the repository include v14.2.0 marked as a beta, v14.1.1 as a stable release, and a separate helm-chart-14.1.1 tag. If you switch the image tag to :beta as the compose comment permits, you are opting into that beta line deliberately.

## Where AIO stops being the right tool

The clearest limitation is the one already visible in compose.yaml: the design assumes the mastercontainer can reach the Docker daemon. Read-only access reduces what a compromised container could do, but the capability is still there, and the project's own answer to that concern is a separate manual installation path rather than a configuration flag.

The second limitation is domain dependency. Automatic TLS through Let's Encrypt and the one-domain model mean the instance is built around being reachable at a public hostname. The README does cover a local instance for people who cannot make it publicly reachable, and access to Nextcloud locally via the domain, but the default path assumes a domain resolves to the host. If you are running on a network where inbound 80 and 443 are blocked and you have no tunnel, the standard flow does not apply.

The third is that the stack is opinionated about scale. AIO targets one Nextcloud instance with most features included. The repository has a multiple-instances.md document, but the README's framing is a single instance, and anyone planning per-tenant isolation or a horizontally scaled deployment should read that document before assuming the model fits.

## How it differs from a hand-built Nextcloud deployment

The obvious alternative is assembling the same components yourself: an Apache or nginx container, a PostgreSQL container, Redis, a cron container, and a certificate tool such as Caddy or certbot in front. That approach gives you control over every version and every configuration file. It also gives you the update procedure, the database migration, the certificate renewal and the backup script.

AIO's difference is not that it uses different software. It uses PostgreSQL, Redis, APCu and PHP-FPM, and the README notes PHP-FPM runs with a performance-optimized config with Opcache enabled by default. The difference is that a mastercontainer owns the lifecycle of those services. Updates, optional service toggles and restores are actions in a web interface rather than commands you run.

There is a middle path inside the project itself. The README states that installation is not read only, so you can apply patches without waiting for a release, and that additional OS packages and PHP extensions can be added permanently to the Nextcloud container without building your own image. That narrows the gap with a hand-built deployment for people who need one or two extra packages but do not want to maintain the whole stack.

## Licence and what it means for a deployment

The repository is licensed AGPL-3.0. For a self-hosted instance that you run for yourself or your organisation, the licence is not something you need to act on. The obligation becomes relevant if you modify the software and make it available to users over a network, which is the scenario the AGPL addresses.

The containers AIO deploys are separate pieces of software with their own licences, and the README does not enumerate them. If you plan to redistribute an image or offer the instance as a service to third parties, check the licence of each component rather than assuming the repository's AGPL-3.0 covers the whole running system. This is a description of what the licence file says, not legal advice.

## Conclusion

Adopt Nextcloud All-in-One if you want the official Nextcloud stack, automatic TLS and a restore path you can exercise from a browser, and you are comfortable giving a container read access to the Docker socket. Do not adopt it if you need a minimal, hand-tuned deployment, cannot expose a domain, or want to control every service version yourself. Before committing, verify that /var/run/docker.sock can be mounted read-only and that the mastercontainer starts, then register the free deSEC domain from the AIO interface and confirm the instance comes up with a valid certificate.

## FAQ

### What is Nextcloud All-in-One used for?

It is the official Nextcloud installation method. The README describes it as providing easy deployment and maintenance with most features included in one Nextcloud instance, covering Nextcloud, Redis and APCu caching, PostgreSQL, and optional services such as Nextcloud Office, Talk backends, ClamAV and a BorgBackup-based backup solution.

### Does Nextcloud All-in-One need access to the Docker socket?

The shipped compose.yaml mounts /var/run/docker.sock read-only into the mastercontainer, with a note that this may be changed on macOS, Windows or Docker rootless. The README also states it can be installed without a container having access to the Docker socket, documented in the manual-install directory.

### How do I install Nextcloud All-in-One?

The repository includes a compose.yaml at the top level, so the documented path is to bring that file up with Docker Compose and then use the AIO web interface to set the domain and start the instance. The compose file fixes the container name and the /mnt/docker-aio-config volume because the built-in backup solution depends on them.

## Sources

- [License: AGPL-3.0](https://github.com/nextcloud/all-in-one/blob/main/LICENSE)
- [nextcloud/all-in-one on GitHub](https://github.com/nextcloud/all-in-one)
- [Project website](https://nextcloud.com/blog/nextcloud-all-in-one-introduces-automatic-domain-acquisition-dns-setup/)
- [README](https://github.com/nextcloud/all-in-one/blob/main/README.md)
- [Releases](https://github.com/nextcloud/all-in-one/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/nextcloud-all-in-one