Install Nextcloud on a VPS With Docker and OnlyOffice

Google Drive is easy—until you need firm control over where data lives, how long you retain it, and who can access what. Nextcloud gives you the familiar “files + sharing + sync” experience. OnlyOffice adds in-browser editing for DOCX/XLSX/PPTX.

This guide shows you how to install Nextcloud on a VPS with a setup you can actually operate. You’ll get predictable storage, clean HTTPS, backups you can restore, and upgrades that don’t turn into a fire drill.

Nextcloud is open source (AGPLv3). OnlyOffice Document Server is source-available (AGPLv3 for the Community Edition), with enterprise features under commercial terms.

For many small teams, Nextcloud + OnlyOffice Community Edition hits the sweet spot. You get collaborative editing, solid sharing controls, and no per-user SaaS bill creeping up every month.

Why Nextcloud + OnlyOffice fits small teams running real infrastructure

Nextcloud works well if you already run websites, apps, or internal services. It gives you file sync on your own infrastructure.

You get WebDAV, desktop/mobile clients, granular link sharing, and an app ecosystem that stays useful.

OnlyOffice covers the gap users notice right away. It edits Office formats in the browser without downloads or messy conversion artifacts.

The integration is mature. The workflow also feels familiar if you’re coming from Google Workspace or Microsoft 365.

Best for: agencies, small product teams, consultancies, and internal IT groups.
Not ideal for: teams that need deep DLP, eDiscovery, and compliance tooling on day one. You can get there, but it’s more work.

If you want this to run without constant babysitting, start on a VPS with enough RAM and fast disk. Shared hosting often falls apart once you add document editing and background jobs.

For predictable performance, a HostMyCode VPS gives you dedicated resources. It also helps you size storage correctly from day one.

Nextcloud vs Google Drive (and other hosted options) in plain terms

Self-hosting isn’t automatically “better.” It’s a trade. You gain control, and you take on operations.

Here’s what tends to matter in practice.

Data control: Nextcloud keeps files and logs on your server. Hosted drives can limit where data resides and how long logs stick around.
Identity and access: Nextcloud supports SSO via SAML/OIDC (often via apps) and can integrate with LDAP/AD. Hosted services offer similar features, but you don’t control server-side policy and logging details.
Cost model: Nextcloud shifts cost to infrastructure + your time. Hosted suites charge per user, per month, indefinitely.
Performance tuning: On a VPS you can add Redis, tune PHP-FPM, and scale storage. Hosted platforms hide the knobs—and often the limits.

A practical bonus: you can treat Nextcloud like any other internal service. Put it behind a VPN, IP allowlists, or an SSO gateway.

That’s awkward (or impossible) with many consumer-grade drive products.

What you need before you install Nextcloud on a VPS

Before you touch Docker Compose, decide where your data will live and how you’ll recover it. Nextcloud can run on modest CPU.

Storage design and backups are where deployments usually fail.

Resource requirements that match real usage

Small team (5–20 users): 2 vCPU, 4–8 GB RAM, NVMe disk. OnlyOffice likes RAM; 8 GB feels noticeably better than 4 GB once multiple people edit at the same time.
Medium team (20–80 users): 4 vCPU, 8–16 GB RAM, NVMe disk, and consider separating database if load increases.
Storage: size for data + versions + trash + database + backups. If users expect “drive” behavior, plan 2–3× the raw file total for safety.

If you want fewer operational chores (OS patching, monitoring, migration help), managed VPS hosting can make the difference.

It can help you keep the service running for years, instead of abandoning it after the first incident.

Storage planning: avoid the expensive rework

Most Nextcloud headaches start with disk and IOPS. These rules tend to hold up over time:

Use fast local disk (NVMe) for the database and Nextcloud app volume.
Keep user files on a dedicated mount (example: /mnt/nextcloud-data) so you can expand or move it later.
If you plan to scale storage, choose a filesystem you know how to grow safely (ext4, xfs). Document the procedure.

DNS and TLS baseline

Use a dedicated hostname such as cloud.example.com. Point an A/AAAA record to your server IP.

Plan for Let’s Encrypt validation.

