Immich 3.0

समग्र भावना और उपयोग-केस

  • कई लोग Immich को उन सर्वश्रेष्ठ self-hosted ऐप्स में से एक बताते हैं जिन्हें वे चलाते हैं, जो घर के उपयोग के लिए “Google/Apple Photos के बराबर या उससे बेहतर” है।
  • सामान्य उपयोग: पूरा पारिवारिक आर्काइव, बड़े वीडियो जो cloud सेवाओं के लिए उपयुक्त नहीं हैं, स्थानीय रूप से तेज़ browsing, और Google One/iCloud की storage सीमाओं/मूल्य से बचाव।

सेटअप, upgrades और reliability

  • कई लोग वर्षों से स्थिर Docker deployments, auto-updates, और आसान backups की रिपोर्ट करते हैं; database और library folder के backups सीधे-साधे हैं।
  • अन्य लोग painful migrations या corruption (DB, thumbnails) के अनुभव बताते हैं, खासकर पुराने versions या Proxmox LXC के साथ; कुछ कहते हैं कि खराब upgrade अनुभवों ने उन्हें updates से सावधान कर दिया।
  • कुछ का कहना है कि सामान्य रूप से self-hosting में जोखिम होता है: upgrades पर breakage, latent corruption, और long-term maintainability की ज़रूरत।

Self-hosting बनाम cloud और लागत

  • कुछ लोग एक और self-hosted service नहीं चाहते (maintenance, power, hardware failures) और hosted options की ओर झुकते हैं।
  • अन्य लोग तर्क देते हैं कि VPS या rented dedicated servers भी “काफी अच्छे” self-hosting माने जा सकते हैं; cheap cloud storage या NAS पर backups आम पैटर्न हैं।
  • चिंता है कि cloud backup pricing बदल सकती है, जिससे समय-समय पर migrations करनी पड़ सकती हैं।

Encryption, privacy और threat models

  • एक बड़े sub-thread में end-to-end encryption (E2EE) की कमी पर बहस होती है।
    • एक पक्ष: self-hosting के लिए filesystem/disk encryption + TLS/VPN पर्याप्त है; app-level E2EE server-side ML, search, और transcoding को खत्म कर देगा, और complexity बढ़ाएगा।
    • दूसरा पक्ष: किसी और के कंप्यूटर (VPS, managed hosting) पर कुछ भी हो, तो E2EE होना चाहिए; वे providers द्वारा data scanning या law enforcement requests के जोखिम का हवाला देते हैं।
    • स्पष्टीकरण: E2EE और “encryption at rest” को बार-बार ग़लत समझा जाता है; कुछ लोग बताते हैं कि recovery features और E2EE स्वाभाविक रूप से एक-दूसरे के साथ तनाव में होते हैं।
  • कुछ लोग E2EE मुख्यतः इसलिए चाहते हैं ताकि परिवार/दोस्तों के लिए या untrusted VPS पर host करते समय operators तस्वीरें देख न सकें।

Data import और export

  • Google Takeout → Immich एक बार-बार सामने आने वाला pain point है:
    • immich-go de facto tool है; कुछ लोग 100–700GB imports को albums preserve करते हुए smooth बताते हैं, जबकि अन्य कई broken Live Photos या metadata failures देखते हैं और इसे “abandonware” कहते हैं।
    • Takeout की quirks (split archives, metadata JSON, naming) friction बढ़ाती हैं; browser “Copy as cURL” से curl द्वारा डाउनलोड करना एक लोकप्रिय workaround है।
  • iCloud से Immich के iOS ऐप के ज़रिए import में लंबे समय से bugs हैं, खासकर Live Photos के आसपास, कुछ रिपोर्टों के अनुसार।
  • Immich से export/migration:
    • कुछ लोग शिकायत करते हैं कि UI में स्पष्ट “download all” नहीं है; अन्य लोग नोट करते हैं कि bulk download हाल ही में जोड़ा गया है, और किसी भी स्थिति में raw files disk पर रहती हैं और सीधे copy की जा सकती हैं।

