How to Build Your Own Secure Private Cloud on a VPS: A Production-Ready Guide

Every file you upload to Google Drive, Dropbox, or iCloud is stored on infrastructure operated by another organization. A self-hosted private cloud gives you greater control over your files, accounts, storage, and backup policies. With Nextcloud, you can build your own file synchronization and collaboration platform on a Virtual Private Server (VPS).

This guide walks through a complete Nextcloud deployment using Docker Compose, MariaDB, Redis, Nginx, and Let's Encrypt. It covers server preparation, SSH security, firewall configuration, container deployment, HTTPS, backups, restoration, monitoring, updates, and troubleshooting.

Estimated setup time: Allow 2–4 hours for a first deployment, including DNS, certificate issuance, verification, and backups. Estimated cost: Approximately $5–25 per month for a small VPS, excluding the domain and optional external backup storage. Actual costs depend on the provider, region, storage, and workload. Prerequisites: A domain name, a supported VPS, an SSH client, basic terminal familiarity, and access to the provider's firewall and DNS settings.

Choosing and Preparing Your VPS

Choose a VPS with reliable storage, sufficient memory, predictable bandwidth limits, provider-level firewall controls, and a documented recovery console. The provider's console is especially useful if a firewall or SSH configuration change accidentally blocks remote access.

Recommended Specifications

• CPU: 2 vCPU for a small installation; 4 or more for multiple users, preview generation, and office integrations.
• RAM: 4 GB is a practical starting point for a small deployment; 8 GB or more provides additional headroom.
• Storage: At least 50–100 GB of SSD or NVMe storage for a small installation. Add capacity based on actual user data and backup requirements.
• Bandwidth: Select a plan that accommodates file uploads, downloads, synchronization, and remote backups.
• Operating system: Ubuntu Server 24.04 LTS, using the current supported security updates.
• Network: A stable public IPv4 address is convenient. IPv6 is optional, but must be configured correctly if enabled.

Database storage, Redis, and application configuration also consume disk space, but backup requirements are usually the largest additional storage consideration. Keep backups on a separate destination whenever possible; a backup stored only on the same VPS does not protect against VPS loss.

Provider Selection

Examples of providers to compare include Hetzner, Netcup, Contabo, DigitalOcean, Akamai Connected Cloud, and Vultr. Compare current prices, disk performance, bandwidth limits, snapshot costs, backup options, support, and the jurisdiction in which your data will be stored. No provider can guarantee that your infrastructure is immune to legal requests or security incidents.

1.1 Create Your VPS and Domain

1. Create a VPS using Ubuntu Server 24.04 LTS.
2. Choose an SSH public key during provisioning if your provider supports it.
3. Record the server's public IPv4 address and, if applicable, IPv6 address.
4. Choose a domain or subdomain for Nextcloud, for example cloud.example.com. Replace this example with your actual domain throughout the guide.
5. In your DNS provider's control panel, create an A record pointing cloud.example.com to your server's public IPv4 address.
6. Create an AAAA record only if you have working IPv6 connectivity and have configured IPv6 firewall rules. An incorrect AAAA record can cause some visitors to fail to connect.
7. Allow time for DNS changes to propagate.

From your own computer, check the DNS records using:

dig +short A cloud.example.com
dig +short AAAA cloud.example.com

The A record should return your VPS IPv4 address. The AAAA query may return nothing if you have not configured IPv6. If the results are incorrect, fix DNS before requesting an HTTPS certificate.

Phase 1: Server Hardening — The Foundation

A compromised host can compromise every container running on it. Begin with operating system updates, a tested administrative account, controlled network access, and a reliable recovery path.

1.1 Connect to the VPS and Update the Operating System

From your local terminal, connect using the initial account and address provided by your VPS provider. The exact username may differ by provider.

ssh root@YOUR_SERVER_IP

Replace YOUR_SERVER_IP with the actual IP address. If your provider uses a different initial username, use that account instead.

