SSD Nodes Learn
Mga Gabay Matt ConnorNi Matt Connor · Na-update 2026-07-24

Paano mag-setup ng Nextcloud sa VPS

Matutong mag-install ng Nextcloud gamit ang Docker Compose, Postgres, at Redis. Alamin ang tamang backup strategy para sa iyong data sa Ubuntu o Debian.

Ang aktwal na iyong bubuuin

Ang guide na ito ay nagpapatakbo ng Nextcloud sa isang VPS gamit ang Docker Compose. Maglalagay tayo ng Let's Encrypt TLS sa harap nito, at magtatayo ng backup na gumagana ang restoration. Mayroong apat na container at isang proxy: ang official nextcloud image na nakikinig sa loopback, Postgres para sa lahat ng file metadata, Redis para sa file locks, pangalawang kopya ng Nextcloud image na para lamang sa cron loop, at nginx sa host para sa TLS termination. Ang installation ay tatagal ng dalawampung minuto, ngunit hindi ito ang pinakamahalaga. Dalawang desisyon sa unang oras ang magtatakda kung may files ka pa pagkalipas ng isang taon: ang paggamit ng totoong database sa halip na SQLite, at ang backup na kumukuha sa data directory, database, at config.php bilang isang consistent na set.

Ipinapalagay nito na gumagamit ka ng Ubuntu 24.04 LTS o Debian 13, Docker Engine na may installed na Compose v2 plugin mula sa repository ng Docker, at isang DNS A record (pati na rin AAAA kung may IPv6) na nakaturo na sa cloud.example.com ng VPS. Kailangan nito ng server na kontrolado mo — hindi maaaring gawin ang TLS termination at database dump sa isang third-party SaaS.

Sizing: ano ang tunay na kumakain ng memory

Ang paggamit ng memory ng Nextcloud ay pinapataas ng tatlong bagay, at wala sa mga ito ang mismong "Nextcloud".

PHP workers. Ang -apache image ay nagsisilbi sa bawat concurrent request gamit ang isang worker process na may PHP interpreter. Ang bawat worker ay maaaring lumaki hanggang PHP_MEMORY_LIMIT bago i-terminate ng PHP ang request. Ang worst-case resident memory ay humigit-kumulang concurrent requests × memory limit, at ang desktop sync client ay nagbubukas ng ilang parallel connections bawat user. Ang concurrency, hindi ang bilang ng user, ang nagtatakda ng ceiling.

Ang database. Nagfo-fork ang Postgres ng backend bawat connection at pinapanatili ang shared buffers sa memory. Ang working set nito ay umaasa sa bilang ng files, hindi sa bilang ng bytes: ang oc_filecache ay may isang row bawat file bawat user. Ang isang daang libong maliliit na file ay mas mabigat sa database kaysa sa isang daang malalaking file.

Preview generation. Ang pag-generate ng thumbnail ay nagde-decode ng source image sa memory sa full resolution nito. Ang video previews ay gumagamit ng ffmpeg. Ang pagtakbo ng occ preview:generate-all ay paulit-ulit na gumagawa ng spike na ito, at ito ang pinakakaraniwang dahilan kung bakit nagkakaroon ng OOM killer ang isang maliit na VPS.

Ang Redis ay mura lang kumpara sa iba. Anumang idagdag mo sa huli — Collabora, full-text search, antivirus scanner — ay mga hiwalay na resident service na may sariling footprint, at dapat na kasama sa iyong sizing plan bago mo ito i-enable.

Ang mga lever, kung kulang ang RAM: babaan ang PHP_MEMORY_LIMIT, limitahan ang preview_max_x / preview_max_y / preview_max_filesize_image, bawasan ang enabledPreviewProviders sa mga format na aktwal mong tinitingnan, at i-set ang trashbin_retention_obligation at versions_retention_obligation para hindi palihim na lumaki ang data directory nang higit sa laki ng iyong mga file. Magdagdag ng swap file. Mabagal ang swap, at mas malala ang OOM kill habang nag-u-upgrade.

Bakit nasisira ang SQLite

