How to Self-Host Nextcloud and Access It from Anywhere

Understand the architecture before installing

Nextcloud is an open-source server application for storing, synchronizing, and sharing files. It can also support calendars, contacts, collaborative applications, and other functions through its app ecosystem. Self-hosting gives you control over the server, accounts, storage, updates, and backup policy, but it does not automatically guarantee privacy, regulatory compliance, availability, or security. Those outcomes depend on how you operate the complete system.

The worked deployment in this guide separates the application into four local components. Nextcloud serves the web interface, MariaDB stores application records, Redis supports caching and file locking, and a cron container runs scheduled Nextcloud background jobs. User files and application state are stored in Docker volumes unless you deliberately configure an external disk.

For remote access, the Localtonet client runs on the host that can reach Nextcloud. It establishes an outbound connection to a Localtonet relay. A remote browser connects to the assigned public HTTPS hostname, the relay forwards the request through that outbound tunnel, and the client sends it to the configured local target.

Choose a supported deployment path and verify prerequisites

This article provides a complete worked example for Docker Compose on an Ubuntu host supported by Docker Engine. Debian users can use Docker's corresponding Debian repository instructions, but should not mix Ubuntu and Debian repository definitions. Other Linux distributions require their own Docker-supported installation path.

Nextcloud's requirements vary by release and by the applications you enable. Docker Engine requirements vary by host distribution and architecture. MariaDB and Redis have their own supported platforms and resource needs. For that reason, there is no universal two-core, 2 GB, or 64-bit minimum that is authoritative for every Nextcloud installation.

Before continuing, prepare a maintained Linux host, an administrator account with sudo, sufficient persistent storage, and a separate backup destination. You also need a Localtonet account and a supported Localtonet client for the host. The Localtonet device token is device-specific and must be treated as a secret.

Install Nextcloud with Docker Compose

Install Docker from its supported repository

Docker's convenience script is intended to simplify some installations, but it is not the best default for a maintained production-like server because it reduces visibility into repository and package setup. For Ubuntu, use Docker's official apt repository. The following sequence installs the repository key, adds the repository for the current Ubuntu codename, and installs Docker Engine with the Compose plugin.

sudo apt-get update
sudo apt-get install -y ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings

sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg \
  -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" \
  | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt-get update
sudo apt-get install -y docker-ce docker-ce-cli containerd.io \
  docker-buildx-plugin docker-compose-plugin

sudo docker run --rm hello-world
sudo docker compose version

If the host is Debian, follow the same repository-based model using Docker's Debian repository and key rather than substituting Ubuntu packages. Docker documents both paths in its Docker Engine installation documentation.

Create the project and secret environment file

The example pins Nextcloud to major release 33 rather than using a floating stable tag. This prevents an ordinary image pull from silently crossing into a later Nextcloud major release. MariaDB and Redis are also assigned explicit release lines. Before deploying, confirm that the selected tags remain available and supported for your host architecture.

sudo install -d -m 0750 -o "$USER" -g "$USER" /opt/nextcloud
cd /opt/nextcloud

openssl rand -base64 36
openssl rand -base64 36
openssl rand -base64 36

Run the random-generation command separately for the database root password, Nextcloud database password, and initial administrator password. Create .env, substitute the generated values, and restrict access to the file:

cat > .env <<'EOF'
MYSQL_ROOT_PASSWORD=replace_with_unique_random_root_password
MYSQL_DATABASE=nextcloud
MYSQL_USER=nextcloud
MYSQL_PASSWORD=replace_with_unique_random_database_password
NEXTCLOUD_ADMIN_USER=ncadmin
NEXTCLOUD_ADMIN_PASSWORD=replace_with_unique_random_admin_password
NEXTCLOUD_TRUSTED_DOMAINS=localhost 127.0.0.1
EOF

chmod 600 .env

Do not commit this file to source control or include it in an unencrypted backup. After installation, create a separate non-administrator account for daily use rather than using the bootstrap administrator account for file synchronization.