Once connected, update the system:

apt update
apt full-upgrade -y
apt install -y sudo curl ca-certificates gnupg openssl nano dnsutils

If the upgrade installs a new kernel or reports that a reboot is required, reboot before proceeding, then reconnect and verify that the system is healthy.

1.2 Create a Non-Root Administrative User

Create a dedicated account named cloudadmin. If the account already exists, inspect it rather than creating a duplicate.

adduser cloudadmin
usermod -aG sudo cloudadmin

Follow the prompts to set a strong account password. This password is useful for local administrative authentication through sudo, even if SSH password authentication will later be disabled.

Install your SSH public key for the new account. The following commands assume that your initial root account already has the correct public key in /root/.ssh/authorized_keys.

install -d -m 700 -o cloudadmin -g cloudadmin /home/cloudadmin/.ssh
install -m 600 -o cloudadmin -g cloudadmin /root/.ssh/authorized_keys /home/cloudadmin/.ssh/authorized_keys

If the initial account does not have an authorized key file, transfer your public key from your own computer using the provider's supported key-management method. Never copy a private key onto the server.

Open a second terminal on your computer and test the new account:

ssh cloudadmin@YOUR_SERVER_IP

Confirm that login succeeds and that sudo works:

sudo whoami

The expected output is root. Keep the original session open until all later SSH and firewall changes have been tested successfully.

1.3 Harden SSH Safely

Ubuntu may use additional configuration files under /etc/ssh/sshd_config.d/. Check the effective SSH settings before editing anything:

sudo sshd -T | grep -E '^(port|permitrootlogin|passwordauthentication|pubkeyauthentication|allowusers)'

Create a dedicated configuration file for the intended SSH policy. This example retains port 22 to reduce the chance of locking yourself out. Changing the port is optional and does not replace real authentication controls.

sudo nano /etc/ssh/sshd_config.d/00-cloud-hardening.conf

Enter the following configuration:

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
PermitEmptyPasswords no
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2
AllowUsers cloudadmin

Save the file. Before reloading SSH, check the configuration and effective values:

sudo sshd -t
sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|kbdinteractiveauthentication|pubkeyauthentication)'

Only proceed if the syntax check succeeds and the effective settings match your intended policy. If the server uses a different SSH configuration layout, resolve any conflicting directives before reloading.

Reload the SSH service on Ubuntu:

sudo systemctl reload ssh

1.4 Configure the Firewall

Ubuntu's UFW firewall controls incoming traffic at the host level. The VPS provider may also supply a separate network firewall. Both must permit the traffic you need.

Install UFW if necessary, then configure the rules while logged in as cloudadmin. The following configuration assumes SSH is still using port 22.

sudo apt install -y ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp comment 'SSH'
sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'
sudo ufw status verbose

If SSH uses a different port, replace the port 22 rule with the actual configured port before enabling UFW. Then enable the firewall:

sudo ufw enable
sudo ufw status numbered

Verify that you can still connect over SSH. Do not create public firewall rules for MariaDB, Redis, or PHP-FPM. These services will communicate over private Docker networks.

1.5 Install and Configure Fail2Ban

Fail2Ban can temporarily block IP addresses that repeatedly fail authentication. It complements SSH key authentication and firewall controls; it does not replace them.

sudo apt update
sudo apt install -y fail2ban

Create a local SSH jail configuration:

sudo nano /etc/fail2ban/jail.d/sshd.local

Add the following configuration:

[sshd]
enabled = true
backend = systemd
maxretry = 5
findtime = 10m
bantime = 1h

This configuration uses the systemd journal backend, which avoids hard-coding a log file path that may not exist on every system. If you change the SSH port, ensure Fail2Ban's SSH filter and the actual SSH service configuration remain compatible.

sudo fail2ban-client -t
sudo systemctl enable --now fail2ban
sudo fail2ban-client status
sudo fail2ban-client status sshd