May kasamang SQLite support ang Nextcloud at gagamitin ito ng official image. Huwag itong gawin. Nagsasagawa ang SQLite ng serialization sa mga writes gamit ang database-wide lock: isang writer lang bawat pagkakataon para sa buong file. Ang Nextcloud ay patuloy na nagsasagawa ng writes — file locks, activity rows, cache entries, job state — at ang isang desktop client na nag-i-sync ng directory tree ay nagpapadala ng maraming parallel requests. Dahil sa pattern na ito, makakakuha ka ng SQLSTATE[HY000]: General error: 5 database is locked at HTTP 500s, at ang failure ay nangyayari mismo kapag nagsisimula nang maging useful ang instance.

Posibleng mag-convert mamaya gamit ang occ db:convert-type, pero isa itong mahaba at all-or-nothing na migration sa isang live dataset. Simulan ito gamit ang Postgres o MariaDB.

Ang Compose file

Ilagay ito sa /srv/nextcloud/compose.yaml, kasama ang mga secret sa isang katabing .env file sa mode na 600.

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

  redis:
    image: redis:7-alpine
    restart: unless-stopped
    command: redis-server --requirepass ${REDIS_PASSWORD}

  app:
    image: nextcloud:31-apache
    restart: unless-stopped
    depends_on: [db, redis]
    ports:
      - "127.0.0.1:8080:80"
    volumes:
      - html:/var/www/html
      - /srv/nextcloud/data:/var/www/html/data
    environment:
      POSTGRES_HOST: db
      POSTGRES_DB: nextcloud
      POSTGRES_USER: nextcloud
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      REDIS_HOST: redis
      REDIS_HOST_PASSWORD: ${REDIS_PASSWORD}
      NEXTCLOUD_ADMIN_USER: admin
      NEXTCLOUD_ADMIN_PASSWORD: ${ADMIN_PASSWORD}
      NEXTCLOUD_TRUSTED_DOMAINS: cloud.example.com
      TRUSTED_PROXIES: 172.16.0.0/12
      OVERWRITEPROTOCOL: https
      OVERWRITECLIURL: https://cloud.example.com
      APACHE_DISABLE_REWRITE_IP: "1"
      PHP_MEMORY_LIMIT: 512M
      PHP_UPLOAD_LIMIT: 10G

  cron:
    image: nextcloud:31-apache
    restart: unless-stopped
    entrypoint: /cron.sh
    depends_on: [db, redis]
    volumes:
      - html:/var/www/html
      - /srv/nextcloud/data:/var/www/html/data

volumes:
  db:
  html:

I-pin ang major tag at i-check ang kasalukuyang tag sa Docker Hub bago i-copy nang verbatim ang 31. Maaaring magkaroon ng major version jump ang latest sa susunod na docker compose pull, at hindi suportado ng Nextcloud ang pagbabagong ito.

Ang data directory ay isang bind mount, hindi isang named volume, sa sadyang paraan: mas mahalaga ang path na direktang pwedeng ituro ng backup tool kaysa sa pagiging maayos ng structure. I-create ito gamit ang www-data UID ng image at ang mga permission na kailangan ng Nextcloud:

sudo mkdir -p /srv/nextcloud/data
sudo chown -R 33:33 /srv/nextcloud/data
sudo chmod 0770 /srv/nextcloud/data

Pansinin ang port publish: 127.0.0.1:8080:80. Naglalabas ng ports ang Docker sa pamamagitan ng pagsulat ng mga DNAT rules na sinusuri bago pa makarating ang packet sa INPUT chain ng ufw — ang isang bare 8080:80 ay maglalagay sa unencrypted na Nextcloud sa public internet anuman ang settings ng ufw. Ang pag-bind sa loopback ay nagpapanatili nito sa labas ng public interface. Dahil dito, kailangan lang payagan ng firewall ang proxy — at kung ayaw mong iwanang bukas ang SSH sa buong internet, ang pag-access sa VPS gamit ang self-hosted WireGuard VPN ay nagbibigay-daan para tanggalin ang port 22 sa mga public rules nang tuluyan:

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

I-run ito gamit ang docker compose up -d, pagkatapos ay i-monitor ang docker compose logs -f app. Sa unang boot, kokopyahin ng buong application tree ang laman sa volume at tatakbo ang installer; walang sasagutin ang container hangga't hindi ito natatapos.

TLS at ang reverse proxy

