Immich selbst hosten: Google Fotos ersetzen

Google Fotos ist bequem, kostet nichts und rechnet dafür mit euren Bildern — und irgendwann steht die Frage im Raum, ob die Familienalben der letzten fünfzehn Jahre wirklich bei einem Werbekonzern liegen müssen. Immich selbst hosten ist der Weg, der diese Frage praktisch beantwortet: ein Foto- und Videoserver auf eigener Hardware, mit Apps für Android und iOS, automatischem Upload vom Telefon, Gesichtserkennung und Volltextsuche, die den Rechner im Keller beschäftigen und nicht ein Rechenzentrum in Iowa.

Diese Anleitung führt von der leeren Maschine bis zur übernommenen Google-Mediathek: Voraussetzungen, Installation mit Docker Compose, die Einstellungen des ersten Tages, der Import eines Google-Takeout-Archivs ohne Datenverlust, der Zugriff von aussen und die Sicherung. Wer Immich nur ausprobieren will, findet auf yourdevice.ch eine laufende Immich-Instanz als kostenlosen Dienst. Und wer seine Bilder schon in einer Nextcloud hat, wirft vorher einen Blick auf Memories als Foto-App für Nextcloud — manchmal ist die kleinere Lösung die richtige.

Immich selbst hosten: was ihr bekommt, und was ihr nicht bekommt

Immich ist eine Galerie mit Server: Die Bilder liegen als gewöhnliche Dateien auf einer Festplatte, die Metadaten in einer Postgres-Datenbank, darüber sitzt eine Weboberfläche nach dem Vorbild von Google Fotos — Zeitleiste, Alben, Karte, Personen, Suche nach Bildinhalten. Die mobilen Apps laden neue Aufnahmen automatisch hoch, und das ist der eigentliche Grund, warum so ein Aufbau im Alltag durchhält. Ein Foto-Archiv, das Handarbeit verlangt, wird nach drei Wochen nicht mehr befüllt.

Was Immich ausdrücklich nicht ist: eine Sicherung. Die Projektdokumentation ist an dieser Stelle unmissverständlich und schreibt zum Pilotbetrieb der eigenen Datenbanksicherung: „The database only contains metadata and user information. You must setup manual backups of the images and videos stored in UPLOAD_LOCATION.“ Immich selbst empfiehlt in seiner Anleitung zu Sicherung und Wiederherstellung eine 3-2-1-Strategie. Wer die einzige Kopie seiner Familienfotos in einen Dienst schiebt, den er gerade selbst zusammengesteckt hat, hat kein Archiv, sondern ein Hobby mit Risiko.

Aktuell ist die Reihe 3.x: Version 3.0.0 erschien am 1. Juli 2026, die jüngste Fassung 3.2.0 am 10. September 2026. Mit 3.0 hat sich die Mindestanforderung an den Prozessor geändert, und die Versionsnummer steht in der Konfigurationsdatei, die ihr gleich anlegt.

Was die Maschine mitbringen muss

Die Anforderungsseite des Projekts nennt konkrete Zahlen, und sie sind ernst gemeint. Als Betriebssystem empfiehlt das Projekt „Linux or *nix 64-bit operating system (Ubuntu, Debian, etc)“; Windows und macOS gelten wegen der schwächeren Docker-Unterstützung als Notlösung. Beim Speicher stehen „Minimum 6GB, recommended 8GB“ — mit 4 GB läuft Immich nur dann, wenn das maschinelle Lernen abgeschaltet ist. Beim Prozessor sind es „Minimum 2 cores, recommended 4 cores“.

Zwei Punkte werden regelmässig übersehen. Erstens verlangt Immich ab Version 3 auf amd64 die Mikroarchitektur x86-64-v2 — das betrifft nur Rechner, die älter als etwa 2012 sind, aber wer einen ausgemusterten Bürorechner zum Fotoserver machen wollte, prüft das vorher. Zweitens gehört das Datenverzeichnis der Datenbank auf lokalen Speicher, am besten auf eine SSD: Netzwerkfreigaben sind nicht unterstützt. Das Dateisystem muss Benutzer- und Gruppenrechte kennen; NTFS und alles aus der FAT-Familie fallen damit aus.

