Instalacja Nextcloud na VPS w Docker

Co zostanie zbudowane

Niniejszy poradnik opisuje uruchomienie Nextcloud na VPS przy użyciu Docker Compose, konfigurację TLS Let's Encrypt oraz wdrożenie systemu kopii zapasowych umożliwiającego pełne przywracanie danych. Rozwiązanie składa się z czterech kontenerów i proxy: oficjalnego obrazu nextcloud nasłuchującego na interfejsie loopback, bazy Postgres przechowującej metadane plików, bazy Redis obsługującej blokady plików, drugiego obrazu Nextcloud uruchamiającego wyłącznie pętlę cron oraz serwera nginx na hoście, który terminują TLS przed wszystkimi usługami. Proces instalacji trwa dwadzieścia minut, jednak kluczowe są inne aspekty. O tym, czy dane zostaną zachowane po roku, decydują dwie decyzje podjęte w pierwszej godzinie: zastosowanie pełnej bazy danych zamiast SQLite oraz utworzenie kopii zapasowej obejmującej katalog danych, bazę danych oraz config.php jako jeden spójny zestaw.

Wymagania wstępne to system Ubuntu 24.04 LTS lub Debian 13, zainstalowany Docker Engine z wtyczką Compose v2 z oficjalnego repozytorium Docker oraz rekord DNS A (oraz AAAA w przypadku obsługi IPv6) skierowany na cloud.example.com adresu VPS. Wszystkie komponenty wymagają serwera pod pełną kontrolą użytkownika — terminacja TLS oraz zrzut bazy danych nie są możliwe w usługach typu SaaS.

Sizing: co faktycznie zużywa pamięć

Zużycie pamięci przez Nextcloud wynika głównie z trzech czynników, z których żaden nie stanowi bezpośrednio procesu "Nextcloud".

PHP workers. Obraz -apache obsługuje każde jednoczesne żądanie za pomocą procesu worker, który zawiera interpreter PHP. Każdy worker może zużywać do PHP_MEMORY_LIMIT pamięci, zanim PHP przerwie żądanie. Maksymalne zużycie pamięci RAM wynosi w przybliżeniu liczba jednoczesnych żądań × limit pamięci. Klient synchronizacji desktopowej otwiera kilka równoległych połączeń na każdego użytkownika. To współbieżność, a nie liczba użytkowników, wyznacza górny limit.

Baza danych. Postgres tworzy proces backend dla każdego połączenia i utrzymuje bufory współdzielone (shared buffers) w pamięci. Zestaw roboczy bazy danych rośnie wraz z liczbą plików, a nie liczbą bajtów: oc_filecache przechowuje jeden wiersz na każdy plik na użytkownika. Sto tysięcy małych plików obciąża bazę bardziej niż sto dużych plików.

Generowanie podglądów. Generowanie miniatury wymaga dekodowania obrazu źródłowego do pamięci w pełnej rozdzielczości. Podglądy wideo wywołują proces ffmpeg. Uruchomienie occ preview:generate-all powoduje powtarzające się skoki zużycia pamięci, co jest najczęstszą przyczyną wywołania mechanizmu OOM killer na małych instancjach VPS.

Redis jest stosunkowo mało wymagający. Każda dodatkowa usługa — Collabora, wyszukiwanie pełnotekstowe, skaner antywirusowy — jest osobnym procesem działającym w pamięci z własnym zapotrzebowaniem na zasoby. Należy uwzględnić je w planowaniu zasobów przed ich aktywacją.

Dostępne metody optymalizacji przy ograniczonej pamięci RAM: obniżyć PHP_MEMORY_LIMIT, ograniczyć preview_max_x / preview_max_y / preview_max_filesize_image, ograniczyć enabledPreviewProviders tylko do formatów, które są przeglądane, oraz ustawić trashbin_retention_obligation i versions_retention_obligation tak, aby katalog danych nie urósł niekontrolowanie do rozmiaru kilkukrotnie większego niż rozmiar plików. Należy dodać plik swap. Swap działa wolno, ale przerwanie aktualizacji przez OOM killer jest bardziej krytyczne.