I-install ang nginx at certbot mula sa distro, gumawa ng plain port-80 server block na may tamang server_name, at hayaan ang certbot na i-rewrite ito. Ang mekanismo ng HTTP-01 challenge, renewal timer, at mga failure mode ay detalyadong tinalakay sa issuing Let's Encrypt certificates with certbot and nginx on Ubuntu 24.04:

sudo apt install nginx certbot python3-certbot-nginx
sudo certbot --nginx -d cloud.example.com

Idinaragdag ng certbot ang mga ssl_certificate line at ang :80:443 redirect, at nag-i-install ng systemd timer para sa 90-day certificate renewal. I-verify ito gamit ang systemctl list-timers | grep certbot — ang renewal timer na hindi na-enable ay parang 90-day fuse.

Ang proxy block mismo:

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name cloud.example.com;

    # certbot manages ssl_certificate / ssl_certificate_key here

    add_header Strict-Transport-Security "max-age=15552000; includeSubDomains" always;

    client_max_body_size 10G;
    client_body_timeout 300s;

    location = /.well-known/carddav { return 301 /remote.php/dav; }
    location = /.well-known/caldav  { return 301 /remote.php/dav; }

    location / {
        proxy_pass http://127.0.0.1:8080;
        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_request_buffering off;
        proxy_buffering off;
        proxy_read_timeout 3600s;
        proxy_send_timeout 3600s;
    }
}

Sa nginx 1.25 at mas bago, idagdag ang http2 on;. Ang Ubuntu 24.04 ay gumagamit ng mas lumang build kung saan ang katumbas nito ay listen 443 ssl http2;. Sasabihin ng nginx -t kung alin ang tinatanggap ng iyong build.

Ang client_max_body_size at ang mahabang read timeouts ang pumipigil sa pagkaputol ng malalaking upload. I-i-stream ng proxy_request_buffering off ang upload sa halip na i-spool muna ang buong file sa disk ng proxy.

Ang nginx sa host ang pinakasimpleng paraan para sa isang app. Kung ibabahagi ng Nextcloud ang VPS sa ibang mga container, ang running Traefik as a Docker Compose reverse proxy for multiple apps ay inililipat ang routing at certificate issuance sa mga container label; ang mga client_max_body_size at timeout concerns ay muling lalabas doon bilang middleware at transport settings.

trusted_proxies at overwriteprotocol

Dito madalas nagkakaroon ng error ang mga self-hosted Nextcloud instance, at ang mga sintomas ay tila walang kaugnayan sa sanhi.

Ang X-Forwarded-Proto: https ay gagana lamang kung ang request ay nanggaling sa address na nakalista sa trusted_proxies. Kapag hindi ito nagamit, iisipin ng Nextcloud na plain HTTP ang request at maglalabas ito ng mga http:// URL; i-re-redirect ng proxy ang mga ito sa HTTPS; susunod ang browser; maglalabas muli ang Nextcloud ng http://. Ito ang redirect loop. Pinapanatili ng OVERWRITEPROTOCOL: https ang scheme anuman ang mangyari.

Ang problema sa TRUSTED_PROXIES ay ang address na nakikita ng Nextcloud ay hindi ang 127.0.0.1. Ang nginx ay tumatakbo sa host at kumokonekta sa isang published port, kaya ang nakikita ng container ay ang Docker bridge gateway — isang bagay sa 172.x. Hanapin ang totoong subnet:

docker network inspect nextcloud_default \
  -f '{{range .IPAM.Config}}{{.Subnet}}{{end}}'

Ilagay ang CIDR na iyon (o ang sakop nitong 172.16.0.0/12) sa TRUSTED_PROXIES. Kapag masyadong malawak ang setting, maaaring i-spoof ng kahit sinong client ang X-Forwarded-For; kapag mali naman ang setting, ang lahat ng login ay magmumulang nanggagaling sa gateway address, iba-block ng brute-force protection ang buong instance, at lalabas sa admin overview ang "The reverse proxy header configuration is incorrect, or you are accessing Nextcloud from a trusted proxy."

Mahalaga ang OVERWRITECLIURL para sa cron container, dahil wala itong incoming request para malaman ang hostname. Kung wala ito, ang mga background job ay gagawa ng mga link papunta sa localhost at ang mga email notification ay magpapadala ng mga hindi magagamit na URL.