The configuration test should succeed and the SSH jail should appear in the status output. Do not enable Nginx-specific Fail2Ban jails until their required logs, filters, and actions are configured and tested.

1.6 Enable Automatic Security Updates

Automatic security updates help protect the host against known vulnerabilities. They do not automatically update every Docker image or perform a safe Nextcloud upgrade.

sudo apt install -y unattended-upgrades apt-listchanges
sudo dpkg-reconfigure -plow unattended-upgrades
sudo systemctl status unattended-upgrades --no-pager

Enable security updates in the interactive configuration if prompted. Review /etc/apt/apt.conf.d/50unattended-upgrades to confirm the permitted update origins. If you also enable ordinary distribution updates, understand the potential impact on the host and schedule periodic reboots when required.

1.7 Apply Conservative Kernel Hardening

Kernel network settings should be selected carefully because overly restrictive settings can interfere with routing, Docker networking, or IPv6. Start with a small set of broadly applicable protections rather than copying an untested hardening profile.

sudo nano /etc/sysctl.d/99-cloud-hardening.conf

Use the following conservative settings:

kernel.kptr_restrict = 2
kernel.dmesg_restrict = 1
fs.protected_hardlinks = 1
fs.protected_symlinks = 1

Apply and verify the settings:

sudo sysctl --system
sysctl kernel.kptr_restrict kernel.dmesg_restrict fs.protected_hardlinks fs.protected_symlinks

The displayed values should match the configuration. These settings provide limited additional protections; they do not make an unpatched or compromised server secure. Review any kernel setting against the needs of the host before enabling more restrictive network policies.

Phase 2: Install Docker Engine and Docker Compose

Docker Compose will manage Nextcloud, MariaDB, Redis, and Nginx. Install Docker Engine from the official Docker repository rather than mixing distribution packages and Docker's packages.

2.1 Add the Official Docker Repository

Run the following commands on Ubuntu 24.04 LTS. They install Docker's signing key and configure the repository for your system architecture and Ubuntu release.

sudo apt update
sudo apt 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
sudo tee /etc/apt/sources.list.d/docker.sources > /dev/null <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF
sudo apt update

2.2 Install Docker and the Compose Plugin

sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
sudo systemctl enable --now docker
sudo docker version
sudo docker compose version
sudo docker run --rm hello-world

The version commands should display installed versions, and the test container should report that Docker is working.

Phase 3: Prepare the Nextcloud Project

3.1 Create the Project Directory

Create the project directory under the administrative user's home directory. The Compose file, environment variables, and Nginx configuration will live here.

mkdir -p ~/cloud/nginx/conf.d
mkdir -p ~/cloud/certbot/www
mkdir -p ~/cloud/certbot/conf
mkdir -p ~/cloud/backups
mkdir -p ~/cloud/scripts
cd ~/cloud
chmod 700 ~/cloud

Docker-managed named volumes will hold the Nextcloud application state, database files, and Redis data. Certbot's webroot directory will be used for HTTP-01 certificate validation.

3.2 Choose the Domain and Administrator Account

Throughout the remaining examples, replace cloud.example.com with your actual hostname. Choose a unique Nextcloud administrator username rather than a predictable name if practical.

The examples below use the administrator username ncadmin. This is an application account, not the Linux administrative account.

3.3 Generate Strong Secrets

Generate unique secrets for the MariaDB root account, the Nextcloud database account, and the Nextcloud administrator account. Keep the values private and store recovery information in a secure password manager.

openssl rand -hex 32
openssl rand -hex 32
openssl rand -hex 32

Run the command three times and record each result under a different label. Use the first for MYSQL_ROOT_PASSWORD, the second for MYSQL_PASSWORD, and the third for NEXTCLOUD_ADMIN_PASSWORD. These are examples of the secrets required by this deployment, not reusable passwords.

3.4 Create the Environment File

Create the environment file using a text editor:

cd ~/cloud
nano .env