Beim Platzbedarf rechnet ihr mit einem Zuschlag: Vorschaubilder und umgewandelte Videos lassen die Mediathek laut Dokumentation um 10 bis 20 Prozent wachsen. Bei 400 GB Bildern sind das bis zu 80 GB, die niemand einplant und die dann mitten im ersten Import die Platte füllen.

Die vier Container, aus denen Immich besteht

Immich wird nicht als ein Programm installiert, sondern als vier zusammenarbeitende Container. Der Blick in die offizielle docker-compose.yml zeigt, wer welche Aufgabe hat:

• immich-server — die Anwendung selbst, samt Weboberfläche und Schnittstelle. Sie ist das einzige Element, das einen Port nach draussen öffnet: 2283. Eingebunden ist genau ein Verzeichnis, nämlich UPLOAD_LOCATION als /data.
• immich-machine-learning — Gesichtserkennung, Objekterkennung und die Suche nach Bildinhalten. Dieser Container hält keine Nutzerdaten, sondern nur die heruntergeladenen Modelle im Volume model-cache. Er ist derjenige, der den Arbeitsspeicher frisst.
• redis — die Warteschlange für Hintergrundaufträge. Der Dienst heisst weiterhin so, das Abbild ist inzwischen aber valkey, der freie Abzweig von Redis nach dessen Lizenzwechsel.
• database — Postgres, allerdings kein gewöhnliches: Das Abbild trägt den Namen postgres:14-vectorchord… und bringt die Vektor-Erweiterungen mit, ohne die es keine Ähnlichkeitssuche und keine Gesichtsgruppierung gibt. Deshalb lässt sich hier auch nicht einfach ein bestehender Postgres-Server aus dem Netz verwenden.

Diese Aufteilung ist der Grund, warum die Sicherung später aus zwei Teilen besteht — und warum die Frage, welcher Teil des Aufbaus ersetzbar ist, vor dem ersten Import geklärt sein sollte.

Immich installieren: zwei Dateien, ein Befehl

Voraussetzung ist Docker samt Compose-Erweiterung aus dem offiziellen Docker-Repository, nicht aus den Distributionspaketen — das Projekt weist ausdrücklich darauf hin, dass Fehler beim Start meist daran liegen. Wie die Einrichtung unter Debian, Ubuntu und Linux Mint abläuft, steht in unserem Beitrag zu den Docker-Grundlagen und der Installation. Wichtig ist ausserdem die Schreibweise: docker compose mit Leerzeichen. Das alte docker-compose mit Bindestrich wird nicht mehr unterstützt.

Legt ein eigenes Verzeichnis an und holt die beiden Dateien, die das Projekt für jede Version bereitstellt:

mkdir -p /opt/immich && cd /opt/immich
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

Die docker-compose.yml bleibt unangetastet. Bearbeitet wird nur die .env, und dort genügen fünf Zeilen:

UPLOAD_LOCATION=/srv/immich/library
DB_DATA_LOCATION=/srv/immich/postgres
IMMICH_VERSION=v3
DB_PASSWORD=EinLangesPasswortOhneSonderzeichen
TZ=Europe/Zurich

UPLOAD_LOCATION ist das Verzeichnis, in dem später alle Originale liegen. Es darf auf einer grossen Platte oder einem eingebundenen Speicher liegen. DB_DATA_LOCATION ist das Datenverzeichnis von Postgres und gehört, wie oben beschrieben, auf lokalen Speicher. Beide Pfade werden nach dem ersten Start nicht mehr geändert, ohne die Datenbank umzuziehen.