Create the Compose configuration

services:
  db:
    image: mariadb:11.4
    restart: unless-stopped
    command:
      - --transaction-isolation=READ-COMMITTED
      - --binlog-format=ROW
    env_file:
      - .env
    volumes:
      - db_data:/var/lib/mysql
    healthcheck:
      test: ["CMD-SHELL", "healthcheck.sh --connect --innodb_initialized"]
      interval: 10s
      timeout: 5s
      retries: 12
      start_period: 30s

  redis:
    image: redis:7.4-alpine
    restart: unless-stopped
    command: redis-server --save 60 1 --loglevel warning
    volumes:
      - redis_data:/data

  app:
    image: nextcloud:33-apache
    restart: unless-stopped
    ports:
      - "127.0.0.1:8080:80"
    env_file:
      - .env
    environment:
      MYSQL_HOST: db
      REDIS_HOST: redis
    depends_on:
      db:
        condition: service_healthy
      redis:
        condition: service_started
    volumes:
      - nextcloud_html:/var/www/html
      - nextcloud_data:/var/www/html/data

  cron:
    image: nextcloud:33-apache
    restart: unless-stopped
    entrypoint: /cron.sh
    env_file:
      - .env
    depends_on:
      app:
        condition: service_started
    volumes:
      - nextcloud_html:/var/www/html
      - nextcloud_data:/var/www/html/data

volumes:
  db_data:
  redis_data:
  nextcloud_html:
  nextcloud_data:

The MariaDB health check verifies database initialization before Compose starts the application container. This is materially different from the short depends_on form, which controls startup order but does not by itself prove that MariaDB is ready to accept application traffic.

The web port is published as 127.0.0.1:8080:80. That means only processes on this host can connect through the published port. This is appropriate when the Localtonet client runs on the same machine. If the client runs on another LAN device, loopback will not be reachable. In that topology, bind deliberately to a suitable LAN interface and protect it with host firewall rules rather than automatically exposing it on every interface.

Start and verify the local installation

cd /opt/nextcloud
sudo docker compose config

sudo docker compose pull

sudo docker compose up -d

sudo docker compose ps
sudo docker compose logs --tail=100 db app

curl -I http://127.0.0.1:8080
sudo docker compose exec --user www-data app php occ status

sudo docker compose exec --user www-data app php occ background:cron
sudo docker compose ps cron

Use a Raspberry Pi deployment path that matches a real release asset

A Raspberry Pi can host Nextcloud when its architecture, storage, cooling, power supply, operating system, and expected workload are suitable. Avoid universal claims that a particular Pi model is always fast enough or always unusable. Photo indexing, preview generation, office integration, full-text search, and multiple simultaneous users can change resource demands substantially.

There are two distinct approaches: run the same Docker Compose architecture on a Docker-supported Raspberry Pi operating system, or use a downloadable NextcloudPi image that explicitly supports your board. Do not combine instructions from those paths unless the selected project documentation calls for it.

Current NextcloudPi release asset limitation

The earlier v1.57.1 release publishes a ZIP asset specifically labeled NextcloudPi_RaspberryPi 4+_v1.57.1.zip. That label supports Raspberry Pi 4 and later models covered by the project's notation. It must not be presented as a generic image for every Raspberry Pi model. The release also publishes a checksum for the asset.

This article does not reproduce an installation script for placing NextcloudPi over an arbitrary existing Raspberry Pi OS installation because the supplied current release evidence does not confirm that path, its supported operating-system matrix, or a current installer URL. Avoid piping an unverified branch script directly into a privileged shell.

Docker Compose on Raspberry Pi

The Docker path can be used only when Docker Engine supports the installed Raspberry Pi operating system and each image tag supports its architecture. Check the image manifests for Nextcloud, MariaDB, and Redis before deployment. Follow Docker's repository instructions for the exact Raspberry Pi operating system rather than assuming the Ubuntu repository commands apply unchanged.