Enter the following content, replacing the example hostname and all three password placeholders with your actual values:

DOMAIN=cloud.example.com
LETSENCRYPT_EMAIL=admin@example.com
MYSQL_ROOT_PASSWORD=REPLACE_WITH_FIRST_GENERATED_SECRET
MYSQL_PASSWORD=REPLACE_WITH_SECOND_GENERATED_SECRET
NEXTCLOUD_ADMIN_USER=ncadmin
NEXTCLOUD_ADMIN_PASSWORD=REPLACE_WITH_THIRD_GENERATED_SECRET

Replace admin@example.com with an email address you control. It will be used for certificate registration and renewal notifications where applicable. Use the same domain in your DNS records and the Nginx configuration.

Save the file and exit the editor. Restrict its permissions:

chmod 600 ~/cloud/.env
ls -l ~/cloud/.env

The file should be readable and writable only by its owner. Do not publish it, upload it to a public repository, or include it in a public support request. Remember that Docker administrators can still inspect container configuration and may be able to access secrets.

Phase 4: Configure Docker Compose

The stack below uses Nginx as the public reverse proxy, Nextcloud's Apache image as the application server, MariaDB for persistent relational storage, Redis for caching and file locking, and Certbot for certificate management. This architecture intentionally uses the official Apache-based Nextcloud image instead of combining a PHP-FPM image with an incompatible web-server configuration.

4.1 Create the Docker Compose File

Create the Compose file:

cd ~/cloud
nano compose.yaml

Use the following configuration. The image tags are explicit major-version selections, not latest. Before deploying, check the current official Nextcloud, MariaDB, Redis, Nginx, and Certbot documentation and select supported compatible versions for your deployment.

name: nextcloud

services:
  db:
    image: mariadb:10.11
    restart: unless-stopped
    command: --transaction-isolation=READ-COMMITTED --binlog-format=ROW
    environment:
      MARIADB_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD:?Set MYSQL_ROOT_PASSWORD in .env}
      MARIADB_DATABASE: nextcloud
      MARIADB_USER: nextcloud
      MARIADB_PASSWORD: ${MYSQL_PASSWORD:?Set MYSQL_PASSWORD in .env}
    volumes:
      - db_data:/var/lib/mysql
    networks:
      - backend
    healthcheck:
      test: ["CMD", "healthcheck.sh", "--connect", "--innodb_initialized"]
      interval: 10s
      timeout: 5s
      retries: 10
      start_period: 30s

  redis:
    image: redis:7-alpine
    restart: unless-stopped
    command: ["redis-server", "--appendonly", "yes"]
    volumes:
      - redis_data:/data
    networks:
      - backend
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s
      timeout: 3s
      retries: 5

  app:
    image: nextcloud:apache
    restart: unless-stopped
    depends_on:
      db:
        condition: service_healthy
      redis:
        condition: service_healthy
    environment:
      MYSQL_HOST: db
      MYSQL_DATABASE: nextcloud
      MYSQL_USER: nextcloud
      MYSQL_PASSWORD: ${MYSQL_PASSWORD:?Set MYSQL_PASSWORD in .env}
      REDIS_HOST: redis
      NEXTCLOUD_ADMIN_USER: ${NEXTCLOUD_ADMIN_USER:?Set NEXTCLOUD_ADMIN_USER in .env}
      NEXTCLOUD_ADMIN_PASSWORD: ${NEXTCLOUD_ADMIN_PASSWORD:?Set NEXTCLOUD_ADMIN_PASSWORD in .env}
      NEXTCLOUD_TRUSTED_DOMAINS: ${DOMAIN:?Set DOMAIN in .env}
      APACHE_DISABLE_REWRITE_IP: "1"
      TRUSTED_PROXIES: 172.30.0.0/24
      OVERWRITEHOST: ${DOMAIN:?Set DOMAIN in .env}
      OVERWRITEPROTOCOL: https
    volumes:
      - nextcloud_html:/var/www/html
    expose:
      - "80"
    networks:
      backend:
      proxy:
        ipv4_address: 172.30.0.10

  nginx:
    image: nginx:stable
    restart: unless-stopped
    depends_on:
      - app
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx/conf.d:/etc/nginx/conf.d:ro
      - ./certbot/www:/var/www/certbot:ro
      - ./certbot/conf:/etc/letsencrypt:ro
    networks:
      - proxy

  certbot:
    image: certbot/certbot
    profiles:
      - tools
    volumes:
      - ./certbot/www:/var/www/certbot
      - ./certbot/conf:/etc/letsencrypt