Bei DB_PASSWORD gilt eine Einschränkung, die in der Dokumentation nur als Nebensatz steht und trotzdem Installationen zerlegt: erlaubt sind ausschliesslich die Zeichen A–Z, a–z und 0–9. Ein Passwort mit Dollarzeichen oder Klammern führt zu einer Datenbank, die nicht startet, und zu einer Fehlermeldung, die das Problem nicht nennt. Nehmt eine lange Folge aus Buchstaben und Zahlen.

IMMICH_VERSION steht in der Beispieldatei auf v3. Das ist ein mitwachsendes Kennzeichen: Bei jedem docker compose pull kommt die neueste Fassung der Reihe 3.x. Wer das nicht will, schreibt eine feste Version hinein, etwa v3.2.0. Für den ersten Aufbau ist v3 richtig; sobald der Server ernsthaft benutzt wird, ist eine feste Version die ruhigere Variante.

Danach folgt der eigentliche Start:

docker compose up -d
docker compose logs -f immich-server

Der erste Start dauert länger als erwartet, weil die Datenbank ihr Schema anlegt und der Lerndienst seine Modelle herunterlädt. Erscheint eine Fehlermeldung zu start_interval im Abschnitt der Datenbank, läuft auf der Maschine eine Docker-Engine älter als Version 25; dann wird diese Zeile auskommentiert.

Der erste Aufruf und das Administratorkonto

Die Oberfläche erreicht ihr unter http://<IP-der-Maschine>:2283. Dort führt die Schaltfläche Getting Started zur Registrierung. Entscheidend ist der Satz aus der Dokumentation: „The first user to register will be the admin user.“ Wer den Port erreichbar macht, bevor er sich selbst registriert hat, verschenkt sein Administratorkonto an den ersten Besucher. Registriert euch also zuerst, und öffnet erst danach den Zugang von aussen.

Weitere Konten für Familie oder Mitbewohner legt ihr unter Administration > Users an. Ein vergessenes Administratorpasswort lässt sich laut FAQ über den Befehl reset-admin-password im Container immich-server zurücksetzen.

Die Einstellungen, die vor dem ersten Import gehören

Das Speicher-Template

Unter Administration > Settings > Storage Template legt ihr fest, wie Immich die Dateien auf der Platte ablegt. Die Vorgabe lautet Year/Year-Month-Day/Filename.Extension, die Funktion muss aber erst eingeschaltet werden. Der Sinn dahinter ist Unabhängigkeit: Eine nach Jahr und Datum sortierte Ordnerstruktur bleibt auch dann lesbar, wenn Immich eines Tages nicht mehr startet. Ohne Template liegen die Dateien unter technischen Kennungen, die ohne Datenbank nichts aussagen.

Ändert ihr das Template später, gilt es zunächst nur für neue Dateien; ein eigener Wartungsauftrag überträgt es auf den Bestand. Es ist trotzdem angenehmer, das vor dem Import der ersten 40'000 Bilder zu entscheiden.

Maschinelles Lernen dosieren oder abschalten

Gesichtserkennung und Inhaltssuche sind der Teil, der Rechenzeit und Arbeitsspeicher verlangt. Die FAQ beschreibt zwei Stufen: „Machine learning can be disabled under Administration > Settings > Machine Learning Settings, either entirely or by model type.“ Damit laufen keine Aufträge mehr — der Container startet aber weiterhin und belegt Speicher. Wer ihn ganz loswerden will, kommentiert den Abschnitt immich-machine-learning in der docker-compose.yml aus.

Bei 4 GB Arbeitsspeicher ist das der Unterschied zwischen „läuft“ und „läuft nicht“. Auch auf grösseren Maschinen lohnt es sich, die Modelle beim ersten grossen Import abzuschalten: Sonst konkurrieren Import und Analyse um dieselben Kerne.

Die App auf dem Telefon