Background jobs: cron, hindi AJAX

Ang default job runner ng Nextcloud ay AJAX: tumatakbo ang mga jobs bilang side effect kapag may naglo-load ng page. Walang nagba-browse nang 04:00, kaya hindi natatapos ang trash expiry, versions cleanup, previews, at federated retries. Ang unang sintomas nito ay ang walang tigil na paglaki ng data directory. Ang cron service sa itaas ay tumatakbo gamit ang official /cron.sh loop sa parehong volumes. Sabihan ang Nextcloud na i-expect ito:

docker compose exec -u www-data app php occ background:cron

Ang bawat occ command ay sumusunod sa format na ito: docker compose exec -u www-data app php occ <command>. Mainam na i-alias ito.

Backups: tatlo dapat, o wala

Ang filesystem-only backup ay hindi gagana sa isang broken instance. Ang data directory ang naglalaman ng bytes; ang Postgres ang may hawak ng file cache, shares, users, at app state; ang config.php ang may hawak ng database credentials, instance ID, at password salt. Kapag ni-restore ang files nang walang database, hindi sila makikita ng Nextcloud. Kapag ni-restore ang database nang walang config.php, hindi nito mabubuksan ang database. Kapag ni-restore ang lumang database sa mas bagong data directory, magkakaroon ng mga share na nakaturo sa mga file na lumipat na ng pwesto.

I-back up ang lahat ng tatlo mula sa isang quiesced instance:

#!/usr/bin/env bash
set -euo pipefail
cd /srv/nextcloud
DEST="/var/backups/nextcloud/$(date -u +%Y%m%dT%H%M%SZ)"
mkdir -p "$DEST"

occ() { docker compose exec -T -u www-data app php occ "$@"; }

occ maintenance:mode --on
trap 'occ maintenance:mode --off' EXIT

docker compose exec -T db \
  pg_dump -U nextcloud --clean --if-exists nextcloud | gzip > "$DEST/db.sql.gz"

docker compose exec -T app \
  tar -C /var/www/html -cf - config custom_apps themes > "$DEST/app.tar"

rsync -a --delete /srv/nextcloud/data/ /var/backups/nextcloud/data/

Ang maintenance mode ang nagsisiguro na magtutugma ang dump at ang file copy. Kapag hindi ito ginamit, maaaring ma-capture ang database na may reference sa isang file na hindi pa naabot ng rsync. Tandaan na ang script ay nagtatabi ng mga timestamped database dumps, pero isang rolling mirror lang ang para sa data directory — tinatabunan ng rsync --delete ang dati nito sa bawat run — kaya ang pinakabagong dump lang ang kapares ng file copy.

Pagkatapos, ilipat ito sa ibang machine. Ang backup na nasa parehong VPS gaya ng item na bina-back up nito ay isang copy lamang, hindi isang backup. Ang restic laban sa object storage o sa pangalawang host ang karaniwang solusyon, at mas maganda ang deduplication nito para sa data directory kumpara sa nightly tarball. Ang buong setup, mula sa repository init hanggang sa nightly timer at restore drill, ay nasa off-box VPS backups with restic.

Ang restore ay hindi simpleng pagbaligtad lang ng proseso. Ang isang bagong-start na stack ay magpapatakbo ng installer at gagawa ng bagong config.php — isang bagong instance ID at password salt — at ang pag-import ng dump sa bagong identity na iyon ay magreresulta sa mga broken session at share tokens. Ibalik muna ang lumang identity sa pagkakasunod-sunod na ito:

docker compose up -d && docker compose stop app cron    # create the volumes, then halt the app
sudo rsync -a --delete /var/backups/nextcloud/data/ /srv/nextcloud/data/
docker compose run --rm -T --entrypoint "" app \
  tar -C /var/www/html -xf - < app.tar                  # the original config.php returns
gunzip -c db.sql.gz | docker compose exec -T db psql -U nextcloud -d nextcloud
docker compose start app cron
docker compose exec -T -u www-data app php occ maintenance:mode --off
docker compose exec -T -u www-data app php occ files:scan --all

Ang files:scan ang nagtutugma ng file cache sa kung ano ang aktwal na nasa disk. Mag-practice nito nang isang beses sa isang spare VPS bago mo ito kailanganin.