Dlaczego SQLite nie działa poprawnie

Nextcloud posiada wsparcie dla SQLite, a oficjalny obraz domyślnie go używa. Nie należy tego robić. SQLite serializuje operacje zapisu za pomocą blokady obejmującej całą bazę danych: w danym momencie może wykonywać tylko jeden proces zapisu dla całego pliku. Nextcloud generuje ciągłe operacje zapisu — blokady plików, wpisy w tabelach aktywności, wpisy w pamięci cache, stany zadań — a pojedynczy klient desktopowy synchronizujący drzewo katalogów wysyła wiele równoległych żądań. Przy takim wzorcu pracy występują błędy SQLSTATE[HY000]: General error: 5 database is locked oraz błędy HTTP 500, a awaria występuje dokładnie w momencie, gdy instancja staje się użyteczna.

Późniejsza konwersja jest możliwa przy użyciu occ db:convert-type, jednak jest to długotrwała migracja typu "wszystko albo nic" na aktywnym zbiorze danych. Należy zacząć od Postgres lub MariaDB.

Plik Compose

Umieść poniższy kod w /srv/nextcloud/compose.yaml, a sekrety w sąsiednim pliku .env w trybie 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:

Przed skopiowaniem 31 należy sprawdzić aktualną wersję na Docker Hub i przypisać główny tag. latest może spowodować aktualizację do nowej wersji głównej w przyszłości (docker compose pull), a Nextcloud nie obsługuje takich zmian.

Katalog danych jest celowo skonfigurowany jako bind mount, a nie named volume: bezpośredni dostęp narzędzia do kopii zapasowej jest ważniejszy niż porządek w strukturze. Utwórz katalog z UID obrazu www-data oraz uprawnieniami wymaganymi przez Nextcloud:

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

Zwróć uwagę na publikację portu: 127.0.0.1:8080:80. Docker publikuje porty poprzez tworzenie reguł DNAT, które są przetwarzane przed regułami łańcucha INPUT w ufw. Pozostawienie go jako 8080:80 wystawia niezaszyfrowany Nextcloud na publiczny internet, niezależnie od ustawień ufw. Wiązanie do interfejsu loopback izoluje usługę od publicznego interfejsu. W takim przypadku firewall musi zezwalać jedynie na ruch z proxy — jeśli nie chcesz pozostawiać otwartego portu SSH dla całego internetu, połączenie z VPS przez własny serwer WireGuard VPN pozwala całkowicie usunąć port 22 z reguł publicznych:

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

Uruchom usługę za pomocą docker compose up -d, a następnie monitoruj docker compose logs -f app. Podczas pierwszego uruchomienia całe drzewo aplikacji jest kopiowane do wolumenu i uruchamiany jest instalator; kontener nie odpowiada na żadne żądania do czasu zakończenia tego procesu.

TLS i reverse proxy

Należy zainstalować nginx oraz certbot z repozytorium dystrybucji, utworzyć zwykły server block na porcie 80 z poprawnym server_name, a następnie pozwolić programowi certbot na jego modyfikację. Mechanizm wyzwania HTTP-01, timer odnawiania oraz przyczyny błędów zostały szczegółowo opisane w wydawaniu certyfikatów Let's Encrypt za pomocą certbot i nginx na Ubuntu 24.04:

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

Certbot dodaje linie ssl_certificate oraz przekierowanie :80 → :443, a także instaluje timer systemd odnawiający 90-dniowy certyfikat. Można to potwierdzić za pomocą systemctl list-timers | grep certbot — brak aktywnego timera odnawiania skutkuje wygaśnięciem certyfikatu po 90 dniach.

Blok proxy:

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;
    }
}