volumes:
  db_data:
  redis_data:
  nextcloud_html:

networks:
  backend:
    internal: true
  proxy:
    ipam:
      config:
        - subnet: 172.30.0.0/24

Important version note: This Compose file is a configuration template that must be checked against the current image documentation before production use. Replace image tags with tested, supported versions and preferably pin production images by digest after validation. Do not run a major-version upgrade simply by changing an image tag.

The example reserves the subnet 172.30.0.0/24 for the proxy network. If that range overlaps your VPS network or another Docker network, choose a non-overlapping private range and update both the Compose file and trusted-proxy configuration.

4.2 Validate the Compose Configuration

Before starting any containers, validate the file:

cd ~/cloud
sudo docker compose --env-file .env -f compose.yaml config -q

A successful validation returns without an error. If validation fails, inspect the variable names, YAML indentation, and the environment file before continuing.

Phase 5: Configure Nginx and Bootstrap HTTPS

5.1 Create the Initial HTTP Configuration

Let's Encrypt HTTP-01 validation requires the domain to resolve to the server and inbound port 80 to be reachable. Begin with an HTTP-only Nginx configuration so the certificate can be obtained before enabling HTTPS.

cd ~/cloud
nano nginx/conf.d/nextcloud.conf

Enter the following configuration, replacing the example hostname with your actual domain:

server {
    listen 80;
    server_name cloud.example.com;

    client_max_body_size 10G;
    client_body_timeout 3600s;
    proxy_read_timeout 3600s;
    proxy_send_timeout 3600s;

    location ^~ /.well-known/acme-challenge/ {
        root /var/www/certbot;
        default_type text/plain;
        try_files $uri =404;
    }

    location / {
        proxy_pass http://app:80;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Port $server_port;
        proxy_request_buffering off;
    }
}

The 10 GB upload limit is an example for large-file workloads, not a requirement. You can lower it to suit your storage and network capacity. Nextcloud's PHP upload limits must also be configured to support the intended file sizes.

5.2 Start the Initial Services

Start the database, Redis, Nextcloud, and Nginx services without requesting a certificate yet:

cd ~/cloud
sudo docker compose --env-file .env up -d db redis app nginx
sudo docker compose --env-file .env ps

Check the logs if any service is not running:

sudo docker compose --env-file .env logs --tail=100 db redis app nginx

5.3 Request a Let's Encrypt Certificate

Confirm that the domain resolves correctly and port 80 is reachable from the internet. Then request the certificate using Certbot's webroot validation.

cd ~/cloud
sudo docker compose --env-file .env --profile tools run --rm certbot certonly --webroot -w /var/www/certbot -d cloud.example.com --email admin@example.com --agree-tos --no-eff-email

Replace cloud.example.com and admin@example.com with your actual hostname and email address. The certificate and private key should be created beneath ~/cloud/certbot/conf/live/cloud.example.com/ if issuance succeeds.

5.4 Enable HTTPS in Nginx

After successful certificate issuance, edit the Nginx configuration:

nano ~/cloud/nginx/conf.d/nextcloud.conf

Replace the HTTP-only configuration with the following complete configuration. Change the hostname to match your domain.