Upgrades: isa lang dapat ang major version bawat pagkakataon

Ang Nextcloud ay sumusuporta lamang sa pag-upgrade ng isang major version sa bawat pagkakataon. Ang pagtalon mula 29 patungong 31 ay magdudulot ng error na Exception: Updates between multiple major versions and downgrades are unsupported. at mag-iiwan sa system sa maintenance mode.

Ang proseso ng Docker upgrade ay: gumawa ng backup, i-edit ang tag mula 31 patungong 32 sa app at cron services, pagkatapos ay i-run ang docker compose pull && docker compose up -d, at pagkatapos ay docker compose logs -f app. Ang image entrypoint ang mag-verify ng bagong code laban sa existing data at kusa nitong tatakbo ang occ upgrade. Huwag itong i-interrupt. Kapag tumigil na ang logs, i-run ang docker compose exec -u www-data app php occ status at i-check ang versionstring at siguraduhin na enabled muli ang mga apps.

Dalawang panuntunan para makaiwas sa error: i-upgrade ang isang major version, i-verify ito, bago mag-upgrade sa susunod. At huwag kailanman i-edit ang tag sa app service nang hindi inaayos ang cron para magtugma — ang paggamit ng dalawang magkaibang Nextcloud version sa iisang database ay magdudulot ng corruption.

Ang mga error na makikita mo

"Your data directory is readable by other users. Please change the permissions to 0770." May group o world read bits ang bind-mounted directory. sudo chmod 0770 /srv/nextcloud/data at sudo chown -R 33:33 /srv/nextcloud/data.

"Your data directory is invalid. Ensure there is a file called .ocdata in the root." Ang bind mount ay nakaturo sa directory na hindi pa na-i-initialize ng Nextcloud — maaaring may typo sa path, o may bagong empty directory na ipinalit sa working instance. Siguraduhin na tugma ang host path sa volume line.

"Access through untrusted domain." Ang hostname sa request ay wala sa trusted_domains. Ang NEXTCLOUD_TRUSTED_DOMAINS ay para sa unang install lamang; pagkatapos nito, i-set ito nang live: occ config:system:set trusted_domains 1 --value=cloud.example.com.

502 Bad Gateway, na may connect() failed (111: Connection refused) while connecting to upstream sa /var/log/nginx/error.log. Walang nahanap na koneksyon ang nginx sa 127.0.0.1:8080. Maaaring nag-i-initialize pa ang container (i-check ang docker compose logs app), nag-exit ito (docker compose ps), o hindi tugma ang publish line sa proxy_pass port. I-verify gamit ang ss -ltnp | grep 8080.

Redirect loop, o "insecure" warnings sa admin overview. Kulang ang OVERWRITEPROTOCOL: https, o walang Docker gateway subnet ang TRUSTED_PROXIES. Tingnan ang proxy section sa itaas.

LockedException: "files/..." is locked. Kapag naka-set ang REDIS_HOST, ginagamit ng image ang Redis bilang locking backend kaya bihira ang stale locks. Kung wala ito, ang mga lock ay nasa database table na oc_file_locks at nag-iiwan ng mga rows kapag naputol ang request habang nagsusulat. Siguraduhin muna na ginagamit talaga ang Redis — dapat Redis class ang ibalik ng occ config:system:get memcache.locking — bago magbura ng mga lock rows nang manual.

"The PHP memory limit is below the recommended value of 512MB." Taasan ang PHP_MEMORY_LIMIT at i-recreate ang container. Tandaan ang epekto nito sa iyong worst-case ceiling.

Ano ang nagiging sanhi ng pagkasira sa scale

Ang unang limitasyon ay ang pagkapuno ng data directory sa volume. Ang pagpapalaki ng volume sa isang VPS ay nangangailangan ng resize at filesystem grow. Mas mahirap itong i-schedule kapag 100% full na ang disk — mag-set ng alert sa disk usage ngayon, hindi mamaya.

Ang ikalawang limitasyon ay ang oc_filecache. Bumabagal ang file listings at sync scans habang dumarami ang row count. Ang solusyon ay database maintenance: panatilihin ang Postgres sa mabilis na storage, bigyan ito ng sapat na shared memory, at i-prune ang mga basura at lumang versions gamit ang retention settings sa halip na hayaan silang maipon nang habambuhay.