W wersji nginx 1.25 i nowszych należy dodać http2 on;. Ubuntu 24.04 dostarcza starszą wersję, w której odpowiednikiem jest listen 443 ssl http2;. Polecenie nginx -t wskaże, która opcja jest obsługiwana przez daną wersję.

client_max_body_size oraz długie czasy oczekiwania na odczyt (read timeouts) zapobiegają przerywaniu dużych przesyłanych plików. proxy_request_buffering off przesyła dane strumieniowo, zamiast zapisywać cały plik na dysku proxy.

Instalacja nginx bezpośrednio na hoście jest najprostszym rozwiązaniem dla jednej aplikacji. Jeśli Nextcloud ma współdzielić VPS z innymi kontenerami, użycie Traefik jako reverse proxy w Docker Compose dla wielu aplikacji przenosi routing i wydawanie certyfikatów do etykiet (labels) kontenerów; w takim przypadku kwestie client_max_body_size oraz timeoutów powracają jako ustawienia middleware i transportu.

trusted_proxies and overwriteprotocol

To tutaj najczęstszy powód błędów w instalacjach Nextcloud typu self-hosted, a objawy wydają się niezwiązane z przyczyną.

Parametr X-Forwarded-Proto: https jest honorowany tylko wtedy, gdy żądanie pochodzi z adresu wymienionego w trusted_proxies. Gdy parametr nie jest honorowany, Nextcloud uznaje żądanie za zwykłe HTTP i generuje adresy URL typu http://; proxy przekierowuje je na HTTPS; przeglądarka podąża za przekierowaniem; Nextcloud ponownie generuje http://. Powstaje pętla przekierowań. Parametr OVERWRITEPROTOCOL: https wymusza schemat protokołu niezależnie od innych ustawień.

Błąd w TRUSTED_PROXIES polega na tym, że adres widoczny przez Nextcloud to nie jest 127.0.0.1. nginx działa na hoście i łączy się przez opublikowany port, więc kontener widzi bramę (gateway) mostka Docker — adres z zakresu 172.x. Należy ustalić właściwą podsieć:

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

Należy wpisać ten zakres CIDR (lub obejmujący go 172.16.0.0/12) do TRUSTED_PROXIES. Zbyt szeroki zakres umożliwi klientom podszywanie się pod X-Forwarded-For; błędny zakres spowoduje, że każde logowanie będzie widoczne jako pochodzące z adresu bramy, co doprowadzi do zablokowania całej instancji przez mechanizm ochrony przed brute-force, a w panelu administracyjnym pojawi się komunikat: "The reverse proxy header configuration is incorrect, or you are accessing Nextcloud from a trusted proxy."

Parametr OVERWRITECLIURL jest istotny dla kontenera cron, który nie otrzymuje przychodzących żądań do wywnioskowania nazwy hosta. Bez tego ustawienia zadania w tle generują linki do localhost, a powiadomienia e-mail zawierają nieużyteczne adresy URL.

Zadania w tle: cron, nie AJAX

Domyślnnym mechanizmem uruchamiania zadań w Nextcloud jest AJAX: zadania są wykonywane jako efekt uboczny ładowania strony przez użytkownika. Brak aktywności użytkowników o godzinie 04:00 powoduje zatrzymanie procesów usuwania śmieci, czyszczenia wersji, generowania podglądów oraz ponawiania prób połączeń federated. Pierwszym objawem jest niekontrolowany wzrost rozmiaru katalogum danych. Powyższa usługa cron uruchamia oficjalną pętlę /cron.sh na tych samych wolumenach. Należy skonfigurować Nextcloud tak, aby oczekiwał tego procesu:

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

Każda komenda occ ma następującą strukturę: docker compose exec -u www-data app php occ <command>. Zaleca się utworzenie aliasu.

Backups: trzy elementy lub brak

