Immich 3.0

Original Article ↗ Hacker News Discussion ↗

Immich 3.0, a self-hosted alternative to Google Photos and iCloud, is widely praised for its fast UI, strong backup features, face recognition and external library support, with many users running it on home servers or low-cost VPSs behind VPNs. Commenters highlight practical challenges around upgrades, large-scale imports from Google/iCloud (often via third‑party tools), and iOS/Android background syncing, noting that reliability has improved but isn’t flawless. A recurring point of contention is the lack of built‑in end‑to‑end encryption: some see filesystem or VPN‑level encryption as sufficient for self‑hosting, while others prefer E2EE‑centric services like Ente for use on untrusted cloud infrastructure or shared family instances.

Overall sentiment & use cases

  • Many describe Immich as one of the best self‑hosted apps they run, “on par or better than Google/Apple Photos” for home use.
  • Common use: full family archive, large videos not suitable for cloud services, local snappy browsing, and escape from storage limits/pricing of Google One/iCloud.

Setup, upgrades & reliability

  • Several report years of stable Docker deployments, auto‑updates, and easy backups; database and library folder backups are straightforward.
  • Others recount painful migrations or corruption (DB, thumbnails), particularly with earlier versions or Proxmox LXC; a few say bad upgrade experiences made them wary of updating.
  • Some note that self‑hosting in general carries risk: breakage on upgrades, latent corruption, and the need for long‑term maintainability.

Self‑hosting vs cloud & cost

  • Some don’t want another self‑hosted service (maintenance, power, hardware failures) and lean toward hosted options.
  • Others argue VPS or rented dedicated servers count as “good enough” self‑hosting; backups to cheap cloud storage or NAS are common patterns.
  • Concern that cloud backup pricing can change, forcing periodic migrations.

Encryption, privacy & threat models

  • Large sub‑thread debates lack of end‑to‑end encryption (E2EE).
    • One camp: for self‑hosting, filesystem/disk encryption + TLS/VPN is sufficient; app‑level E2EE would kill server‑side ML, search, and transcoding, and increase complexity.
    • Other camp: anything on someone else’s computer (VPS, managed hosting) should be E2EE; they cite risks from providers scanning data or law enforcement requests.
    • Clarifications: E2EE vs “encryption at rest” is repeatedly confused; some point out recovery features and E2EE are inherently in tension.
  • Some want E2EE mainly to host for family/friends or on untrusted VPS while guaranteeing operators can’t inspect photos.

Data import & export

  • Google Takeout → Immich is a recurring pain point:
    • immich‑go is the de facto tool; some report smooth 100–700GB imports with preserved albums, others see numerous broken Live Photos or metadata failures and call it “abandonware.”
    • Takeout’s quirks (split archives, metadata JSON, naming) add friction; downloading via curl from browser “Copy as cURL” is a popular workaround.
  • Import from iCloud via Immich’s iOS app has longstanding bugs, especially around Live Photos, per some reports.
  • Export/migration out of Immich:
    • Some complain there’s no obvious “download all” in the UI; others note bulk download was recently added, and in any case raw files reside on disk and can be copied directly.

Mobile apps & sync behavior

  • Android: background backup has reportedly improved significantly in 3.0 using a new scheduler; some users already had reliable background uploads before.
  • iOS: synchronization is described as more fragile:
    • Some say it’s now acceptable; others report very slow or never‑completing full-library uploads and non‑resumable large video uploads.
    • Comparisons to Synology/Ente suggest Immich’s iOS experience can lag behind in reliability for large first‑time syncs.
  • Desire for “set and forget” behavior for non‑technical relatives is strong; whether this is fully solved is unclear.

External libraries, read‑only folders & storage

  • External (read‑only) libraries are available and widely used:
    • Good for those who want to preserve existing folder structures and keep Immich as an indexer only.
    • Recommended to mount external library volumes read‑only in Docker.
  • Complaints:
    • UI and logic have rough edges; some recurring date‑taken issues with subsets of photos.
    • External libraries per‑user currently cause duplicated thumbnails and increased storage; multi‑user face recognition amplifies this.
    • Maintainers indicate plans to better unify external and internal libraries and improve this.

Networking, exposure & access

  • Many run Immich behind:
    • Tailscale/WireGuard for private access; battery impact on phones is reported as small if not using full exit nodes.
    • Nginx/Caddy, sometimes via Cloudflare Tunnel (but Cloudflare’s 100MiB limit can break large video uploads).
  • Debate over exposing Immich directly to the internet:
    • Some say it’s fine with updates, WAF/CrowdSec, and IP geofencing.
    • Others insist on VPN‑only to minimize attack surface, citing the complexity of the codebase.

Alternatives & comparisons

  • Ente is the main alternative discussed:
    • Praised for polished UX, E2EE, album sharing with public upload links, and optional self‑hosting.
    • Some report serious upload bugs in self‑hosted setups; others say it runs flawlessly.
    • Viewed as complementary: Ente for E2EE/cloud use, Immich for trusted self‑hosting.
  • Photoprism and Synology Photos are mentioned as existing solutions; several are considering or planning migration to Immich.

Feature gaps & wishes

  • Frequently requested:
    • Better, first‑class import tooling from Google Photos/iCloud (not relying on external projects).
    • Smarter workflows (e.g., face‑based automatic albums), nested albums/folders, and album elements beyond photos (text, maps) to mimic Google Photos’ “story” feel.
    • Per‑photo “vault”/locked area for especially sensitive images.
    • More robust multi‑user handling of external libraries and shared collections.