Ang ikatlo ay ang preview generation na nakikipag-compete sa ibang proseso. Sa maliliit na server, limitahan ang mga preview providers at huwag kailanman patakbuhin ang occ preview:generate-all habang working hours.

Higit pa rito, ang tapat na sagot ay kailangan ng mga extra features ng sarili nilang machine. Ang Collabora at full-text search ay magkahiwalay na resident services na may sariling memory profiles. Ang paglalagay sa kanila sa parehong server kung nasaan ang iyong tanging kopya ng mga files ay nagpapalaki sa failure domain nang walang benepisyo. Ilipat ang file storage sa S3-compatible primary storage kapag hindi na angkop ang kasalukuyang volume — tandaan na mas mahirap ang backups dahil dito: ang database ay may hawak pa ring metadata, at dapat itong i-dump kasabay ng bucket.

Kapag ang instance ay nagsisilbi na sa mga totoong user, maglagay ng Uptime Kuma sa harap nito para malaman mo ang downtime bago pa ito malaman ng mga sync clients. Ang private cloud ay mainam na ipares sa sarili mong mail server, at kung ayaw mong i-configure ang mga services nang manual, ihambing ang mga platform na Cloudron, CasaOS at Coolify na gumagawa nito para sa iyo.

FAQ

Maaari ko bang gamitin ang SQLite sa halip na Postgres para sa Nextcloud?

Maaari ito, at pinahihintulutan ito ng official image, pero magdudulot ito ng SQLSTATE[HY000]: General error: 5 database is locked at HTTP 500 errors kapag maraming parallel requests ang isinagawa ng isang desktop sync client. Naglalagay ang SQLite ng database-wide write lock, at ang Nextcloud ay madalas magsagawa ng writes — para sa file locks, activity rows, at job state. Simulan ang setup gamit ang Postgres o MariaDB; mayroong occ db:convert-type pero mahaba at "all-or-nothing" ang migration nito sa live data.

Gaano karaming RAM ang kailangan ng isang Nextcloud VPS?

Ang sukat ay dapat base sa concurrency, hindi sa bilang ng users. Ang worst-case resident memory ay humigit-kumulang sa bilang ng concurrent requests multiplied by PHP_MEMORY_LIMIT, plus ang Postgres shared buffers at isang backend bawat connection, plus ang spikes sa preview generation. Ang isang 2 GB na box ay kayang magpatakbo ng maliit na household instance kung lilimitahan ang previews at magdadagdag ng swap; kung magdadagdag ng Collabora o full-text search, kailangan mo ng pangalawang set ng resident services.

Bakit nag-eerror ang malalaking uploads sa likod ng nginx reverse proxy?

Dalawang settings sa proxy ang karaniwang sanhi nito: ang client_max_body_size na nakaset sa 1 MB default ay nagti-truncate ng request, at ang maikling proxy_read_timeout / proxy_send_timeout values ay nagpapatigil sa mahahabang transfers. I-set ang parehong ito nang malaki, i-set ang proxy_request_buffering off sa stream sa halip na spool, at itaas ang PHP_UPLOAD_LIMIT sa app container para tumugma rito.

Bakit nagkakaroon ng redirect loop o warning tungkol sa reverse proxy sa Nextcloud?

Hindi nakikita ng container ang nginx sa 127.0.0.1 — ang nakikita nito ay ang Docker bridge gateway sa 172.x. Kapag wala ang address na iyon sa TRUSTED_PROXIES, hindi binabasa ang X-Forwarded-Proto: https header, maglalabas ang Nextcloud ng mga http:// URL, at ibabalik ito ng proxy. I-set ang TRUSTED_PROXIES sa tunay na bridge subnet at i-pin ang OVERWRITEPROTOCOL: https.

Maaari ko bang i-upgrade ang Nextcloud mula 29 diretso sa 31?

Hindi. Ang Nextcloud ay sumusuporta lamang sa isang major version bawat upgrade. Ang paglaktaw ay hihinto sa Updates between multiple major versions and downgrades are unsupported., at maiiwan ang instance sa maintenance mode. Mag-backup, i-update ang tag ng isang major version sa parehong app at cron services, docker compose pull && docker compose up -d, i-verify gamit ang occ status, at ulitin ang proseso.