Ohne App bleibt ein Fotoserver eine Ablage. Die Anleitung des Projekts zur Nacharbeit nach der Installation nennt vier Bezugsquellen: App Store, Google Play, die APK-Datei aus den GitHub-Releases und Obtainium sowie das F-Droid-Repository von FUTO. Für Geräte ohne Google-Dienste ist der Weg über die APK-Datei oder Obtainium der naheliegende.

Beim Anmelden wird nicht ein Konto bei einem Anbieter eingetragen, sondern die Adresse des eigenen Servers, also http://<IP-der-Maschine>:2283. Danach wählt ihr im Sicherungsbereich der App aus, welche Ordner des Telefons hochgeladen werden sollen — Kamera ja, der Ordner mit den heruntergeladenen Bildern aus Chatgruppen vermutlich nein — und schaltet die Sicherung ein. Der erste Durchlauf läuft am besten über Nacht und im WLAN.

Die Google-Fotos-Mediathek übernehmen

Jetzt zum Teil, an dem die meisten Umzüge scheitern. Ein Google-Fotos-Export ist keine Ordnerstruktur mit Bildern, sondern ein Archiv mit Bildern und einer zweiten Datei je Bild, in der die eigentlichen Informationen stehen. Wer nur die Bilder hochlädt, bekommt eine Mediathek ohne Aufnahmedaten, ohne Orte und ohne Alben — technisch vollständig, inhaltlich entkernt.

Schritt eins: das Takeout-Archiv anfordern

Der Export läuft über den Google Datenexport. Google beschreibt den Weg selbst so: Seite aufrufen, bei allen Produkten das Häkchen entfernen, die ihr nicht braucht, und nur Google Fotos stehen lassen. Danach wählt ihr Dateityp und Grösse. Nehmt ZIP, nicht TGZ, und als maximale Archivgrösse einen Wert, den euer Dateisystem und euer Download verkraften — bei 50 GB Grösse bekommt ihr wenige riesige Dateien, bei 2 GB viele kleine.

Zwei Angaben aus der Google-Hilfe sind für die Planung wichtig: Der Export kann „wenige Minuten oder auch einige Tage“ dauern, und die fertigen Archive „laufen ungefähr nach 7 Tagen ab“, wobei ein Archiv nur fünfmal heruntergeladen werden kann. Wer den Export am Freitagabend anstösst und dann in die Ferien fährt, fängt danach von vorne an.

Warum die Bilder nicht einfach hochgeladen werden

Neben jedem Bild liegt im Archiv eine JSON-Datei. Die Dokumentation von immich-go beschreibt, was dort steht: der ursprüngliche Dateiname, das Aufnahmedatum als Zahl in Sekunden, die GPS-Koordinaten, ob das Bild im Papierkorb lag und ob es aus einer Partnerfreigabe stammt. Alben sind im Archiv als eigene Ordner abgebildet. Vieles davon fehlt in den Bilddateien selbst, weil Google beim Export nicht alles zurückschreibt.

Dazu kommen die bekannten Eigenheiten des Exports, die das Projekt offen benennt: Bilder sind „duplicated with no apparent logic“ über mehrere Teilarchive verteilt, bearbeitete Fassungen haben manchmal keine JSON-Datei, und unbenannte Alben landen im selben Ordner — „Therefore it's impossible to rebuild original albums“. Ein Import, der das ignoriert, erzeugt Dubletten und Alben, die niemand wiedererkennt.

Das offizielle Kommandozeilenwerkzeug von Immich hilft hier nicht weiter, und das sagt es selbst: In der Dokumentation zur Immich-CLI steht „If you are looking to import your Google Photos takeout, we recommend this community maintained tool immich-go“. Die Bastellösung ist hier also der offiziell empfohlene Weg.

Schritt zwei: der Import mit immich-go

immich-go beschreibt sich als „An alternative to the immich-CLI command that doesn't depend on nodejs installation. It tries its best for importing google photos takeout archives.“ Es ist ein einzelnes übersetztes Programm, das ihr als fertige Datei für Linux, macOS, Windows und FreeBSD aus den Releases herunterladet — keine Abhängigkeiten, keine Installation.