server {
    listen 80;
    server_name cloud.example.com;

    location ^~ /.well-known/acme-challenge/ {
        root /var/www/certbot;
        default_type text/plain;
        try_files $uri =404;
    }

    location / {
        return 301 https://$host$request_uri;
    }
}

server {
    listen 443 ssl;
    http2 on;
    server_name cloud.example.com;

    ssl_certificate /etc/letsencrypt/live/cloud.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/cloud.example.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets off;

    client_max_body_size 10G;
    client_body_timeout 3600s;
    proxy_read_timeout 3600s;
    proxy_send_timeout 3600s;

    add_header Referrer-Policy "no-referrer" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-Permitted-Cross-Domain-Policies "none" always;

    location / {
        proxy_pass http://app:80;
        proxy_http_version 1.1;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Port 443;

        proxy_request_buffering off;
        proxy_buffering off;
    }
}

The example deliberately omits HSTS until HTTPS has been verified and you have confirmed that the hostname will remain HTTPS-only. Add HSTS later if appropriate for your deployment. Review Nextcloud's official reverse-proxy recommendations and security headers before production use.

Validate and reload Nginx:

cd ~/cloud
sudo docker compose --env-file .env exec nginx nginx -t
sudo docker compose --env-file .env exec nginx nginx -s reload

The syntax check should report that the configuration is successful. If it fails, fix the reported problem before reloading.

Phase 6: Complete the Nextcloud Initial Setup

6.1 Open Nextcloud

Visit https://cloud.example.com in a browser. Replace the hostname with your actual domain. Confirm that the browser reports a valid HTTPS connection.

The container configuration supplies the initial administrator credentials and database connection settings to the official Nextcloud image. Wait for the initial installation to finish before signing in.

If the page returns an error, inspect the service logs before changing configuration:

cd ~/cloud
sudo docker compose --env-file .env ps
sudo docker compose --env-file .env logs --tail=100 app nginx db redis

6.2 Configure Redis Caching and File Locking

Redis is running on the private Docker network. Confirm that the selected Nextcloud image supports the intended Redis configuration and that the Redis PHP extension is available. Configure Nextcloud's local and distributed caching using the documented method for the installed version.

The following example shows the intended Nextcloud settings, but apply them only after confirming the appropriate configuration method for your exact image and installation:

'memcache.local' => '\\OC\\Memcache\\APCu',
'memcache.distributed' => '\\OC\\Memcache\\Redis',
'memcache.locking' => '\\OC\\Memcache\\Redis',
'redis' => [
    'host' => 'redis',
    'port' => 6379,
],

These are PHP array entries for Nextcloud's config.php, not a standalone PHP file. Do not paste them blindly into the middle of an existing configuration file or overwrite the configuration generated during installation. Use the official Nextcloud Docker documentation to determine the supported way to persist the settings.

6.3 Configure Background Jobs

Nextcloud needs background jobs for maintenance tasks, previews, notifications, and other scheduled work. For a small production deployment, system cron is generally preferable to relying on visitors to trigger jobs.

Open the Nextcloud administration settings, locate the Basic settings section, and select the recommended Cron background-job mode. Then configure a scheduler using the method documented for the chosen Docker image. Verify that jobs execute successfully and that the Nextcloud administration overview does not report a background-job warning.

6.4 Verify Uploads and Downloads

1. Sign in with the Nextcloud administrator account.
2. Upload a small test file.
3. Download the file again and compare its contents.
4. Rename and delete the test file.
5. Sign out and sign in again.
6. Check the administration overview for configuration warnings.

Do not store irreplaceable data in the new installation until you have completed a backup and tested a restoration.

Phase 7: Security Verification and Monitoring

7.1 Verify the Public Ports

On the VPS, inspect listening sockets:

sudo ss -lntup
sudo ufw status verbose

Only the intended public web ports and the configured SSH port should be allowed through your firewalls. The Compose configuration does not publish MariaDB or Redis ports to the host. Test external exposure from a separate machine if you need to confirm the provider firewall behavior.

