Immich-Self-Hosting-Benchmarks zeigen hohen RAM-Bedarf und kritische Backup-Anforderungen

Self-Hosting-Enthusiasten, die Google Photos durch Immich ersetzen möchten, stehen vor erheblichen Hardware- und Betriebskompromissen, wie eine kürzlich veröffentlichte Deployment-Analyse vom 30. Oktober 2026 aufzeigt. Der Testbericht hebt hervor, dass die Open-Source-Plattform zwar leistungsstarke Machine-Learning-Funktionen bietet, aber deutlich mehr Systemressourcen als typische leichtgewichtige Self-Hosted-Anwendungen verlangt. Nutzer müssen sich auf ein komplexes Setup mit mehreren Containern, strengen Passwortrichtlinien und rigorosen Backup-Prozeduren vorbereiten, um Datenverluste zu vermeiden.

Was passiert ist

Der Autor stellte Immich Version 3 auf einer Workstation bereit, die mit einem Intel Core Ultra 7 255H Prozessor, 30 GB RAM und NVMe-Speicher unter Ubuntu 24.04.5 LTS ausgestattet war. Das Ziel bestand darin, den tatsächlichen Ressourcenverbrauch des Stacks zu messen, der den Hauptserver, einen Machine-Learning-Dienst, VectorChord für Postgres und Valkey umfasst. Im Gegensatz zu einfacheren Tools wie Vaultwarden oder Uptime Kuma, die im Bereich weniger Megabyte Speicher laufen, erwies sich Immich als ressourcenhungrige Anwendung. Der gemessene Working Set pendelte sich bei etwa 2,4 GB RAM ein, mit spürbaren Spitzen während der Machine-Learning-Verarbeitungsaufgaben wie Thumbnail-Erstellung und Embedding-Generierung.

Neben dem reinen Ressourcenverbrauch offenbarte das Deployment mehrere betriebliche Fallstricke, die die Installation brechen oder die Sicherheit gefährden können. Der Autor merkte an, dass sich die Docker Compose-Datei aufgrund des schnellen Entwicklungszyklus des Projekts zwischen den Releases häufig ändert. Ein einfaches Pullen neuer Images ohne Aktualisierung der Compose-Konfiguration kann zu Fehlern führen. Darüber hinaus ist die Datenbankkomponente nicht wegwerfbar; sie enthält alle Metadaten, Alben, Gesichtserkennungsdaten und Bearbeitungshistorien. Dies macht regelmäßige Backups sowohl des Bibliotheksordners als auch eines Postgres-Dumps vor dem Import großer Fotosammlungen unerlässlich.

Wichtige Details

• Speicheranforderungen: Der Stack benötigt mindestens 4 GB freien RAM für zuverlässiges Funktionieren, mit einer Grundauslastung von etwa 2,4 GB und höheren Spitzen während ML-Aufgaben.
• Datenbankkomplexität: Postgres speichert kritische Metadaten und darf nicht als ephemeral behandelt werden; Nutzer müssen sowohl den Datenbank-Dump als auch den Bibliotheksordner sichern.
• Passwortbeschränkungen: Sonderzeichen in der Umgebungsvariable DB_PASSWORD brechen die Verbindungszeichenkette, was alphanumerische Passwörter trotz standardmäßiger Warnungen erforderlich macht.
• Konfigurationsvolatilität: Die offizielle Docker Compose-Datei wird häufig aktualisiert, was einen erneuten Download bei jedem Upgrade erfordert, anstatt nur neue Container-Images zu pullen.
• Netzwerksicherheit: Mobile Backup-Funktionen erfordern HTTPS über einen Reverse Proxy oder einen sicheren Tunnel wie Tailscale, da die direkte Exposition des Dienstes im Internet unsicher ist.
• Optionale Dienste: Der Machine-Learning-Dienst kann für schwächere Hardware entfernt werden, wobei dies jedoch Smart Search- und Gesichtserkennungsfunktionen deaktiviert.

Hintergrund