Kopia zapasowa samych plików systemu plików nie przywróci uszkodzonej instancji. Katalog danych zawiera bajty; Postgres przechowuje pamięć podręczną plików, udostępnione zasoby, użytkowników oraz stan aplikacji; config.php przechowuje dane uwierzytelniające bazy danych, identyfikator instancji oraz sól hasła. Przywrócenie plików bez bazy danych uniemożliwi Nextcloud ich odczytanie. Przywrócenie bazy danych bez config.php uniemożliwi jej otwarcie. Przywrócenie starej bazy danych do nowszego katalogu danych spowoduje błędy w udostępnionych zasobach wskazujących na pliki, których lokalizacja uległa zmianie.

Należy wykonać kopię zapasową wszystkich trzech elementów z instancji w stanie spoczynku (quiesced):

#!/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/

Tryb konserwacji (Maintenance mode) zapewnia spójność zrzutu bazy danych z kopią plików. Pominięcie tego kroku spowoduje zapisanie bazy danych zawierającej odwołania do plików, których rsync jeszcze nie skopiował. Skrypt przechowuje zrzuty bazy danych z datami, ale tylko jedną rotacyjną kopię katalogu danych — rsync --delete nadpisuje ją przy każdym uruchomieniu — zatem tylko najnowszy zrzut jest zgodny z kopią plików.

Następnie należy przenieść kopię poza serwer. Kopia znajdująca się na tym samym VPS co dane źródłowe jest jedynie duplikatem, a nie kopią zapasową. Standardowym rozwiązaniem jest użycie restic w celu przesłania danych do pamięci obiektowej lub na drugi host; mechanizm deduplikacji znacznie lepiej radzi sobie z katalogiem danych niż codzienne pliki tarball. Pełna konfiguracja, od inicjalizacji repozytorium po harmonogram zadań i procedurę przywracania, znajduje się w off-box VPS backups with restic.

Przywracanie nie jest prostym procesem odwrotnym. Nowo zainstalowany stos uruchamia instalator i generuje nowy config.php — nowy identyfikator instancji i sól hasła — a zaimportowanie zrzutu do nowej tożsamości skutkuje błędnymi sesjami i tokenami udostępniania. Najpierw należy przywrócić starą tożsamość, zachowując następującą kolejność:

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

files:scan synchronizuje pamięć podręczną plików z rzeczywistym stanem na dysku. Należy przećwiczyć tę procedurę raz na dodatkowym VPS przed wystąpieniem awarii.

Upgrades: jedna wersja główna naraz

Nextcloud obsługuje aktualizację tylko jednej wersji głównej naraz. Przejście bezpośrednio z wersji 29 na 31 nie przebiega pomyślnie — występuje błąd Exception: Updates between multiple major versions and downgrades are unsupported., a system przechodzi w tryb konserwacji (maintenance mode).

Proces aktualizacji w Dockerze wygląda następująco: wykonaj kopię zapasową, zmień tag z 31 na 32 w usługach app oraz cron, następnie wykonaj docker compose pull && docker compose up -d, a potem docker compose logs -f app. Entrypoint obrazu weryfikuje nowszy kod względem istniejących danych i automatycznie uruchamia occ upgrade. Nie przerywaj tego procesu. Gdy logi przestaną wyświetlać nowe wpisy, wykonaj docker compose exec -u www-data app php occ status i sprawdź versionstring oraz czy aplikacje są ponownie włączone.

Dwie zasady zapobiegające błędom: najpierw zaktualizuj jedną wersję główną, zweryfikuj działanie, a następnie zaktualizuj kolejną. Nigdy nie zmieniaj tagu w usłudze app bez jednoczesnej zmiany w cron w celu zachowania zgodności — użycie dwóch różnych wersji Nextcloud na jednej bazie danych prowadzi do uszkodzenia danych.

Błędy, które faktycznie wystąpią