7.2 Check HTTPS

From your own computer, inspect the HTTPS response:

curl -I https://cloud.example.com

A valid response should establish a TLS connection and return an HTTP response from the application. A redirect, authentication response, or other application response can be normal; investigate certificate errors, unexpected server errors, or a hostname mismatch.

7.3 Monitor Container Health and Disk Space

cd ~/cloud
sudo docker compose --env-file .env ps
sudo docker stats --no-stream
df -h
free -h

Check these results regularly. A full filesystem can prevent uploads, database writes, logs, and certificate renewal. Container health checks are useful but do not replace application-level checks or monitoring from outside the VPS.

Phase 8: Automated Backups

A reliable backup must include the database, Nextcloud user files, application configuration, and the secrets and deployment files needed for recovery. Keep a separate encrypted copy off the VPS.

8.1 Prepare the Backup Destination

The example below stores temporary archives under ~/cloud/backups. For production, configure a separate encrypted storage destination or remote backup service, and test that the remote copy is actually present.

mkdir -p ~/cloud/backups
chmod 700 ~/cloud/backups

8.2 Perform a Database Backup

For a database backup, use the database's supported dump utility rather than copying its live storage directory. The following command creates a logical SQL dump and prompts for the database root password without placing it directly in the command line.

cd ~/cloud
sudo docker compose --env-file .env exec -T db mariadb-dump --single-transaction --routines --triggers -u root -p nextcloud > ~/cloud/backups/nextcloud-database.sql

The command prompts for the MariaDB root password. Enter the value of MYSQL_ROOT_PASSWORD. Restrict the resulting dump file and verify that it is not empty.

chmod 600 ~/cloud/backups/nextcloud-database.sql
test -s ~/cloud/backups/nextcloud-database.sql && echo "Database dump exists and is not empty"

This command illustrates a logical database dump, but it does not by itself create a complete consistent backup of the live Nextcloud installation. Coordinate the database dump with the file and configuration backup, and use the documented maintenance procedure for your installed version.

8.3 Back Up Application Data and Configuration

The Nextcloud data volume and application configuration must be backed up using a procedure that is consistent with the database backup. Identify the actual Nextcloud data directory and configuration directory for your installed image before creating the archive.

Do not blindly archive a running application volume while users are writing files and assume that it is a complete recovery point. For a reliable backup, pause writes or use the documented Nextcloud backup procedure, capture the database and files from the same recovery point, and verify the resulting archives.

8.4 Off-Site Storage and Retention

• Encrypt backups before transferring them to remote storage.
• Store encryption keys separately from the backup archives.
• Keep more than one recovery point.
• Apply a retention policy appropriate to your storage capacity.
• Monitor the backup job's exit status and the timestamp of the latest successful copy.
• Test a restoration on a separate instance before trusting the backup procedure.

Phase 9: Restoration and Disaster Recovery

A backup is not proven until it has been restored successfully. Document the recovery process and maintain a secure copy of the deployment files, environment secrets, database dump, and application data.

9.1 Prepare a Recovery Server

1. Provision a supported operating system and secure SSH access.
2. Install compatible Docker Engine and Compose versions.
3. Restore the deployment files and securely recreate the environment file.
4. Restore the database and Nextcloud data using the documented procedure for the matching application version.
5. Verify ownership, permissions, configuration, trusted domains, and reverse-proxy settings.
6. Start the services and inspect their logs.
7. Test login, file access, uploads, downloads, and background jobs.

Do not restore over your only surviving copy of the data. Perform a trial restoration on a separate environment and confirm that the restored files are readable before declaring the disaster-recovery process complete.

Phase 10: Updates and Monthly Maintenance

A production Nextcloud installation requires regular maintenance. Automatic operating system security updates are useful, but container updates and Nextcloud upgrades must be managed separately.

10.1 Review Available Updates

sudo apt update
sudo apt list --upgradable
cd ~/cloud
sudo docker compose --env-file .env ps

