Nextcloud AIO Self-Hosted Installation: My Production Setup

I have been running Nextcloud AIO as the self-hosted file and collaboration layer for a couple of small teams for about 18 months, and the deployment has settled into a pattern I am willing to recommend in writing. This Nextcloud AIO self-hosted installation guide is the actual stack I ship: the AIO master container, Nginx Proxy Manager in front for TLS, and the storage and backup layout I would set up for a paying client.

If you have run vanilla Nextcloud and bounced off it, AIO is worth a second look. The master container manages the database, Redis, the cron worker, Collabora Office, Talk, and the backup container as children. You stop hand-rolling six pieces and start clicking checkboxes. The trade-off is that AIO assumes it owns the Docker socket and its own database, so it is not a fit for every environment, but for a fresh VPS it is what I default to now.

Roughly 30 to 60 minutes from a hardened server to a working Nextcloud with TLS, accounts, and the desktop sync client connected. The slow part is not the install, it is deciding whether you should be self-hosting this at all.

Why self-host Nextcloud instead of paying for Workspace

The honest answer is that most five-person teams should not. Google Workspace at 6€ per user per month, Dropbox Business at 12€ per user per month, or Microsoft 365 Business Basic at 5€ per user per month each give you a battle-tested file layer and someone else’s pager rotation. If your only requirement is “a shared drive that works”, pay the bill and move on.

Self-hosting Nextcloud earns its keep when one of these is true:

1. Compliance or data sovereignty. GDPR-sensitive client data, healthcare records, legal hold material, or anything where “the data lives on a server I control in this jurisdiction” is a hard requirement.
2. Per-seat economics break. A 25-person agency at 12€ per seat is 3,600€ per year for Dropbox Business. A Hetzner CX32 with a 1TB volume runs around 240€ per year. The math starts working somewhere between 10 and 15 active users.
3. Integration with the rest of a self-hosted stack. If you already run Mailcow for email, Authentik for SSO, and Vikunja for tasks, Nextcloud slots in as the file and calendar layer with shared identity.
4. You actually want the file collaboration. Collabora Office in the browser, end-to-end encrypted Talk video calls, and CardDAV/CalDAV calendar/contacts sync are genuinely good, not just acceptable.

If none of those four apply, pay for Workspace. I am not the only self-hosting advocate who will tell you this; I am just willing to put it in writing.

Prerequisites for the Nextcloud AIO self-hosted installation

A few non-negotiables before any of this lands on a server:

• A hardened Linux host. SSH keys only, no root login, UFW with deny-by-default. My Linux server security fundamentals post is the baseline I run on every fresh box.
• A reverse proxy stack. Nextcloud AIO expects to live behind a real reverse proxy with valid TLS. I use Nginx Proxy Manager from my Portainer + NPM + Vaultwarden stack. Caddy or Traefik work too; my notes assume NPM.
• A real domain name with DNS access. Nextcloud AIO refuses to set up without a public-DNS-resolved hostname, and Let’s Encrypt needs DNS-01 or HTTP-01 to work. Cloudflare DNS is the pragmatic default.
• Server sizing. 4GB RAM is the floor. 8GB is what I recommend if you enable Talk and Collabora for more than five concurrent users. CPU is rarely the bottleneck; RAM and disk IO are.
• Storage. Nextcloud is a file server. Plan storage at 5–10x the per-user working set, separate the data volume from the OS disk where possible, and snapshot it daily.

I run production AIO instances on Hetzner CX32 (4 vCPU, 8GB RAM) with a 500GB attached volume mounted into the Nextcloud data directory. That sizing handles roughly 8 active users with calendar, contacts, file sync, and occasional Collabora editing without breathing hard.

The Nextcloud AIO Docker Compose file

Here is the actual Compose file I deploy. The upstream AIO repository keeps the canonical version current; the snippet below is what I check into config management for new deployments.

version: "3.8"

volumes:
  nextcloud_aio_mastercontainer:
    name: nextcloud_aio_mastercontainer

services:
  nextcloud:
    image: nextcloud/all-in-one:latest
    restart: unless-stopped
    container_name: nextcloud-aio-mastercontainer
    volumes:
      - nextcloud_aio_mastercontainer:/mnt/docker-aio-config
      - /var/run/docker.sock:/var/run/docker.sock:ro
    ports:
      - 8083:8080
    environment:
      - APACHE_PORT=11000
      - SKIP_DOMAIN_VALIDATION=false
      - APACHE_DISABLE_REWRITE_IP=1
      - NEXTCLOUD_TRUSTED_DOMAINS=cloud.yourdomain.com
      - TRUSTED_PROXIES=10.0.0.0/8,172.16.0.0/12,192.168.0.0/16

The values that need to change before you bring this up:

• NEXTCLOUD_TRUSTED_DOMAINS is the public hostname users will type into the browser. Match this to the domain you point at the proxy.
• TRUSTED_PROXIES is the CIDR range of your reverse proxy. The example above covers all RFC1918 ranges so the same Compose works in most Docker bridge networks; tighten it if you know the exact bridge subnet.
• APACHE_PORT=11000 is the port the Nextcloud child container will listen on for proxied HTTPS traffic. NPM points at this port.

Bring it up:

docker compose -f /srv/docker/nextcloud-aio/docker-compose.yml up -d

Then open https://server-ip:8083 in a browser. The AIO interface generates an initial admin password, and from that screen you click through domain validation, then the master container pulls and orchestrates the child containers (database, Redis, the Nextcloud server itself, the backup container, and optionally Talk, Collabora, and ClamAV).

