Self-hosting na Synology: jak sensownie ogarnąć kontenery w Container Managerze

Jeśli masz NAS-a Synology z serii plus (DS220+, DS920+, DS923+ i podobne), to prawdopodobnie kupiłeś go „na zdjęcia i backup”, a po miesiącu okazało się, że da się na nim postawić pół domowej infrastruktury: Vaultwarden, Pi-hole, Paperless-ngx, Immich, Home Assistant. Wszystko to działa w kontenerach, a klikanie każdego z nich z osobna w GUI szybko robi się nie do utrzymania. Da się to uporządkować tak, żeby po pół roku nadal wiedzieć, co gdzie stoi.

Container Manager to Docker pod nową nazwą

Od DSM 7.2 Container Manager zastąpił pakiet Docker. Pod spodem nadal jest Docker, a projekty z plikami Compose obsługuje zakładka Project. Kreator w GUI możesz pominąć i pracować tak jak na zwykłym serwerze.

Włącz SSH (Panel sterowania → Terminal i SNMP → Terminal), zaloguj się i sprawdź wersje:

sudo docker version
sudo docker compose version

Dokumentacja Synology opisuje operacje projektów poleceniami docker-compose, więc sprawdź, której składni używa Twoja wersja: docker compose (plugin) czy starszego docker-compose. Przykłady poniżej używają pierwszej.

Jeden folder na stack, cała konfiguracja w compose

Największy błąd początkujących to stawianie kontenerów przez GUI i zapominanie, jak się je skonfigurowało. Za trzy miesiące, przy migracji albo awarii, nie odtworzysz tego z głowy.

Zrób na wolumenie strukturę, np. /volume1/docker/, a w niej folder na każdą aplikację:

/volume1/docker/
├── vaultwarden/
│   ├── docker-compose.yml
│   └── data/
├── paperless/
│   ├── docker-compose.yml
│   ├── .env
│   └── data/
└── immich/
    ├── docker-compose.yml
    └── .env

Konfiguracja jest w pliku, dane leżą obok. Backup całego /volume1/docker to backup całego self-hostingu, a migracja na nowego NAS-a sprowadza się do skopiowania folderu i docker compose up -d.

Przykład: Vaultwarden, dobry pierwszy kontener na start.

services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      - SIGNUPS_ALLOWED=false
      - DOMAIN=https://vault.twojadomena.pl
    volumes:
      - ./data:/data
    ports:
      - "8222:80"

Uruchamiasz z katalogu stacku:

cd /volume1/docker/vaultwarden
sudo docker compose up -d

Container Manager pokaże ten kontener w GUI i możesz go stamtąd monitorować, ale źródłem prawdy jest plik.

Uważaj na UID/PUID i uprawnienia

Tu łatwo stracić wieczór. Użytkownik DSM zwykle nie ma UID 1000, który zakłada większość poradników z internetu. Sprawdź swój:

id twoj_uzytkownik

Dostaniesz coś w stylu uid=1026 gid=100(users). Obrazy LinuxServer.io (lscr.io/linuxserver/...) przyjmują zmienne PUID i PGID. Wpisz tam wartości ze swojego systemu, bo inaczej kontener nie zapisze do wolumenu albo utworzy pliki, których nie ruszysz z poziomu File Station.

    environment:
      - PUID=1026
      - PGID=100
      - TZ=Europe/Warsaw

Sieć: nie wystawiaj wszystkiego na porty hosta

Domyślny odruch to mapowanie 8080:80, 8222:80, 3000:3000 i zapamiętywanie tych numerów. Po pięciu kontenerach robi się z tego chaos, a każdy opublikowany port to dziura w bezpieczeństwie, bo słucha na IP NAS-a.

Lepsze podejście to reverse proxy. DSM ma własne (Panel sterowania → Portal logowania → Zaawansowane → Reverse Proxy). Wystawi kontener pod adresem w rodzaju https://paperless.twojadomena.pl, a certyfikat Let's Encrypt wygenerujesz w Panelu sterowania → Bezpieczeństwo → Certyfikat. Let's Encrypt sprawdza domenę przez port 80, który musi być otwarty na NAS-ie i routerze zarówno przy wystawieniu certyfikatu, jak i przy każdym odnowieniu. Zasady wystawiania usług do internetu opisuje wpis o zabezpieczaniu DSM.

Schemat działania:

• kontener słucha lokalnie, np. na 127.0.0.1:8000,
• reverse proxy DSM przekierowuje ruch z paperless.twojadomena.pl:443 na localhost:8000,
• certyfikat obsługuje DSM, a kontener nic nie wie o HTTPS.

Jeśli chcesz więcej kontroli (a docelowo będziesz chciał), rozważ osobny kontener z Nginx Proxy Manager albo Traefikiem i wspólną siecią Docker zamiast portów hosta:

networks:
  proxy:
    external: true

Wtedy aplikacje w ogóle nie publikują portów na hoście, a proxy łączy się z nimi po wewnętrznej sieci Dockera, po nazwie kontenera. Jest to czystsze i bezpieczniejsze.

Aktualizacje i przypinanie wersji

Tag latest kusi, ale przy docker compose pull && docker compose up -d możesz z dnia na dzień wciągnąć zmianę łamiącą zgodność. Dla usług, na których ci zależy (menedżer haseł, zdjęcia), przypnij konkretną wersję (numer poniżej jest przykładowy):

    image: vaultwarden/server:1.32.0

Aktualizuj świadomie, po przeczytaniu changelogu. Do automatyzacji reszty służy Watchtower, ale nie polecam go przy krytycznych stackach: automatyczna aktualizacja menedżera haseł o trzeciej w nocy to przepis na nieprzespaną noc. Poza tym repozytorium Watchtowera jest zarchiwizowane (stan na 2026-10-10), więc nie dostaje już poprawek.

Backup wolumenów

Kontener da się odtworzyć z obrazu, więc cała wartość leży w wolumenach i plikach compose. Skoro trzymasz wszystko w /volume1/docker, dopisz ten folder do zadania Hyper Backup. Jak ułożyć takie kopie tak, żeby przetrwały ransomware, opisuje wpis o backupie 3-2-1.

Jeden warunek: bazy danych (PostgreSQL, MariaDB) źle znoszą kopiowanie plików „na gorąco”. Dla Paperless czy Immich, które trzymają dane w Postgresie, zrób krótki docker compose stop na czas kopii albo dodaj kontener robiący pg_dump do pliku, który trafia do backupu.

Reguły na start

1. Jeden folder na stack, konfiguracja w docker-compose.yml, dane obok.
2. Realne UID/GID z Twojego systemu zamiast 1000 z tutoriala.
3. Reverse proxy zamiast portów hosta: wbudowany w DSM albo Nginx Proxy Manager.
4. Przypięte wersje krytycznych obrazów i świadome aktualizacje.
5. Backup wolumenów przez Hyper Backup, z uwagą na bazy danych.

Container Manager to dobra baza do domowego self-hostingu, jeśli traktujesz go jak infrastrukturę: z plikami konfiguracji, przypiętymi wersjami i kopią zapasową. Trochę dyscypliny na starcie zwraca się przy pierwszej migracji albo awarii dysku.