August 24, 2026

Nextcloud and Keeping Data Off Third-Party Services

Notes on running Nextcloud to keep personal files off commercial cloud services: app and database architecture, Docker Compose deployment, backup practice, and the limitations of a single-machine homeserver.

Commercial cloud storage is convenient, but the trade-off rarely gets discussed: personal files live on infrastructure owned by a third party, subject to terms of service and policies you cannot control. Nextcloud is a common answer for cutting that dependency—a file storage, synchronization, and collaboration hub that runs on your own server.

Why Keep Data Off Third-Party Services

In a self-hosted ecosystem, Nextcloud offers a private alternative to commercial cloud services. Files stay entirely on your own server without sacrificing mobile accessibility or a web UI, and vendors’ incentives to analyze or sell data stop being relevant.

Nextcloud covers two core needs:

  • File Synchronization: Automatically syncs documents, photos, and data across laptops, phones, and the server.
  • Secure Sharing: Provides public links or internal folder sharing with fine-grained access control.

Architecture: App, Database, and WebDAV

Nextcloud runs as a two-tier stack:

  1. Nextcloud Application (PHP/Apache): Handles the web UI, application logic, and the synchronization protocol.
  2. Database (MariaDB/PostgreSQL): Stores file metadata, user accounts, permissions, and activity logs.

Physical files live in the data directory inside the installation, not in the database. The database only records metadata linking accounts, folders, and files. Because of this separation, a backup that copies only one half will not restore correctly.

Desktop and mobile clients sync over WebDAV at https://example.com/nextcloud/remote.php/dav/files/USERNAME/. The protocol also lets you mount the folder from a file manager, so access is not limited to official apps.

Deployment with Docker Compose

A minimal setup is two containers—application and database:

services:
  db:
    image: mariadb:11.4
    container_name: nextcloud_db
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: change_root_password
      MYSQL_DATABASE: nextcloud
      MYSQL_USER: nc_user
      MYSQL_PASSWORD: change_user_password
    volumes:
      - ./db_data:/var/lib/mysql

  app:
    image: nextcloud
    container_name: nextcloud_app
    restart: always
    ports:
      - "8080:80"
    environment:
      MYSQL_HOST: db
      MYSQL_DATABASE: nextcloud
      MYSQL_USER: nc_user
      MYSQL_PASSWORD: change_user_password
    volumes:
      - ./nextcloud_data:/var/www/html
    depends_on:
      - db

The volume ./nextcloud_data:/var/www/html holds both the application code and the data directory, so they are backed up together. The database port is not published to the host; db is only reachable from the internal Docker network.

Security & Operations

  • HTTPS is mandatory: Put Nextcloud behind a reverse proxy (e.g., Cloudflare Tunnel or Nginx Proxy Manager) with TLS enabled. Without TLS, credentials and files in transit can be read.
  • Never expose the database: Keep MariaDB traffic on the internal Docker bridge network; do not publish its port publicly.
  • Server-side encryption (optional): At-rest encryption can be enabled from the admin page. Losing the encryption keys makes data undecryptable, and files grow by roughly 1%; enable it only after understanding that risk.
  • occ CLI: Maintenance commands run as the HTTP user, for example sudo -E -u www-data php occ maintenance:mode --on.

Backup & Recovery

Keeping physical files and the database consistent is the key to recovery. Copying file data without a database dump—or vice versa—yields metadata that does not match the stored files.

The official documentation recommends this order:

  1. Enable maintenance mode (occ maintenance:mode --on) to lock user sessions and prevent changes during the process.
  2. Copy the installation directory including the data directory, e.g. with rsync, to a location outside the Nextcloud environment.
  3. Dump the database, mysqldump --single-transaction for MySQL/MariaDB.
  4. Disable maintenance mode (occ maintenance:mode --off) when done.

Note that a backup on the same machine is still a single failure domain. It protects against configuration mistakes, but not against losing the whole host.

Drawbacks and Limitations

Separating from third parties is not free:

  • Operational responsibility moves to you. Upgrades, disk capacity monitoring, and database maintenance become routine work that the cloud provider used to handle.
  • Backups are not automatic. Keeping files and database consistent requires manual discipline, unlike commercial cloud where the vendor manages backups.
  • At-rest encryption is not the default, and it adds key-loss risk; for most cases HTTPS plus control over the server covers the basic requirements.
  • Real-time document collaboration (editing together in the browser) needs a separate document server such as Collabora Online or OnlyOffice, adding resource footprint.
  • One machine, one failure domain. Hardware failure means losing everything unless an off-site copy exists.
  • Limited scale. Default configuration is fine for personal use or small groups; many concurrent users need extra tuning.

Conclusion

Nextcloud does keep data off third-party services: files, metadata, and access control live on your own server, with synchronization and sharing on par with commercial cloud. The trade-off is that availability and backup duties move to the server owner as well. With limited storage on one machine, backup discipline and capacity planning matter more than features—Nextcloud is not a substitute for good backup habits, just the right place to hold data you should control.

References

Back to all posts