"Your data directory is readable by other users. Please change the permissions to 0770." Katalog podmontowany przez bind-mount posiada uprawnienia do odczytu dla grupy lub innych użytkowników. sudo chmod 0770 /srv/nextcloud/data oraz sudo chown -R 33:33 /srv/nextcloud/data.

"Your data directory is invalid. Ensure there is a file called .ocdata in the root." Punkt montowania bind-mount wskazuje na lokalizację, która nie została zainicjalizowana przez Nextcloud — błąd w ścieżce lub podmienienie działającej instancji pustym katalogiem. Należy sprawdzić, czy ścieżka na hoście jest zgodna z linią volume.

"Access through untrusted domain." Nazwa hosta w zapytaniu nie znajduje się w trusted_domains. NEXTCLOUD_TRUSTED_DOMAINS dotyczy tylko pierwszej instalacji; w późniejszych etapach należy ustawić ją na żywo: occ config:system:set trusted_domains 1 --value=cloud.example.com.

502 Bad Gateway, z błędem connect() failed (111: Connection refused) while connecting to upstream w /var/log/nginx/error.log. nginx nie nawiązał połączenia na 127.0.0.1:8080. Kontener jest w trakcie inicjalizacji (sprawdzić docker compose logs app), uległ awarii (docker compose ps) lub linia publish nie odpowiada portowi proxy_pass. Należy potwierdzić za pomocą ss -ltnp | grep 8080.

Pętla przekierowań lub ostrzeżenia "insecure" w przeglądzie administratora. Brakuje OVERWRITEPROTOCOL: https lub TRUSTED_PROXIES nie zawiera podsieci bramy Docker. Patrz: sekcja dotycząca proxy powyżej.

LockedException: "files/..." is locked. Przy ustawionej zmiennej REDIS_HOST obraz konfiguruje Redis jako backend blokad (locking backend), co minimalizuje ryzyko wystąpienia przestarzałych blokad. Bez tej zmiennej blokady są zapisywane w tabeli bazy danych oc_file_locks, a przerwanie zapisu podczas żądania pozostawia niepotrzebne wiersze. Przed ręcznym usuwaniem wierszy blokad należy potwierdzić użycie Redis — occ config:system:get memcache.locking powinno zwrócić klasę Redis.

"The PHP memory limit is below the recommended value of 512MB." Należy zwiększyć PHP_MEMORY_LIMIT i ponownie utworzyć kontener. Należy pamiętać o wpływie tej zmiany na maksymalny limit pamięci.

Problemy przy dużej skali

Pierwszą barierą jest rozmiar katalogu danych przekraczający pojemność wolumenu. Zwiększenie rozmiaru wolumenu na VPS wymaga zmiany rozmiaru partycji oraz rozszerzenia systemu plików. Proces ten jest trudniejszy do zaplanowania, gdy dysk jest zapełniony w 100% — należy ustawić alerty zużycia miejsca na dysku z wyprzedzeniem.

Drugą barierą jest oc_filecache. Wyświetlanie list plików oraz skanowanie synchronizacji spowalnia wraz ze wzrostem liczby wierszy. Rozwiązaniem jest optymalizacja bazy danych: należy umieścić Postgres na szybkim nośniku, zapewnić mu odpowiednią ilość pamięci shared memory oraz regularnie usuwać zbędne dane i stare wersje za pomocą ustawień retencji.

Trzecim problemem jest generowanie podglądów obciążające zasoby systemu. Na słabszych maszynach należy ograniczyć liczbę dostawców podglądu i nigdy nie uruchamiać occ preview:generate-all w godzinach pracy.

Poza tymi kwestiami, dodatkowe usługi wymagają dedykowanych maszyn. Collabora oraz pełnotekstowe wyszukiwanie to oddzielne usługi działające w tle o własnych profilach zużycia pamięci. Umieszczenie ich na tej samej maszynie, na której znajduje się jedyna kopia plików, zwiększa zakres awarii bez żadnych korzyści. Należy przenieść przechowywanie plików na pamięć masową zgodną z protokołem S3, gdy wolumen przestaje być optymalny — należy jednak pamiętać, że utrudnia to tworzenie kopii zapasowych: baza danych nadal przechowuje metadane i musi być kopiowana w tym samym czasie co bucket.