Mobile apps और sync व्यवहार

  • Android: बताया गया है कि background backup 3.0 में नए scheduler के साथ काफी बेहतर हुआ है; कुछ उपयोगकर्ताओं के लिए पहले भी background uploads विश्वसनीय थीं।
  • iOS: synchronization को अधिक नाज़ुक बताया गया है:
    • कुछ कहते हैं कि अब यह स्वीकार्य है; अन्य बहुत धीमे या कभी पूरे न होने वाले full-library uploads और resumable न होने वाले बड़े video uploads की रिपोर्ट करते हैं।
    • Synology/Ente से तुलना बताती है कि बड़े first-time syncs की reliability में Immich का iOS अनुभव पीछे रह सकता है।
  • गैर-तकनीकी रिश्तेदारों के लिए “set and forget” व्यवहार की चाहत मजबूत है; यह पूरी तरह हल हुआ है या नहीं, स्पष्ट नहीं है।

External libraries, read-only folders और storage

  • External (read-only) libraries उपलब्ध हैं और व्यापक रूप से उपयोग होती हैं:
    • उन लोगों के लिए अच्छी हैं जो मौजूदा folder structures को बनाए रखना चाहते हैं और Immich को केवल एक indexer के रूप में रखना चाहते हैं।
    • Docker में external library volumes को read-only mount करने की सलाह दी जाती है।
  • शिकायतें:
    • UI और logic में खुरदुरे किनारे हैं; कुछ photo subsets के साथ date-taken issues बार-बार आते हैं।
    • प्रति-user external libraries के कारण thumbnails डुप्लिकेट होते हैं और storage बढ़ती है; multi-user face recognition इसे और बढ़ाता है।
    • maintainers इसे बेहतर तरीके से unify करने और सुधारने की योजनाएँ बताते हैं।

Networking, exposure और access

  • कई लोग Immich को इनके पीछे चलाते हैं:
    • निजी access के लिए Tailscale/WireGuard; phones पर battery impact, full exit nodes का उपयोग न करने पर, छोटा बताया जाता है।
    • Nginx/Caddy, कभी-कभी Cloudflare Tunnel के माध्यम से (लेकिन Cloudflare का 100MiB limit बड़े video uploads को तोड़ सकता है)।
  • Immich को सीधे इंटरनेट पर expose करने पर बहस:
    • कुछ कहते हैं कि updates, WAF/CrowdSec, और IP geofencing के साथ यह ठीक है।
    • अन्य attack surface कम करने के लिए केवल VPN पर insist करते हैं, codebase की complexity का हवाला देते हुए।

Alternatives और comparisons

  • Ente मुख्य alternative के रूप में चर्चा में है:
    • polished UX, E2EE, public upload links के साथ album sharing, और optional self-hosting के लिए सराहा जाता है।
    • कुछ लोग self-hosted setups में गंभीर upload bugs की रिपोर्ट करते हैं; अन्य कहते हैं कि यह flawlessly चलता है।
    • इसे पूरक के रूप में देखा जाता है: E2EE/cloud use के लिए Ente, trusted self-hosting के लिए Immich।
  • Photoprism और Synology Photos का भी उल्लेख है; कई लोग Immich में migration पर विचार कर रहे हैं या योजना बना रहे हैं।

Feature gaps और इच्छाएँ

  • बार-बार माँगे गए फीचर्स:
    • Google Photos/iCloud से बेहतर, first-class import tooling (external projects पर निर्भर न होना)।
    • अधिक स्मार्ट workflows (जैसे face-based automatic albums), nested albums/folders, और Google Photos के “story” अनुभव की नकल करने के लिए photos के अलावा album elements (text, maps)।
    • विशेष रूप से संवेदनशील images के लिए प्रति-photo “vault”/locked area।
    • external libraries और shared collections के लिए अधिक robust multi-user handling.