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 odkryłeś, że możesz na nim postawić pół domowej infrastruktury. Vaultwarden, Pi-hole, Paperless-ngx, Immich, Home Assistant — wszystko to jednak działa w kontenerach. I tu zaczynają się schody, bo klikanie każdego kontenera z osobna w GUI szybko robi się nie do utrzymania.

W tym wpisie pokażę, jak podejść do tego tak, żeby po pół roku dało się to jeszcze ogarnąć.

Container Manager to Docker — nie bójmy się tego słowa

Synology w DSM 7.2 przemianowało „Docker" na „Container Manager", ale pod spodem to nadal Docker plus Docker Compose. Dobra wiadomość: możesz kompletnie zignorować kreator GUI i pracować tak, jak na normalnym serwerze.

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

sudo docker version
sudo docker compose version

Compose jest w wersji plugin (docker compose, nie docker-compose), więc trzymaj się tej składni.

Zasada numer jeden: jeden folder na stack, wszystko 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 sobie 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 = backup całego twojego self-hostingu. Migracja na nowego NAS-a = skopiowanie folderu i docker compose up -d.

Przykład — Vaultwarden, mój ulubiony „pierwszy kontener" dla każdego:

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 w GUI i tak pokaże ten kontener — możesz go stamtąd monitorować, ale źródłem prawdy jest plik.

Uważaj na UID/PUID i uprawnienia

To jest miejsce, w którym ludzie tracą wieczory. Synology nie nadaje twojemu użytkownikowi UID 1000, jak większość poradników z internetu zakłada. Sprawdź swój:

id twoj_uzytkownik

Dostaniesz coś w stylu uid=1026 gid=100(users). Obrazy typu LinuxServer.io (lscr.io/linuxserver/...) przyjmują zmienne PUID i PGID — wpisz tam realne wartości ze swojego systemu, bo inaczej kontener nie zapisze do wolumenu albo zrobi 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 pamiętanie tych numerów. Po pięciu kontenerach jest to chaos i dziura bezpieczeństwa, bo każdy port siedzi na IP NAS-a.

Lepsze podejście: reverse proxy. DSM ma wbudowany reverse proxy (Panel sterowania → Portal aplikacji → Reverse Proxy), który potrafi wystawić kontener pod ładnym adresem https://paperless.twojadomena.pl i doszyć certyfikat Let's Encrypt.

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, kontener nie wie nic o HTTPS

Jeśli chcesz więcej kontroli (a docelowo chcesz), rozważ osobny kontener z Nginx Proxy Manager albo Traefik i wspięcie kontenerów wspólną siecią Docker zamiast portami hosta:

networks:
  proxy:
    external: true

Wtedy aplikacje w ogóle nie publikują portów na hoście — proxy komunikuje się z nimi po wewnętrznej sieci Dockera po nazwie kontenera. Znacznie czyściej i bezpieczniej.

Aktualizacje: latest to wygoda, nie strategia

Tag image: something:latest jest kuszący, ale przy docker compose pull && docker compose up -d możesz z dnia na dzień wciągnąć breaking change. Dla usług, na których ci zależy (menedżer haseł, zdjęcia), przypnij konkretną wersję:

    image: vaultwarden/server:1.32.0

Aktualizuj świadomie, po zerknięciu w changelog. Do automatyzacji reszty można użyć Watchtower, ale osobiście trzymałbym go z dala od krytycznych stacków — automatyczny update menedżera haseł o 3 w nocy to przepis na nieprzespaną noc.

Backup, o którym wszyscy zapominają

Kontenery są bezstanowe — cała wartość jest w wolumenach. Skoro trzymasz wszystko w /volume1/docker, dopisz ten folder do zadania Hyper Backup. Jeden warunek: bazy danych (PostgreSQL, MariaDB) nie lubią, gdy kopiuje się ich pliki „na gorąco". Dla Paperless czy Immich, które trzymają dane w Postgresie, zrób albo krótki docker compose stop na czas snapshotu, albo dorzuć kontener robiący pg_dump do pliku, który backupujesz.

Podsumowanie

Reguły, które oszczędzą ci nerwów:

1. Jeden folder = jeden stack, konfiguracja w docker-compose.yml, dane obok.
2. Sprawdź realne UID/GID zamiast wklejać 1000 z tutoriala.
3. Reverse proxy zamiast portów hosta — wbudowany w DSM albo Nginx Proxy Manager.
4. Przypnij wersje krytycznych obrazów, aktualizuj świadomie.
5. Backup wolumenów przez Hyper Backup, z uwagą na bazy danych.

Container Manager na Synology to naprawdę solidna baza do domowego self-hostingu — pod warunkiem, że potraktujesz go jak infrastrukturę, a nie jak zabawkę do klikania. Trochę dyscypliny na starcie zwraca się przy pierwszej migracji albo awarii dysku.