Once those requirements are confirmed, the Compose structure remains the same: database health checking, explicit image release lines, named volumes, a cron worker, and a loopback-bound web port when Localtonet runs on the same Pi. Monitor memory pressure, storage latency, temperature, and available disk space under the actual workload.

Prepare external storage without risking the data directory

Adding a disk and moving an existing Nextcloud data directory are separate operations. A new installation can start with an empty, correctly mounted directory. An existing installation requires maintenance mode, a consistent copy, ownership preservation, a configuration change, verification, and a rollback plan.

Detect and validate the filesystem

lsblk -o NAME,SIZE,FSTYPE,LABEL,UUID,MOUNTPOINTS
sudo blkid
findmnt --verify

If the intended partition has no filesystem, stop and create one only after confirming that the device can be erased. Filesystem selection, encryption, RAID, and recovery design are administrative decisions beyond the tunnel setup. The examples below assume an existing Linux-compatible filesystem whose UUID has already been verified.

sudo install -d -m 0750 /mnt/nextcloud-data
sudoedit /etc/fstab

Add one reviewed entry using the real UUID and filesystem type reported by lsblk. Do not copy this placeholder literally:

UUID=verified-filesystem-uuid /mnt/nextcloud-data ext4 defaults,nofail 0 2

Then test the entry before rebooting:

sudo mount -a
findmnt /mnt/nextcloud-data
df -h /mnt/nextcloud-data
sudo touch /mnt/nextcloud-data/.write-test
sudo rm /mnt/nextcloud-data/.write-test

Use the disk for a new installation

Before the first application start, create an empty directory for the bind mount. Determine the numeric identity used by www-data in the selected Nextcloud image rather than assuming it:

cd /opt/nextcloud
sudo mkdir -p /mnt/nextcloud-data/data
sudo docker compose run --rm --no-deps app id www-data

Apply the reported numeric user and group to the new directory, then replace the application's data volume mapping with the verified host path:

volumes:
  - nextcloud_html:/var/www/html
  - /mnt/nextcloud-data/data:/var/www/html/data

The path must be mounted before Nextcloud starts. A missing disk combined with an ordinary local directory at the same mount point can cause the application to write data onto the root filesystem instead.

Migrate an existing Docker data volume

Create and test a full backup first. Then perform a controlled migration during a maintenance window:

cd /opt/nextcloud

sudo docker compose exec --user www-data app \
  php occ maintenance:mode --on

sudo docker compose stop cron app

container_id="$(sudo docker compose ps -aq app)"
sudo mkdir -p /mnt/nextcloud-data/data
sudo docker cp "${container_id}:/var/www/html/data/." \
  /mnt/nextcloud-data/data/

sudo rsync -aHAX --numeric-ids --delete \
  /mnt/nextcloud-data/data/ \
  /mnt/nextcloud-data/data.verify/

The second copy above is an optional verification target, not a replacement for an off-host backup. Compare file counts, sizes, and representative checksums. Apply ownership using the numeric www-data identity reported by the selected image. Change the Compose mapping only after the copy is complete, then start the application and inspect it before removing the original named volume.

sudo docker compose up -d app cron
sudo docker compose exec --user www-data app php occ status
sudo docker compose exec --user www-data app \
  php occ maintenance:mode --off

sudo docker compose logs --tail=100 app

Test uploads, downloads, previews, and an existing user's files. Keep the original volume until the new storage has passed verification and a fresh backup has completed.

Configure hostnames, proxies, and generated URLs correctly

A Localtonet HTTP tunnel does not automatically mean that every private network must be listed in Nextcloud's trusted_proxies. The correct configuration depends on the request path observed by Nextcloud, whether forwarding headers are present, and which address actually supplies them.

Add the assigned public hostname to trusted domains

After Localtonet assigns the real public hostname, add only the hostname, without https:// or a path. First list the current indexed values so you do not overwrite an existing entry:

cd /opt/nextcloud

sudo docker compose exec --user www-data app \
  php occ config:system:get trusted_domains