Gebraucht wird ein API-Schlüssel aus der Weboberfläche, unter Account Settings > API Keys. Die Hinweise zur guten Praxis empfehlen einen eigenen Schlüssel mit nur den nötigen Rechten, und ihn nicht fest in ein Skript zu schreiben.

Erst ein Probelauf, der nichts schreibt:

./immich-go upload from-google-photos \
  --server=http://localhost:2283 \
  --api-key=EUER_API_SCHLUESSEL \
  --dry-run \
  /srv/takeout/takeout-*.zip

Sieht die Ausgabe plausibel aus, folgt der echte Durchlauf. Die Archive bleiben dabei gepackt, entpacken ist nicht nötig:

./immich-go upload from-google-photos \
  --server=http://localhost:2283 \
  --api-key=EUER_API_SCHLUESSEL \
  --manage-raw-jpeg=StackCoverRaw \
  --manage-burst=Stack \
  --pause-immich-jobs=true \
  /srv/takeout/takeout-*.zip

Die Optionen der Reihe nach: --manage-raw-jpeg=StackCoverRaw fasst RAW- und JPEG-Fassung derselben Aufnahme zu einem Stapel zusammen, statt zwei Einträge anzulegen. --manage-burst=Stack macht dasselbe mit Serienaufnahmen. --pause-immich-jobs=true hält die Hintergrundaufträge während des Imports an, was bei grossen Sammlungen empfohlen wird — der Server soll erst einlesen und danach analysieren.

Bricht der Vorgang ab, weil das Netz weg ist oder die Platte voll, startet ihr denselben Befehl einfach erneut: Laut Dokumentation erkennt das Werkzeug bereits vorhandene Dateien und überspringt sie. Einzelne Alben lassen sich mit --from-album-name="Ferien 2023" gezielt holen, und für Bilder, die nicht aus Google Fotos kommen, gibt es upload from-folder mit --folder-as-album=FOLDER.

Der erste Import einer grossen Mediathek braucht Stunden bis Tage. Lasst danach die Hintergrundaufträge durchlaufen, bevor ihr das Ergebnis beurteilt: Eine Zeitleiste mit halben Vorschaubildern ist kein Fehler, sondern eine Warteschlange.

Bestehende Ordner einbinden, statt sie zu kopieren

Wer seine Bilder schon sortiert auf einem NAS hat, will sie nicht ein zweites Mal hineinkopieren. Dafür gibt es externe Bibliotheken: Immich liest ein Verzeichnis, das ihr in den Container einbindet, und legt die Dateien nicht selbst an.

Der Zusatz in der Compose-Datei sieht so aus, und der Schalter am Ende ist der wichtige:

services:
  immich-server:
    volumes:
      - ${UPLOAD_LOCATION}:/data
      - /mnt/nas/fotoarchiv:/mnt/media/fotoarchiv:ro