If you prefer to keep DNS and infrastructure under one roof, HostMyCode domains covers domain registration and DNS management.

For a deeper TLS runbook (renewal failures, mixed-content cleanup, common pitfalls), keep this nearby: HTTPS with Let’s Encrypt on a VPS.

Compose architecture: keep it boring, keep it maintainable

A sensible Compose layout makes backups and updates routine. The design below stays “boring” on purpose:

PostgreSQL for the database (reliable, fast, easy to back up).
Redis for file locking (prevents sync conflicts under load).
Nextcloud (app + cron) as separate containers.
OnlyOffice Document Server behind the same reverse proxy.

Use Docker volumes for the database and config. Keep user data on a host bind mount on a dedicated disk.

It’s your largest dataset, so make it obvious and portable.

Example directory layout

/opt/nextcloud/compose.yml
/opt/nextcloud/.env
/opt/nextcloud/volumes/ (optional if you prefer named volumes)
/mnt/nextcloud-data/ (user files on a separate mount)

Deploy Nextcloud + OnlyOffice with Docker Compose

This is a reference design, not a one-click lab. Adjust hostnames, passwords, and paths to match your environment.

1) Install Docker and Compose plugin

On Ubuntu or Debian, Docker’s official packages are usually the least surprising option. Confirm the install:

docker --version
docker compose version

If this server will run other apps too, plan a shared reverse-proxy network. Keep each project’s services separated.

2) Create a Compose file

This Compose setup is a solid production baseline. It assumes Nginx runs on the host as your reverse proxy.

(Caddy or Traefik works too.)

services:
  db:
    image: postgres:16
    container_name: nextcloud-db
    environment:
      POSTGRES_DB: nextcloud
      POSTGRES_USER: nextcloud
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - db_data:/var/lib/postgresql/data
    restart: unless-stopped

  redis:
    image: redis:7-alpine
    container_name: nextcloud-redis
    command: ["redis-server", "--save", "", "--appendonly", "no"]
    restart: unless-stopped

  nextcloud:
    image: nextcloud:apache
    container_name: nextcloud-app
    depends_on:
      - db
      - redis
    environment:
      POSTGRES_HOST: db
      POSTGRES_DB: nextcloud
      POSTGRES_USER: nextcloud
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      REDIS_HOST: redis
      NEXTCLOUD_TRUSTED_DOMAINS: ${NEXTCLOUD_HOSTNAME}
      OVERWRITEPROTOCOL: https
      PHP_MEMORY_LIMIT: 1024M
      UPLOAD_MAX_SIZE: 10G
    volumes:
      - nextcloud_html:/var/www/html
      - /mnt/nextcloud-data:/var/www/html/data
    restart: unless-stopped

  cron:
    image: nextcloud:apache
    container_name: nextcloud-cron
    depends_on:
      - nextcloud
    entrypoint: /cron.sh
    volumes:
      - nextcloud_html:/var/www/html
      - /mnt/nextcloud-data:/var/www/html/data
    restart: unless-stopped

  onlyoffice:
    image: onlyoffice/documentserver
    container_name: onlyoffice-ds
    environment:
      JWT_ENABLED: "true"
      JWT_SECRET: ${ONLYOFFICE_JWT_SECRET}
    restart: unless-stopped

volumes:
  db_data:
  nextcloud_html:

Notes you’ll be glad you read:

Nextcloud image choice: nextcloud:apache is fine behind a reverse proxy and simpler than wiring your own PHP-FPM + Nginx container stack. If you already standardize on Nginx+PHP-FPM, you can switch later.
Redis config: disabling persistence is common here; Redis is used for locking/cache. Don’t treat it as a datastore.
Uploads: large uploads require matching limits in PHP, reverse proxy, and client timeouts.

3) Add an environment file

POSTGRES_PASSWORD=use-a-long-random-secret
ONLYOFFICE_JWT_SECRET=use-a-different-long-random-secret
NEXTCLOUD_HOSTNAME=cloud.example.com

4) Bring it up

cd /opt/nextcloud
docker compose up -d
docker compose ps

The containers should now be running. Don’t expose them directly.

Put a reverse proxy in front, terminate TLS, and forward traffic to the Nextcloud and OnlyOffice containers by port.