Choose the next unused numeric index and replace the example with the exact hostname shown by your tunnel:

sudo docker compose exec --user www-data app \
  php occ config:system:set trusted_domains 2 \
  --value="assigned-public-hostname.example"

Keep localhost, 127.0.0.1, or a deliberately configured LAN hostname if you need those access paths. Removing local entries can make local diagnostics unnecessarily difficult.

Trust a proxy only when the observed topology requires it

Inspect the Nextcloud logs and request behavior before setting trusted_proxies. If a proxy supplies forwarding headers that Nextcloud must honor, trust only that proxy's verified address or the narrowest necessary CIDR. Do not trust all of 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 as a convenience. That authorizes many unrelated private addresses to provide headers that affect client-address and URL interpretation.

Use overwrite parameters only to correct demonstrated URL problems

Nextcloud can sometimes see the local HTTP side of a tunnel even though the browser used public HTTPS. If generated links, WebDAV endpoints, redirects, or callback URLs incorrectly use HTTP, an overwrite protocol may be required. A global overwritehost can force every generated URL to the public hostname and may disrupt local access.

Test first. If overwrite settings are necessary, preserve local access by applying the narrowest configuration supported by the actual source-address topology. Nextcloud supports conditional overwrite behavior through an address condition. The exact address or expression must come from observed requests, not from a copied private-network range. Record the old configuration before changing it:

sudo docker compose exec --user www-data app \
  php occ config:list system

After any routing change, test the local URL and public URL separately. Confirm that browser redirects, generated share links, WebDAV endpoints, and mobile-client login all use the expected hostname and protocol.

Expose Nextcloud with a Localtonet HTTP tunnel

With Localtonet, the client on your device establishes an outbound connection to one of our relay servers. The resulting HTTP tunnel provides a public HTTPS address that forwards to the local Nextcloud service. This avoids inbound router port forwarding, firewall changes, VPN setup, and the need for a public IP address.

Creating a tunnel is not the same as running it. The selected Localtonet client must be connected, and the tunnel must be started. If the client exits, the host loses internet connectivity, or the tunnel is stopped, the public endpoint cannot reach Nextcloud.

You can access the authenticated Localtonet HTTP tunnel page to configure the tunnel. Availability of custom or reserved hostnames, custom domains, continuous operation, timeout behavior, access controls, and other options can vary by plan and current product configuration. Confirm those details in the dashboard rather than assuming that every endpoint is permanently reserved.

Verify local service, public access, and reboot behavior

Verification should prove more than the appearance of the login page. Test the local application first, then the tunnel, then Nextcloud's generated URLs and user workflows.

cd /opt/nextcloud
sudo docker compose ps
sudo docker compose exec --user www-data app php occ status

curl -I http://127.0.0.1:8080
sudo ss -lntp | grep 8080

sudo docker compose logs --tail=200 app db redis cron
sudo docker compose exec --user www-data app \
  php occ log:watch

Harden a publicly reachable Nextcloud deployment

A public HTTPS endpoint protects the public transport path, but it does not make weak accounts, outdated applications, excessive permissions, or missing backups safe. Treat Nextcloud as an internet-facing application even though the origin is reached through an outbound tunnel.

Self-hosting can improve control over where data is stored, but compliance depends on governance, access policy, auditability, retention, encryption choices, contracts, incident response, and applicable law. Running Nextcloud on your own hardware does not by itself establish GDPR, HIPAA, or other compliance.

Back up and update Nextcloud safely

Back up all required state

A useful backup set includes the database, Nextcloud configuration, user data, custom applications, themes or other customizations, the Compose file, and a protected copy of the secrets needed for restoration. Store the resulting backup separately from the Nextcloud host. A second directory on the same physical disk is not sufficient protection against disk failure, theft, or host compromise.

The following example uses maintenance mode and an exit trap so an interrupted backup attempts to return Nextcloud to service. It creates a temporary MariaDB option file inside the database container, avoiding a database password in the host command line.