Gdy instancja obsługuje rzeczywistych użytkowników, należy zainstalować Uptime Kuma, aby otrzymać powiadomienie o awarii przed klientami synchronizacji. Chmura prywatna dobrze współpracuje z własnym serwerem poczty, a jeśli nie chcą Państwo ręcznie łączyć usług, można porównać platformy takie jak Cloudron, CasaOS i Coolify, które wykonują tę pracę automatycznie.

FAQ

Czy można uruchomić Nextcloud na SQLite zamiast Postgres?

Tak, oficjalny obraz na to pozwala, jednak pojedynczy klient desktopowy wysyłający równoległe żądania spowoduje błędy SQLSTATE[HY000]: General error: 5 database is locked oraz HTTP 500. SQLite stosuje blokadę zapisu dla całej bazy danych, a Nextcloud wykonuje operacje zapisu stale — blokady plików, wpisy aktywności, stan zadań. Należy zacząć od Postgres lub MariaDB; rozwiązanie occ db:convert-type istnieje, lecz migracja danych na żywo jest długotrwała i nieodwracalna.

Ile pamięci RAM faktycznie potrzebuje VPS dla Nextcloud?

Parametry należy dobierać pod kątem liczby równoległych żądań, a nie liczby użytkowników. Maksymalne zużycie pamięci RAM to w przybliżeniu liczba równoległych żądań pomnożona przez PHP_MEMORY_LIMIT, plus shared buffers w Postgres oraz jeden proces backendowy na każde połączenie, plus dodatkowe zużycie podczas generowania podglądów. Maszyna z 2 GB RAM obsłuży małą instancję domową, jeśli ograniczono generowanie podglądów i dodano swap; instalacja Collabora lub pełnotekstowego wyszukiwania wymaga przeliczenia zasobów dla dodatkowych usług.

Dlaczego duże przesyłanie plików kończy się błędem za reverse proxy nginx?

Przyczyną są zazwyczaj dwie konfiguracje proxy: domyślna wartość client_max_body_size wynosząca 1 MB powoduje przerwanie żądania, a krótkie wartości proxy_read_timeout / proxy_send_timeout przerywają długie transfery. Należy ustawić obie wartości z dużym zapasem, zmienić proxy_request_buffering off na stream zamiast spool oraz zwiększyć PHP_UPLOAD_LIMIT w kontenerze aplikacji do odpowiedniego poziomu.

Dlaczego Nextcloud wpada w pętlę przekierowań lub wyświetla ostrzeżenie o reverse proxy?

Kontener nie widzi nginx pod adresem 127.0.0.1 — widzi bramę Docker bridge w zakresie 172.x. Gdy ten adres nie znajduje się w TRUSTED_PROXIES, nagłówek X-Forwarded-Proto: https jest ignorowany, Nextcloud generuje adresy URL typu http://, a proxy przekierowuje je z powrotem. Należy ustawić TRUSTED_PROXIES na właściwą podsieć bridge i utwierdzić OVERWRITEPROTOCOL: https.

Czy można zaktualizować Nextcloud bezpośrednio z wersji 29 na 31?

Nie. Nextcloud obsługuje tylko jedną główną wersję podczas aktualizacji; pominięcie wersji spowoduje błąd Updates between multiple major versions and downgrades are unsupported. i przełączenie instancji w tryb konserwacji (maintenance mode). Należy wykonać kopię zapasową, zwiększyć tag o jedną wersję główną w usługach app oraz cron, wykonać docker compose pull && docker compose up -d, zweryfikować za pomocą occ status, a następnie powtórzyć proces.