Reverse proxy with HTTPS (Nginx) and sane defaults

Terminating TLS on the host with Nginx + Certbot keeps certificates and renewal logs stable. It also keeps working even as containers come and go.

If you’d rather use Caddy for automatic HTTPS, the same idea applies. This HostMyCode guide pairs well with a Docker setup: Set up Caddy reverse proxy for Docker.

Nginx server blocks (two hostnames is simplest)

OnlyOffice is happiest on its own hostname, such as office.example.com. This avoids messy path routing and CSP trouble later.

cloud.example.com → Nextcloud
office.example.com → OnlyOffice Document Server

Example Nginx config (paths as used on Ubuntu/Debian):

/etc/nginx/sites-available/nextcloud.conf
/etc/nginx/sites-available/onlyoffice.conf

Nextcloud vhost (proxying to the container’s exposed port; you can use docker inspect or publish a port explicitly):

server {
  server_name cloud.example.com;

  client_max_body_size 10G;

  location / {
    proxy_pass http://127.0.0.1:8080;
    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_read_timeout 3600;
    proxy_send_timeout 3600;
  }
}

OnlyOffice vhost:

server {
  server_name office.example.com;

  client_max_body_size 1G;

  location / {
    proxy_pass http://127.0.0.1:8081;
    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_read_timeout 3600;
  }
}

You’ll need to publish ports from the containers to the host (or run Nginx in Docker on a shared network). The simplest approach is to add:

    ports:
      - "127.0.0.1:8080:80"

to the Nextcloud service, and:

    ports:
      - "127.0.0.1:8081:80"

to the OnlyOffice service. Then run docker compose up -d again.

Once plain HTTP works, request certificates with Certbot. Then switch the vhosts to HTTPS.

If you want a step-by-step checklist, use the HostMyCode TLS guide linked earlier. Apply it to both hostnames.

Connect OnlyOffice to Nextcloud (and avoid the common security mistake)

After Nextcloud is running, install the “OnlyOffice” integration app from Nextcloud Apps.

Then open the OnlyOffice settings in the admin panel and set:

Document Editing Service address: https://office.example.com/
JWT secret: must match ONLYOFFICE_JWT_SECRET in your Compose file

Don’t leave JWT off. Without JWT, anything that can reach your OnlyOffice service can try to use it.

JWT keeps it an integrated editor, not a public document renderer.

Backups that you can restore: what to save and how often

A usable Nextcloud backup is not “one folder.” You need three pieces.

Take them in a consistent window:

Database (PostgreSQL dump)
Nextcloud app volume (config, apps, themes)
Data directory (user files) — usually the largest part

Database backup (PostgreSQL)

Run pg_dump inside the container. This avoids version mismatch surprises:

docker exec -t nextcloud-db pg_dump -U nextcloud nextcloud | gzip > /backup/nextcloud-db.sql.gz

Keep at least one copy off the server. If the VPS disk fails, “local-only backups” fail with it.

Even a basic offsite copy to another VPS or storage box improves recovery options.

File + config backup

For the Nextcloud app volume and data directory, filesystem snapshots are ideal if your storage supports them. Otherwise, use rsync or an archive.

The key is to reduce churn while you copy:

Put Nextcloud into maintenance mode
Take backups
Exit maintenance mode

# maintenance mode on
docker exec -u www-data nextcloud-app php occ maintenance:mode --on

# backup app volume (example uses docker volume mountpoint inspection)
docker run --rm -v nextcloud_nextcloud_html:/src -v /backup:/dst alpine \
  sh -c "cd /src && tar -czf /dst/nextcloud-html.tgz ."

# backup data directory
tar -czf /backup/nextcloud-data.tgz -C /mnt/nextcloud-data .

# maintenance mode off
docker exec -u www-data nextcloud-app php occ maintenance:mode --off

If you want a more structured approach (retention, encryption, restore testing), adapt this runbook: Disaster recovery tutorial (2026).

Quick restore test (the part most people skip)

A backup plan only counts if you’ve restored it. At least quarterly, spin up a small VPS.

Restore the three components, then verify you can log in and open a document.

If the service is business-critical, do it monthly.