Warning: Port 8083 is the AIO admin page. Do not leave it open to the public internet. Restrict it at the firewall to your office IP, or only enable it temporarily for setup and updates. The admin page issues commands to your Nextcloud stack as root inside the master container; treat it like an SSH port.

Firewall ports

Open these on the server’s firewall:

• 3478/tcp and 3478/udp to any IPv4 for Nextcloud Talk STUN/TURN traffic. Without this, Talk video calls fall back to TURN-relay-only and may fail behind strict NATs.
• 8083/tcp to your dedicated admin IP only. This is the AIO admin page. Never open it to 0.0.0.0/0.
• 80/tcp and 443/tcp to any IPv4, handled by Nginx Proxy Manager, which Nextcloud AIO sits behind.

If you change the 8083 port in the Compose file, update the firewall rule to match.

Reverse proxy and TLS through Nginx Proxy Manager

In the NPM admin UI:

1. Add a new Proxy Host. Domain: cloud.yourdomain.com. Forward hostname/IP: the host running the AIO master container (or the container name if NPM is on the same Docker network). Forward port: 11000.
2. Tick “Block Common Exploits” and “Websockets Support”. Websockets is required for Talk and live notifications.
3. SSL tab: request a Let’s Encrypt cert, force SSL, enable HTTP/2, enable HSTS.
4. Advanced tab: paste the Nextcloud-recommended security headers. The exact set I use is in my Nginx security hardening post. Content-Security-Policy needs frame-ancestors set to your domain only, X-Frame-Options DENY, X-Content-Type-Options nosniff, and Referrer-Policy strict-origin-when-cross-origin.

After saving the proxy host, return to https://server-ip:8083, fill in the domain, and let AIO run its domain validation. If Let’s Encrypt and the proxy host are wired correctly, validation passes within a minute and AIO begins the rest of the setup.

Backups, the part the install guide skims over

AIO ships its own backup container that handles encrypted, deduplicated backups using BorgBackup under the hood. Configure it from the AIO admin page once initial setup is complete:

• Backup target. A separate mounted volume, a remote server over SSH, or both. A backup that lives on the same physical disk as the original is a copy, not a backup.
• Daily schedule. Pick an off-hours window.
• Retention. Borg’s default retention is sane. I keep 7 daily, 4 weekly, and 6 monthly snapshots for production.
• Encryption passphrase. Stored off the server, ideally in a separate password manager. Lose this and the encrypted backup is unrecoverable.

The non-negotiable: rehearse the restore. Spin up a second VPS, install AIO, point the backup container at the off-site repository, run a restore, and verify users can log in. Do this once before you onboard a single non-technical user.

Sizing reality and the threat model

A few numbers from the production instances I run, so you can calibrate:

• 8 active users, calendar + contacts + file sync, no Talk: roughly 1.2GB RAM steady, occasional spikes to 2GB during the daily backup window.
• 8 active users with Collabora enabled, two concurrent editors: RAM jumps to 3–4GB during edits. The Collabora child container is the heaviest single piece in the stack.
• Storage growth: about 200GB of working files generated 380GB total after 14 months once version history and trash bin retention were factored in. Your mileage varies by team behaviour, but plan high.

The threat model worth thinking about for a self-hosted Nextcloud is not the Nextcloud code itself. The codebase is mature, the security team is responsive, and CVEs ship inside reasonable windows. The realistic risks are:

1. Public exposure of the AIO admin page. Covered above. Lock 8083 to a specific IP, full stop.
2. Weak admin password and no 2FA. Nextcloud supports TOTP, WebAuthn, and SSO via OIDC. Enable WebAuthn for the admin account on day one. If you are running Authentik, wire Nextcloud to it via OIDC and let Authentik enforce hardware-key login.
3. Unmonitored failed logins. Configure the brute-force protection app (it ships enabled by default) and add Nextcloud’s logs to your Uptime Kuma or central log pipeline.
4. Backup gaps. Covered above. Off-site, encrypted, restore-rehearsed.

For team-scale deployments I also enforce Talk’s end-to-end encryption flag, and I disable the public file-sharing feature unless explicitly needed. Public links are a common source of accidental data exposure.

Verifying the deployment before you trust it

A short checklist before you onboard real users:

1. Create one test user. Upload a 1GB file from the desktop client. Verify it lands and is downloadable from a different device.
2. Edit a document in Collabora from two browsers simultaneously. Verify the live cursor and presence indicators work.
3. Make a Talk call to yourself from a second device. Verify audio and video both flow without TURN-only fallback (check the Talk admin panel for the connection state).
4. Trigger a manual backup from the AIO admin. Verify the backup completes and the size is what you expect.
5. From a second VPS, restore that backup into a fresh AIO instance. Log in as the test user. Verify files match.

Step 5 is the one most people skip. Do it once with one test user before you have eight team members and 400GB of working data on the line.

When to walk away

If after reading this you are not sure self-hosting Nextcloud is right for your team, you probably already have your answer. Workspace is fine. Dropbox is fine. The teams that get value out of self-hosted Nextcloud are the ones with a specific compliance, sovereignty, or integration reason, plus someone willing to own the operational burden when the desktop client misbehaves on a Friday afternoon.

For everyone else who decided the trade is worth it, the stack above is the boring, working version. Pair it with Authentik for SSO, Mailcow for email, and Uptime Kuma watching the proxy and you have the spine of a small self-hosted office that holds up under day-to-day use.

Recurring cost on my production setup is roughly 25€ per month for the VPS, the volume, and the backup target. The monthly operational burden is checking the backup log on the first Monday of the month and applying the AIO update when the admin page flags one. That is the deal: a few clicks a month, in exchange for owning the data layer end to end.