Immich hat sich als Self-Hosted-Alternative zu Google Photos großer Beliebtheit erfreut und verzeichnet über 115.000 GitHub-Stars. Es bietet mobile Apps mit automatischer Backup-Funktionalität und nutzt maschinelles Lernen, um die Suche in natürlicher Sprache zu ermöglichen, beispielsweise das Finden von Fotos durch die Beschreibung "Sonnenuntergang über Wasser". Diese Funktionalität beruht auf der Generierung von Embeddings für Bilder, einem Prozess, der im Vergleich zur einfachen Dateispeicherung rechenintensiv ist. Während viele Self-Hosted-Tools darauf ausgelegt sind, auf minimalen virtuellen privaten Servern zu laufen, spiegelt Immichs Architektur die ressourcenintensive Natur kommerzieller Cloud-Dienste wider und verlagert die Kosten von Abonnementgebühren auf lokale Hardwarekapazitäten.

Die Unterscheidung zwischen einem Galerie-Viewer und einer vollständigen Backup-Lösung ist in diesem Kontext entscheidend. Google Photos bot Langlebigkeit und Off-Site-Redundanz, während eine self-hosted Immich-Instanz einen Single Point of Failure darstellt, es sei denn, sie wird ordnungsgemäß gesichert. Die "3-2-1"-Backup-Regel – drei Kopien der Daten auf zwei verschiedenen Medien halten, davon eine off-site – gilt hier streng. Ohne ein Off-Site-Backup der Datenbank und Bibliothek ist der Server lediglich eine zweite Kopie der Daten auf Hardware, die der Nutzer verwaltet, und kein echtes Sicherheitsnetz gegen Hardwareausfälle oder Ransomware.

Warum es wichtig ist

Für IT-Leiter und Entwickler, die kleine Infrastrukturen verwalten, ist es vital, die wahren Kosten des Self-Hostings komplexer Anwendungen zu verstehen. Immich demonstriert, dass "kostenlose" Software oft versteckte Kosten in Bezug auf Hardwarespezifikationen und Wartungsaufwand mit sich bringt. Ein Standard-1-GB-VPS oder eine Free-Tier-PaaS-Option ist für diese Last unzureichend. Teams, die solche Migrationen in Betracht ziehen, müssen bewerten, ob ihre vorhandene Hardware, wie z. B. eine Oracle-Free-VM mit 12 GB RAM, die kontinuierliche Last der Hintergrund-ML-Verarbeitung und Datenbankoperationen bewältigen kann.

Darüber hinaus übersteigt die für Immich erforderliche betriebliche Disziplin diejenige für einfachere zustandslose Anwendungen. Die Notwendigkeit, Datenbankschemas zu verwalten, Breaking Changes in Konfigurationsdateien zu handhaben und Fernzugriffskanäle abzusichern, erhöht den administrativen Aufwand. Für Organisationen oder Einzelpersonen mit intermittierender Verfügbarkeit ihrer Home Labs steigt das Risiko von Datensynchronisationsfehlern. Wenn der Server offline ist, wenn mobile Geräte versuchen zu synchronisieren, wird der Nutzen des Backups zunichte gemacht. Dies macht Immich nur für Always-On-Umgebungen mit robuster Stromversorgung und Netzwerkkonnektivität geeignet.

Was Sie tun können

• Hardware-Ressourcen prüfen: Stellen Sie sicher, dass Ihr Server über mindestens 4 GB freien RAM und ausreichend NVMe-Speicher verfügt, bevor Sie mit dem Deployment beginnen.

• Strenge Backups implementieren: Konfigurieren Sie automatisierte Skripte, die sowohl pg_dump-Operationen als auch Datei-Level-Backups des Bibliotheksordners an einen Off-Site-Speicherort durchführen.

• Fernzugriff absichern: Verwenden Sie einen Reverse Proxy mit gültigen TLS-Zertifikaten oder ein Mesh-Network-Tool wie Tailscale, um mobile Backups zu ermöglichen, ohne Ports dem öffentlichen Internet auszusetzen.

• Upgrade-Protokolle befolgen: Laden Sie beim Upgrade immer die neueste offizielle Docker Compose-Datei vom spezifischen Release-Tag herunter, anstatt sich auf gecachte Konfigurationen zu verlassen.

• Zugangsdaten validieren: Verwenden Sie nur alphanumerische Zeichen für Datenbankpasswörter, um Parsing-Fehler der Verbindungszeichenkette während der Ersteinrichtung zu vermeiden.

• Skalierung nach unten in Betracht ziehen: Wenn Sie auf begrenzter Hardware arbeiten, deaktivieren Sie den Machine-Learning-Dienst, um den RAM-Verbrauch zu reduzieren, und akzeptieren Sie den Verlust der Smart-Search-Fähigkeiten.