Updates and upgrades: keep maintenance predictable

Nextcloud upgrades stay boring if you follow two habits. Don’t jump multiple major versions in one go.

Take a fresh backup before you change anything.

Update workflow for Docker-based installs

Read the Nextcloud release notes for breaking changes (especially PHP requirements).
Backup database + volumes.
Pull new images.
Recreate containers.
Run Nextcloud’s upgrade routine if needed and check logs.

cd /opt/nextcloud
docker compose pull
docker compose up -d

# run database migrations / upgrade steps if prompted
docker exec -u www-data nextcloud-app php occ upgrade

OnlyOffice updates work the same way. Pull the image and restart.

After updating, watch RAM usage for a day or two. Editor releases sometimes change memory behavior.

Patch the VPS too (not just containers)

Container images don’t replace OS security updates. On Ubuntu, enable unattended upgrades or stick to scheduled patch windows.

This guide walks through a safe baseline: Set up automated security updates on Ubuntu VPS.

Operational checks that prevent slowdowns and sync issues

Nextcloud will warn you about problems, but only if you look.

These checks catch most “why is it slow?” complaints early.

Background jobs: confirm cron is running. Nextcloud performs poorly on “AJAX” background jobs.
File locking: Redis should be enabled and reachable. Without it, users will hit random conflicts.
Large uploads: match client_max_body_size (Nginx) with Nextcloud’s PHP upload limits.
Database health: check disk space and autovacuum activity. A full disk can ruin your day fast.

Monitoring helps you spot disk growth and memory pressure before users do. For a lightweight setup, pair system monitoring with uptime checks: Server monitoring setup guide (2026).

(Even if you don’t use Netdata, the alerting checklist is useful.)

Security baseline: the minimum that’s actually worth doing

Nextcloud is a high-value target because it tends to store everything. You don’t need exotic security tools.

You do need consistent basics.

Lock SSH down: key-based auth, no password login, no root login.
Firewall: only expose 80/443 (and SSH from your admin IP if possible). A simple UFW policy is enough for most deployments.
Fail2Ban or rate limiting: protect login endpoints and admin panels.
2FA: enforce it for admins at minimum.
Separate hostnames: keep OnlyOffice on its own hostname and require JWT.

If you want a practical UFW baseline on Ubuntu, this guide maps well to a Nextcloud VPS: Set up UFW firewall on Ubuntu for a web server.

If you’re rolling Nextcloud out to a team, start with infrastructure that won’t choke on disk I/O, RAM, or flaky networking. A HostMyCode VPS gives you consistent resources for sync and document editing, and managed VPS hosting makes sense if you want help keeping the OS patched and the service steady.

FAQ

Do I need OnlyOffice, or is Nextcloud’s built-in editor enough?

For basic text and light collaboration, Nextcloud’s editing options can be enough. If your users expect high-fidelity DOCX/XLSX/PPTX editing in the browser, OnlyOffice is usually the smoother experience.

Can I run Nextcloud on shared hosting?

Small installs can work, but document editing and background processing quickly run into shared limits (CPU time, memory, long-running requests). For teams, a VPS is the practical starting point.

What’s the most common cause of “random” sync conflicts?

Missing or misconfigured file locking (Redis) is a frequent culprit. The other common issue is overloaded storage that can’t keep up with concurrent uploads.

How do I back up Nextcloud correctly?

Back up the database, the Nextcloud app/config volume, and the data directory. Take them consistently (maintenance mode helps), and keep at least one copy offsite.

How often should I update?

For most teams, monthly maintenance windows work well: OS security updates, container image refresh, and Nextcloud minor updates. Apply urgent security fixes sooner.

Summary: a clean self-hosted “Drive” stack that you control

Nextcloud plus OnlyOffice is a practical replacement for hosted drive suites if you want control over data, identity, and retention.

Smooth deployments come from operational discipline. Focus on storage planning, HTTPS that renews cleanly, backups you can restore, and a repeatable update process.

If you’re deploying for a real team, size the VPS for sync and editing. Keep it patched and monitored.

Start with a HostMyCode VPS, or choose managed VPS hosting if you want platform maintenance handled alongside your app stack.