#!/usr/bin/env bash
set -Eeuo pipefail

project="/opt/nextcloud"
destination="/mnt/offhost-backups/nextcloud/$(date -u +%Y%m%dT%H%M%SZ)"
maintenance_enabled=0

cleanup() {
  if [ "$maintenance_enabled" -eq 1 ]; then
    sudo docker compose -f "$project/compose.yaml" \
      --env-file "$project/.env" \
      exec -T --user www-data app \
      php occ maintenance:mode --off || true
  fi
}
trap cleanup EXIT INT TERM

mkdir -p "$destination"
cd "$project"

sudo docker compose exec -T --user www-data app \
  php occ maintenance:mode --on
maintenance_enabled=1

sudo docker compose exec -T db sh -eu -c '
  umask 077
  option_file="$(mktemp)"
  trap "rm -f \"$option_file\"" EXIT
  printf "[client]\nuser=%s\npassword=%s\n" \
    "$MYSQL_USER" "$MYSQL_PASSWORD" > "$option_file"
  mariadb-dump \
    --defaults-extra-file="$option_file" \
    --single-transaction \
    --routines \
    --triggers \
    "$MYSQL_DATABASE"
' > "$destination/nextcloud-database.sql"

sudo docker compose cp app:/var/www/html/config \
  "$destination/config"
sudo docker compose cp app:/var/www/html/data \
  "$destination/data"
sudo docker compose cp app:/var/www/html/custom_apps \
  "$destination/custom_apps"
sudo docker compose cp app:/var/www/html/themes \
  "$destination/themes"

sudo cp compose.yaml "$destination/compose.yaml"
sudo docker compose exec -T --user www-data app \
  php occ status > "$destination/nextcloud-status.txt"

sudo docker compose exec -T --user www-data app \
  php occ maintenance:mode --off
maintenance_enabled=0

printf 'Backup completed: %s\n' "$destination"

If your Compose file is named docker-compose.yml instead of compose.yaml, adjust the script consistently. Protect the backup because Nextcloud configuration and data can contain sensitive information. Back up .env separately using encryption and access controls rather than copying it into an ordinary unencrypted directory.

Perform an explicit restore test

A backup is not proven until it has been restored. Use an isolated host or isolated project name, prevent it from sending notifications to real users, and install the same Nextcloud major release used by the backup.

1. Create empty database, HTML, and data volumes using the recorded Compose configuration.
2. Restore configuration, custom applications, themes, and data with their original ownership and permissions.
3. Import the SQL dump into an empty database using a temporary protected option file.
4. Start MariaDB and Redis first, wait for database health, then start Nextcloud.
5. Run occ status, inspect logs, and keep maintenance mode enabled while validating the restored version.
6. Test representative users, file downloads, shares, previews, installed apps, and background jobs.
7. Record the restore duration, missing steps, and recovery point. Correct the backup process before relying on it.

Update one Nextcloud major release at a time

Do not replace nextcloud:33-apache with a floating stable tag. Before an update, confirm the supported upgrade path, application compatibility, database compatibility, available disk space, and current backup status. Prepare rollback by retaining the previous image reference and a restore-tested pre-update backup.

cd /opt/nextcloud

sudo docker compose exec --user www-data app php occ status
sudo docker compose exec --user www-data app php occ app:list
sudo docker compose pull
sudo docker compose up -d
sudo docker compose exec --user www-data app php occ status
sudo docker compose logs --tail=200 app db cron

For a major upgrade, edit both the app and cron image tags to the next supported Nextcloud major only. Do not skip a major release. Follow the version-specific Nextcloud upgrade procedure, confirm that required migrations finish, and test before advancing again.

occ maintenance:repair runs repair steps registered by Nextcloud and installed applications. It should not be described as a generic cache-clearing command. Similarly, occ db:add-missing-indices addresses reported missing database indices and should be used when Nextcloud's administration checks or documented upgrade process calls for it.

Troubleshoot the deployment layer by layer

Frequently asked questions