Read the release notes for Docker, Nextcloud, MariaDB, Redis, and Nginx before updating. Back up the installation first, verify version compatibility, and avoid changing several major versions at once.

10.2 Update Container Images Carefully

For a tested compatible image update, pull the selected images and recreate the affected services using the Compose configuration. Never treat a blind image update as a complete maintenance strategy.

cd ~/cloud
sudo docker compose --env-file .env config -q
sudo docker compose --env-file .env pull
sudo docker compose --env-file .env up -d
sudo docker compose --env-file .env ps

Run this sequence only after reviewing the image tags and release notes, taking a suitable backup, and confirming that the proposed update is compatible. Pin tested versions rather than relying on a moving latest tag. For Nextcloud major-version upgrades, follow the official upgrade instructions and supported upgrade path.

10.3 Monthly Maintenance Checklist

• Check operating system and container security updates.
• Verify HTTPS and certificate renewal status.
• Review Nextcloud administration warnings.
• Check container health, application logs, and disk space.
• Confirm that recent database and file backups exist.
• Verify that an off-site copy has completed successfully.
• Review authentication failures and firewall status.
• Perform periodic restoration tests.
• Review user accounts, application access, and storage usage.

Phase 11: Troubleshooting Common Problems

11.1 Nextcloud Is Unavailable

Check service status and recent logs:

cd ~/cloud
sudo docker compose --env-file .env ps
sudo docker compose --env-file .env logs --tail=100 app nginx

Look for startup failures, connection errors, invalid configuration, and permission problems. Correct the reported cause before restarting services repeatedly.

11.2 Nginx Returns a 502 Bad Gateway

A 502 response commonly means that Nginx cannot reach the Nextcloud application container. Confirm that both services are running and attached to the same proxy network.

cd ~/cloud
sudo docker compose --env-file .env ps
sudo docker compose --env-file .env logs --tail=100 nginx app

11.3 Let's Encrypt Cannot Issue a Certificate

Check the domain's A and AAAA records, ensure that port 80 is accessible from the internet, and confirm that the ACME challenge path is being served from the expected webroot. If IPv6 is configured in DNS but not working on the server, correct the IPv6 configuration or remove the invalid AAAA record.

11.4 Uploads Fail

Large uploads can fail because of Nginx's request-size limit, PHP upload limits, execution timeouts, available disk space, or client connectivity. Check each layer and set compatible limits. A large Nginx upload limit alone does not guarantee that PHP or Nextcloud can accept files of that size.

11.5 The Server Runs Out of Storage

df -h
sudo docker system df

Identify which filesystem is full before deleting anything. Do not remove Docker volumes or database directories to free space unless you have verified their contents and have a tested backup.

Final Verification Checklist

Before considering the installation ready for regular use, verify every item below:

• SSH key authentication works and root SSH login is disabled as intended.
• The host firewall and provider firewall permit only the required public ports.
• Docker and Docker Compose are installed and functioning.
• Nextcloud, MariaDB, Redis, and Nginx start successfully.
• The domain resolves to the correct server address.
• HTTPS is valid and certificate renewal is configured and tested.
• Nextcloud trusted domains and proxy settings are correct.
• Test files can be uploaded, downloaded, renamed, and deleted.
• Database and application data backups are created and stored off-site.
• A restoration has been tested on a separate environment.
• Monitoring, disk-space checks, and maintenance procedures are documented.
• The administrator knows how to update the deployment and recover from a failure.

Conclusion: Operate Your Private Cloud Responsibly

A private Nextcloud deployment gives you greater control over your files and collaboration tools, but that control comes with responsibility. Maintain the host, keep applications updated, monitor storage, protect credentials, maintain independent backups, and periodically test your recovery process.

The most important production principle is simple: a working installation is only the beginning. A secure and dependable private cloud is one that you can monitor, maintain, and restore when something goes wrong.