Immich ist die selbstgehostete Antwort auf Google Fotos: Ihr Server, Ihre Platten, eine mobile App, die Ihre Kamerarolle sichert. Die Installation liest sich, als dauerte sie fünf Minuten, und mechanisch stimmt das auch. Die Entscheidungen darüber, ob Sie Ihre Fotos in drei Jahren noch haben, fallen allesamt in der Datei, die Sie vorher bearbeiten.
Was die offizielle Installation tatsächlich ist
Zwei Downloads und ein Befehl. Die Dokumentation nennt sie wörtlich:
wget -O docker-compose.yml https://github.com/immich-app/immich/releases/latest/download/docker-compose.yml
wget -O .env https://github.com/immich-app/immich/releases/latest/download/example.env
Achten Sie auf die Asymmetrie der zweiten Zeile: Die Datei wird als example.env veröffentlicht und von Ihnen als .env gespeichert. Sind die Variablen dann ausgefüllt, schrumpft die gesamte Installation auf docker compose up -d.
Scheitert dieser letzte Befehl, benennt die Dokumentation die übliche Ursache, bevor Sie suchen müssen. Sie warnt, dass bei einem Fehler wie unknown shorthand flag: 'd' in -d vermutlich die falsche Docker-Version läuft und die korrekte Form docker compose mit Leerzeichen statt der älteren Binärdatei docker-compose ist. Getrennt davon weist sie auf eine zweite Versionsfalle hin: einen Fehler mit dem Wortlaut can't set healthcheck.start_interval as feature require Docker Engine v25 or later, den sie durch Auskommentieren dieser Zeile umgehen lässt.
Beides sind Versionsabweichungen, keine Fehler in Ihrer Datei. Keiner davon ist einen Abend wert.
Die zwei Orte, die über Ihre Wiederherstellbarkeit entscheiden
Die Compose-Datei ist kurz, aber zwei ihrer Variablen sind keine austauschbaren Einstellungen. Sie sind die Antwort auf „was sichere ich" und „was korrumpiert sich von selbst".
UPLOAD_LOCATION wird in der Dokumentation als der Ort beschrieben, an dem Ihre hochgeladenen Dateien gespeichert werden, mit der Aufforderung, dort den bevorzugten Speicherort für diese Daten einzutragen. Das ist das Verzeichnis, das jedes hochgeladene Foto aufnehmen wird. Es beiläufig zu wählen ist der häufigste Weg zu einer Mediathek, die außerhalb aller bereits laufenden Sicherungen liegt.
DB_DATA_LOCATION ist die Datenbank, und die Dokumentation knüpft daran eine harte Bedingung: Netzwerkfreigaben werden für die Datenbank nicht unterstützt. Das ist keine Performance-Empfehlung. Datenbank-Engines stützen sich auf Sperr- und Schreibreihenfolge-Garantien, die Netzwerkdateisysteme uneinheitlich liefern, und der Fehlerfall ist meist eine stille Korruption, die Wochen später auffällt, nicht eine Startverweigerung.
Praktisch gelesen: Ihre Fotomediathek darf auf Netzwerkspeicher liegen, wenn Sie hinnehmen, dass sie langsamer wird. Das Datenbankverzeichnis bleibt auf einer lokalen Platte. Und was auch immer Sie für das erste wählen, notieren Sie es, denn es ist der Pfad, den Ihre Sicherungen einschließen müssen.
Der Hinweis, den das Projekt auf seine eigene Startseite setzt
Die meisten Selbsthosting-Anleitungen übergehen ihn, deshalb lohnt es sich, das Projekt zu zitieren statt es zu paraphrasieren. Das Immich-Repository trägt ganz oben die Zeile: « Always follow 3-2-1 backup plan for your precious photos and videos! »
Dieser Hinweis tut etwas Bestimmtes. Er sagt nicht, die Software sei unzuverlässig. Er sagt, dass ein eigener Fotoserver für sich genommen kein Backup ist, und wer ihn geschrieben hat, weiß, dass Selbsthoster regelmäßig das Gegenteil glauben. Eine einzelne Instanz auf einer einzelnen Maschine hält genau eine Kopie Ihrer Mediathek. Eine ausfallende Platte, ein verpfuschtes Update, eine versehentliche Löschung oder ein vertippter Pfad lässt sie verschwinden, und es gibt keinen Anbieter, den man danach fragen könnte.
Das Projekt steht unter AGPL-3.0, was mit ein Grund ist, dass Sie es prüfen und betreiben können. An der Arithmetik einer einzigen Kopie ändert das nichts.
Was Selbsthosting verschiebt, und was nicht
Selbsthosting wird oft schlicht als die private Option dargestellt. Genauer und nützlicher ist: Es verschiebt das Vertrauen, statt es abzuschaffen.
Was sich wirklich ändert: Kein Unternehmen besitzt Ihre Mediathek, kein Anbieter kann rechtlich zur Herausgabe gezwungen werden, keine Nutzungsbedingung ändert sich hinter Ihrem Rücken, und es gibt kein Konto zu verlieren. Für viele ist genau das der Sinn der Sache, und der Gewinn ist echt.
Was sich nicht von selbst ändert: Verschlüsselung im Ruhezustand auf Ihren eigenen Platten, die physische Sicherheit der Maschine, das Aktuellhalten und das Vorhandensein von mehr als einer Kopie. All das wird in dem Moment zu Ihrer Aufgabe, in dem Sie es einem Anbieter abnehmen. Das ist der Handel, und es ist vernünftig, ihn wissentlich einzugehen. Deutlich weniger vernünftig ist es, ihn versehentlich einzugehen, weil man selbstgehostet für geschützt gehalten hat.
Private Fotomediathek ohne eigenen Server? pCloud lebenslang + Crypto
Schweizer Rechtsraum · Zero-Knowledge mit dem Crypto-Zusatz · Einmalzahlung, keine Updates zu verfolgen und keine Datenbank zu sichern
Ehrlich zwischen beiden wählen
Hosten Sie Immich selbst, wenn Sie Ihre Fotos auf Hardware wollen, die Sie kontrollieren, wenn Sie Sicherungen und Updates übernehmen möchten und die Wartung Sie interessiert, statt Ihnen in acht Monaten zur Last zu fallen.
Nehmen Sie einen verwalteten Zero-Knowledge-Dienst, wenn Sie eigentlich nur wollten, dass kein Unternehmen Ihre Fotos lesen kann, ohne die Person zu werden, die einspringt, wenn die Platte ausfällt. Dieses Ergebnis gibt es ohne Server, und es zu wählen ist kein Verzicht bei der Privatsphäre, sondern eine andere Verteilung derselben Arbeit.
Die einzige Antwort, die dem Alltag nicht standhält, ist eine einzelne selbstgehostete Instanz ohne zweite Kopie. Genau deshalb sagt das Projekt es selbst, bevor Sie überhaupt etwas installieren.
Die Installationsbefehle, der Hinweis, dass die Umgebungsdatei als example.env veröffentlicht wird, die Beschreibungen von UPLOAD_LOCATION und DB_DATA_LOCATION, die Aussage, dass Netzwerkfreigaben für die Datenbank nicht unterstützt werden, und die beiden Docker-Versionsfehler stammen aus der offiziellen Immich-Dokumentation zur Installation per Docker Compose. Die 3-2-1-Backup-Zeile und die AGPL-3.0-Lizenz stammen von der Startseite des Projekt-Repositoriums. Die Zitate stehen in ihrer Originalsprache. Beide Quellen wurden zum Zeitpunkt der Abfassung geprüft; prüfen Sie gegen die Version, die Sie installieren, da die Compose-Datei mit jedem Release ausgeliefert wird. Kommerzielle Links tragen das Attribut rel="sponsored nofollow"; eine Affiliate-Provision kann anfallen, ohne Mehrkosten für Sie.
Verwandte Leitfäden
- Bester Cloud-Speicher für Fotos - die verwaltete Seite derselben Frage, samt der Dienste, die Fotos clientseitig verschlüsseln.
- Selbstgehosteter Cloud-Speicher - derselbe Handel, angewandt auf Dateien statt Fotos, mit Nextcloud, Seafile und ownCloud.
Häufig gestellte Fragen
- Was muss man wirklich herunterladen, um Immich zu installieren?
- Zwei Dateien, die mit jeder Version veröffentlicht werden. Die Dokumentation nennt die Befehle wörtlich: wget -O docker-compose.yml https://github.com/immich-app/immich/releases/latest/download/docker-compose.yml und wget -O .env https://github.com/immich-app/immich/releases/latest/download/example.env. Beachten Sie, dass die zweite Datei als example.env veröffentlicht wird und Sie sie als .env speichern. Sind die Variablen ausgefüllt, besteht die gesamte Installation aus einem Befehl: docker compose up -d.
- Warum scheitert mein docker-compose-Befehl an einer unbekannten Option?
- Sie verwenden mit hoher Wahrscheinlichkeit die alte eigenständige Binärdatei statt des Plugins. Die Dokumentation behandelt diesen Fall ausdrücklich: Wenn Sie einen Fehler wie unknown shorthand flag 'd' in -d erhalten, läuft vermutlich die falsche Docker-Version, und der korrekte Befehl lautet docker compose mit Leerzeichen, nicht docker-compose mit Bindestrich. Sie nennt getrennt davon eine zweite Versionsfalle: einen Fehler, wonach healthcheck.start_interval Docker Engine v25 oder neuer voraussetzt, den sie durch Auskommentieren dieser Zeile umgehen lässt.
- Wo landen meine Fotos tatsächlich auf der Platte?
- Dort, wohin UPLOAD_LOCATION zeigt. Die Dokumentation beschreibt es als den Ort, an dem Ihre hochgeladenen Dateien gespeichert werden, und fordert Sie auf, dort den von Ihnen bevorzugten Speicherort für diese Daten einzutragen. Es ist die folgenreichste Zeile der Datei, denn sie entscheidet, welches Verzeichnis Sie sichern müssen. Setzen Sie sie bewusst auf einen Pfad, den Sie ohnehin schon schützen, statt einen Standardwert zu übernehmen und später festzustellen, dass Ihre Fotomediathek an einer Stelle liegt, in die Ihre Sicherungen nie schauen.
- Darf die Datenbank auf mein NAS?
- Die Datenbank nicht. Die Dokumentation sagt es für DB_DATA_LOCATION unmissverständlich: Netzwerkfreigaben werden für die Datenbank nicht unterstützt. Datenbanken brauchen Dateisperren auf niedriger Ebene, die Netzwerkdateisysteme nicht zuverlässig liefern, und wer das ignoriert, erhält in der Regel Korruption statt einer sauberen Fehlermeldung. Ihre Fotomediathek darf auf Netzwerkspeicher liegen, wenn Sie die Geschwindigkeitseinbuße hinnehmen; das Verzeichnis der Datenbank bleibt auf einer lokalen Platte.
- Reicht Selbsthosting von Immich, um meine Fotos zu sichern?
- Das Projekt selbst sagt nein, und es sagt es auf seiner eigenen Startseite: Befolgen Sie für Ihre wertvollen Fotos und Videos stets einen 3-2-1-Sicherungsplan. Den Server selbst zu betreiben ändert, wer Ihre Mediathek besitzt, es erzeugt keine zweite Kopie davon. Eine selbstgehostete Instanz auf einer einzigen Maschine ist einen Plattenausfall, ein misslungenes Update oder eine versehentliche Löschung vom Totalverlust entfernt, und genau dagegen existiert die 3-2-1-Regel.
Erhalten Sie pCloud
10-tägige Geld-zurück-Garantie