Die Dokumentation erklärt dazu: „The ro flag at the end only gives read-only access to the volumes. This will disallow the images from being deleted in the web UI, or adding metadata to the library.“ Danach legt ihr unter Administration > External Libraries eine Bibliothek an und tragt als Importpfad den Pfad innerhalb des Containers ein, hier also /mnt/media/fotoarchiv. Importpfade werden rekursiv durchsucht, und mit Ausschlussmustern wie **/*.tif oder **/Raw/** lassen sich Dateitypen und ganze Unterordner auslassen.

Drei Eigenschaften solltet ihr kennen, bevor ihr das produktiv nutzt. Ein Suchlauf läuft standardmässig einmal täglich, der Zeitplan ist einstellbar. Verschwindet eine Datei auf der Platte, wandert der Eintrag beim nächsten Durchlauf in den Papierkorb von Immich und wird nach 30 Tagen endgültig entfernt. Und alles, was ihr in Immich an einem externen Bild ergänzt — Beschreibung, Schlagwörter, Personen —, bleibt in der Datenbank und wird nicht in die Datei zurückgeschrieben.

Von aussen erreichbar machen

Port 2283 direkt ins Internet zu stellen ist keine gute Idee, schon weil dann alles unverschlüsselt läuft. Der saubere Weg führt über einen Reverse Proxy mit eigenem Zertifikat; wie das mit Caddy in wenigen Zeilen gelingt, steht in unserer Anleitung zum Caddy Reverse Proxy mit automatischem HTTPS. Für Immich genügt dort ein Block dieser Art:

fotos.example.ch {
    reverse_proxy http://127.0.0.1:2283
    request_body {
        max_size 50GB
    }
}

Die Seite des Projekts zum Reverse Proxy nennt drei Punkte, an denen es sonst hakt. Erstens die Obergrenze für Uploads: Für nginx steht dort client_max_body_size 50000M, und wer sie zu klein setzt, bekommt genau bei den grossen Videos einen Fehler. Zweitens die Zeitgrenzen, die auf 600 Sekunden gehören — proxy_read_timeout 600s und Geschwister. Drittens die Weiterleitung für WebSockets über Upgrade und Connection "upgrade"; ohne sie lädt die Oberfläche, aktualisiert sich aber nie. Caddy bringt die WebSocket-Weiterleitung von sich aus mit, die Zeitgrenzen und die Uploadgrösse müsst ihr setzen.

Wer keinen öffentlichen Zugang braucht, nimmt stattdessen ein VPN und öffnet gar keinen Port — für einen Server, den nur die eigene Familie benutzt, die ruhigere Lösung.

Sichern: zwei Teile, zwei Verfahren

Immich trennt Daten und Metadaten, und genau so wird gesichert. Die Datenbank hält Pfade, Alben, Personen und Benutzer; die Dokumentation stellt klar: „Immich stores file paths and user metadata in the database. It does not scan the library folder, so database backups are essential.“ Ein Auszug entsteht so:

docker exec -t immich_postgres pg_dump --clean --if-exists \
  --dbname=immich --username=postgres | gzip > /srv/backup/immich-dump.sql.gz

Auf der Dateiseite sind laut Projekt UPLOAD_LOCATION/library, /upload und /profile die kritischen Verzeichnisse; empfohlen wird, UPLOAD_LOCATION vollständig zu sichern, „but only the original content is critical“. Vorschaubilder und umgewandelte Videos baut Immich bei Bedarf neu.

Zwei Regeln dazu. Erstens: Das Datenverzeichnis von Postgres wird nicht als Ordner kopiert. Ein solcher Abzug führt beim Zurückspielen zu Konflikten, und die Dokumentation beschreibt als Ausweg, DB_DATA_LOCATION zu löschen und die Datenbank neu aufzusetzen — was ohne gültigen Auszug bedeutet, dass alle Alben und Personen weg sind. Zweitens die Reihenfolge: Am besten wird der Container immich-server während der Sicherung angehalten. Ist das nicht möglich, sichert zuerst die Datenbank und danach die Dateien.

Beides lässt sich einrichten und dann vergessen. Wie ein solcher Auftrag mit einem systemd-Timer statt eines Cronjobs läuft und sich bei einem Fehlschlag von selbst meldet, haben wir separat beschrieben — gerade bei Sicherungen ist die Benachrichtigung bei Misserfolg der halbe Nutzen.

Aktualisieren, ohne Überraschungen

Ein Update besteht aus zwei Befehlen im Verzeichnis der Compose-Datei:

docker compose pull
docker compose up -d

Was dabei ankommt, entscheidet IMMICH_VERSION. Steht dort v3, holt ihr jeweils die neueste Fassung der Reihe. Vor jedem Sprung gehört ein Blick in die Veröffentlichungshinweise, und zwar aus einem konkreten Grund: Beim Sprung auf 3.0.0 waren die Änderungen mit Bruch überwiegend Schnittstellensachen, das Projekt schreibt dazu, „many of the breaking changes are updates to API endpoints and only affect third-party tools“. Für die Weboberfläche und die Apps war das unkritisch — für Skripte und Fremdwerkzeuge nicht.

Die Fassung 3.2.0 vom 10. September 2026 bringt unter anderem gemeinsame Personengruppen über Benutzergrenzen hinweg. Der Hinweis dazu ist unbedingt zu lesen, bevor die Funktion eingeschaltet wird: Sie verlangt ein Zurücksetzen der Gesichtserkennung für alle beteiligten Benutzer, und dabei gehen die vergebenen Namen und Geburtsdaten verloren. Eine Funktion, die Arbeit von Wochen löscht, gehört nicht in einen Feierabend-Klick.

Worauf ihr achten solltet

Die Fallen bei diesem Aufbau sind selten technisch schwierig, aber teuer, wenn sie erst nach dem Import auffallen:

• Registriert euch zuerst selbst. Das erste Konto wird Administrator. Der Port gehört erst danach nach draussen.
• Nur Buchstaben und Zahlen im Datenbankpasswort. Sonderzeichen in DB_PASSWORD führen zu einer Datenbank, die ohne verwertbare Meldung nicht startet.
• DB_DATA_LOCATION nicht auf eine Netzwerkfreigabe legen. Das ist ausdrücklich nicht unterstützt, und der Schaden zeigt sich erst unter Last.
• Das Speicher-Template vor dem ersten Import einschalten. Nachträglich geht es, verlangt aber einen Wartungsauftrag über den gesamten Bestand.
• Takeout-Archive niemals ohne Werkzeug hochladen. Ohne Auswertung der JSON-Dateien fehlen Datum, Ort und Alben — und das lässt sich später nur mit einem neuen Export nachholen.
• Platz für den Zuschlag einplanen. Vorschaubilder und umgewandelte Videos kommen mit 10 bis 20 Prozent obendrauf.
• Die Sicherung einmal zurückspielen. Ein Datenbankauszug, der noch nie eingelesen wurde, ist eine Vermutung.
• Externe Bibliotheken mit :ro einbinden. Ein Schreibzugriff auf das gewachsene Archiv ist ein Risiko, das keinen Vorteil bringt.

Erst ausprobieren, dann selbst aufsetzen

Bevor ihr eine Maschine aufsetzt, eine Platte einplant und einen Sicherungsauftrag schreibt, lässt sich die wichtigste Frage auch günstiger klären: Passt Immich überhaupt zu der Art, wie ihr eure Fotos verwaltet? Dafür betreiben wir unter unseren Free Services eine eigene Instanz, die ihr kostenlos nutzen könnt — immich.yourdevice.ch, mit 3 GB Speicher gratis für alle. Konto anlegen, App aufs Telefon, ein paar hundert Bilder hochladen.

Was ihr dort an einem Abend lernt, kann diese Anleitung nicht beantworten: ob euch die Zeitleiste liegt, ob die Suche nach Bildinhalten in eurer Sammlung tatsächlich trifft, ob die Gesichtserkennung eure Familie auseinanderhält und ob die App auf eurem Telefon zuverlässig sichert. Alles, was oben Platz braucht — Arbeitsspeicher, Speicherplatz, Reverse Proxy, Sicherung —, stellt sich dabei nicht, weil wir es übernehmen. Kein Tracking, keine Profilbildung, keine Weitergabe an Werbenetzwerke; der Dienst läuft nach denselben Regeln wie alles andere hier.

Und wenn ihr euch danach für den eigenen Server entscheidet, war die Testmediathek kein verlorener Aufwand: immich-go zieht nicht nur aus einem Google-Takeout um, sondern auch von einer Immich-Instanz zur nächsten. Die drei Gigabyte sind als Probe gedacht und nicht als Archiv — für fünfzehn Jahre Familienfotos braucht es die eigene Platte. Dafür steht der Rest dieser Anleitung.

Fazit: Immich ersetzt Google Fotos, aber kein Backup

Der Aufbau selbst ist erstaunlich unspektakulär: zwei heruntergeladene Dateien, fünf Zeilen Konfiguration, ein Befehl. Alles, was in dieser Anleitung Platz braucht, liegt davor und danach — die Frage, ob die Maschine reicht, die Entscheidung über das Speicher-Template, der Umzug der Google-Mediathek, die Sicherung. Wer diese vier Punkte vor dem ersten Bild klärt, hat einen Dienst, der jahrelang läuft. Wer sie überspringt, hat eine Zeitleiste voller Bilder mit Aufnahmedatum von letztem Dienstag.

Der wichtigste Satz steht dabei im Projekt selbst und nicht in dieser Anleitung: Die Datenbanksicherung deckt die Metadaten ab, für die Bilder und Videos seid ihr zuständig. Mit der Kontrolle über die eigenen Erinnerungen kommt die Verantwortung für die zweite Kopie — kein Nachteil des Selbsthostens, sondern dessen ehrlichere Variante. Bei Google lag die zweite Kopie auch nie bei euch, nur hat dort niemand darüber gesprochen.

Habt ihr Immich schon im Einsatz, oder einen Takeout-Import hinter euch, der anders verlief als beschrieben? Schreibt es in die Kommentare.

Quellen und weiterführende Links

• Immich: Requirements — Arbeitsspeicher, Kerne, x86-64-v2 ab Version 3, Dateisysteme und der Hinweis gegen Netzwerkfreigaben für die Datenbank
• Immich: Docker Compose Installation — die beiden Download-Adressen, die Variablen der .env und die Einschränkung beim Datenbankpasswort
• Immich: Quick Start — Port 2283, das erste Konto als Administrator und der Satz zur Eigenverantwortung bei der Sicherung der Dateien
• Immich: Post Installation — Speicher-Template, Bezugsquellen der mobilen Apps und der Verweis auf die 3-2-1-Strategie
• Immich: Backup and Restore — der pg_dump-Befehl im Wortlaut, die kritischen Unterverzeichnisse und die Warnung gegen das Kopieren des Postgres-Datenverzeichnisses
• Immich: Reverse Proxy — Uploadgrenze, Zeitgrenzen von 600 Sekunden und die Kopfzeilen für WebSockets
• Immich: External Libraries — Einbinden mit :ro, Importpfade, Ausschlussmuster, täglicher Suchlauf und Papierkorb nach 30 Tagen
• Immich: FAQ — Abschalten des maschinellen Lernens ganz oder je Modell, Zurücksetzen des Administratorpassworts
• Immich: Command Line Interface — Umfang der offiziellen CLI und die Empfehlung, für Google-Takeout immich-go zu nehmen
• immich-app/immich: docker/docker-compose.yml — die vier Dienste mit Abbildern, Volumes, Port und Abhängigkeiten
• Immich Blog: Release v3.0.0 — Erscheinungsdatum 1. Juli 2026 und die Einordnung der Änderungen mit Bruch
• immich-app/immich: Release v3.2.0 — Erscheinungsdatum 10. September 2026 und der Hinweis zum Zurücksetzen der Gesichtserkennung
• simulot/immich-go — Selbstbeschreibung des Werkzeugs, unterstützte Plattformen und der Hinweis, vorher eine Sicherung anzulegen
• immich-go: Google Takeout — Aufbau des Archivs, Inhalt der JSON-Dateien und die benannten Schwächen des Exports
• immich-go: Examples — die Befehle für from-google-photos und from-folder samt Optionen
• immich-go: Best Practices — API-Schlüssel, Probelauf, Anhalten der Hintergrundaufträge und Wiederaufnahme nach Abbruch
• Google: Daten herunterladen (Datenexport) — Auswahl einzelner Dienste, Dateityp und Archivgrösse, Ablauf nach etwa sieben Tagen und höchstens fünf Downloads