← Tutti gli articoli

Synology DSM 7.2 e Docker: cosa funziona davvero (e cosa no)

12 February 20242 min di lettura

Container Manager ha sostituito Docker. Cosa abbiamo imparato gestendo 12 stack su DSM nei nostri clienti.

Con DSM 7.2 Synology ha rinominato il pacchetto Docker in Container Manager. Più di un rebrand: cambia la UI, migliora il supporto a Docker Compose, e chiude alcuni vecchi bug del package precedente.

Compose finalmente di prima classe

Container Manager ora ha un editor Compose dedicato dove incollare un docker-compose.yml, validare e applicare. Per gli stack che self-hostiamo per i clienti — Vaultwarden, Plausible, n8n, NocoDB — è la differenza tra "lo metto su" e "lo metto su in pace".

Networking: il punto delicato

Le reti Docker su DSM sono separate dalla rete del NAS. Se vuoi che un container raggiunga un'altra macchina nella stessa LAN del NAS, devi usare network_mode: host o creare una macvlan dedicata. La macvlan è più pulita ma richiede attenzione alle subnet.

Persistenza: volumi vs bind mount

Su Synology consigliamo sempre bind mount a un percorso Btrfs (es. /volume1/docker/<servizio>) e non i volumi Docker nativi. Motivo: gli snapshot Btrfs proteggono i dati al pari del resto del NAS. I volumi nativi vivono in una zona meno facile da snapshottare.

Aggiornamenti automatici

Container Manager non ha auto-update integrato. Per gli stack critici usiamo Watchtower con scheduling settimanale e notifica via webhook. Per gli stack di produzione di un cliente, mai auto-update silenzioso — sempre con review.

Limiti reali

  • Niente Docker Swarm (esiste su Synology in modo non ufficiale).
  • Niente Kubernetes su Synology — se serve, è il momento di un VPS.
  • RAM limitata sui modelli J/value: container troppo grossi (Postgres + Redis + app) saturano in fretta. Su DS923+/DS1522+ (4-8 GB+) si lavora bene.

Per il 90% dei nostri scenari self-hosting su NAS, DSM 7.2 + Container Manager basta e avanza.