अल्टीमेट सेल्फ-होस्टिंग वातावरण बनाने की कहानी

 (codecaptured.com)
26 पॉइंट द्वारा GN⁺ 2025-07-20 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • कई वर्षों तक अलग-अलग self-hosting approaches आज़माने के बाद, अपने लिए एक कस्टम वातावरण सफलतापूर्वक बनाने का अनुभव साझा किया गया है
  • मुख्य लक्ष्य व्यक्तिगत डेटा पर नियंत्रण और भरोसेमंद infrastructure बनाए रखना था, जिसके लिए NixOS, ZFS, Tailscale, Authelia जैसी कई प्रमुख तकनीकों को जोड़ा गया
  • परिवार और परिचितों की usability को भी ध्यान में रखते हुए SSO, अलग start page आदि के माध्यम से accessibility बेहतर की गई
  • वास्तविक संचालन के दौरान सामने आए मुद्दों और उनके ठोस समाधानों (जैसे private services के public proxy, mixed VPN environment, authentication integration) को विस्तार से व्यवस्थित किया गया है
  • आगे backup infrastructure और security hardening जैसी अतिरिक्त सुधार योजनाएँ भी हैं, साथ ही उपयोगी know-how और reference materials भी दिए गए हैं

परिचय और प्रेरणा

  • कई वर्षों में self-hosting के कई तरीके आज़माने के बाद, लेखक ने अपने लिए एक "काफ़ी अच्छा" वातावरण तैयार किया
  • कई open source संसाधनों और अन्य लोगों के अनुभवों का संदर्भ लिया गया, और इस प्रक्रिया को साझा कर दूसरे developers की मदद करने का उद्देश्य रखा गया

लक्ष्य

  • व्यक्तिगत डेटा और उससे जुड़ी सेवाओं पर सीधे नियंत्रण के माध्यम से privacy को मजबूत करना और निर्भर सेवाओं में बदलाव या उनके बंद हो जाने के जोखिम को कम करना
  • यही नियंत्रण परिवार और परिचितों को भी उपलब्ध कराकर, एक भरोसेमंद service environment तैयार करने पर ध्यान केंद्रित किया गया

आवश्यकताएँ

  • अनिवार्य शर्तें

    • जितना संभव हो, सेवाओं की public internet exposure को सीमित करना ताकि security incidents का जोखिम घटे
    • गलती की वजह से होने वाले core infrastructure downtime को न्यूनतम रखना (circular dependency से बचना और configuration rollback आसान होना)
    • authentication, network, domain जैसे मुख्य components पर सीधा स्वामित्व और open source को प्राथमिकता
    • परिवार और परिचितों के नज़रिए से usability का ध्यान (एकसमान SSO login, न्यूनतम maintenance)
    • configuration files की declarative संरचना को सक्रिय रूप से अपनाना (version control, backup/recovery में आसानी, और दूसरों की settings का संदर्भ लेकर पुन: उपयोग)
    • updates आसान और सुरक्षित हों, ताकि नियमित रूप से maintenance किया जा सके

  • गैर-प्राथमिक शर्तें

    • अत्यधिक modularity/साफ़-सुथरेपन की आवश्यकता नहीं (व्यावहारिकता पहले)
    • सब कुछ open source होना ज़रूरी नहीं, लेकिन जहाँ संभव हो वहाँ उसका उपयोग
    • high availability (HA) का लक्ष्य नहीं; downtime स्वीकार करते हुए सरल संरचना अपनाई गई

तकनीकी चयन

  • NixOS

    • Nix language और package manager के माध्यम से पूरे OS configuration को declarative तरीके से प्रबंधित करने वाला Linux distribution
    • configuration को code के रूप में रखने से version control और व्यवस्थित rollback संभव होता है
    • विभिन्न packages और Docker/Podman जैसे integrations का समर्थन
    • दूसरे developers की Nix configurations से सीखकर know-how इकट्ठा किया गया

  • ZFS

    • high-performance filesystem जिसमें snapshots, rollback जैसे data protection features काफ़ी मज़बूत हैं
    • 4 x 10TB HDD को RAIDZ2 में कॉन्फ़िगर किया गया (एक साथ 2 disks fail होने तक सहनशील), और 256GB SDD को caching के लिए इस्तेमाल किया गया
    • files और media datasets को अलग करके, उपयोग के अनुसार NFS mounts से प्रबंधन
    • सरल और भरोसेमंद main storage architecture तैयार की गई

  • Tailscale & headscale

    • Tailscale: आसान accessibility वाला Mesh VPN, जिसमें सिर्फ client install करके public internet exposure के बिना internal network access संभव है
    • Headscale: self-host किया जा सकने वाला open source Tailscale backend (कंपनी policy बदलने के जोखिम को हटाता है)
    • network safety बेहतर होती है, लेकिन user devices पर client install करना पड़ता है
    • usability के नज़रिए से, हर device पर client install करने की आवश्यकता थोड़ी entry barrier बनती है

  • Authelia & LLDAP

    • Authelia: OpenID Connect आधारित SSO, authentication और authorization solution, जिसे nginx proxy के साथ जोड़ा जा सकता है
    • LLDAP: Lightweight LDAP, जिसे Authelia के user/group management और backup authentication के लिए उपयोग किया गया
    • कम resources में अच्छी तरह काम करता है, लेकिन configuration कठिन है और किन services के साथ कैसे integrate करना है, इसमें learning curve है

संरचना डिज़ाइन

  • आर्किटेक्चर

    • हर server का नाम Star Wars के ग्रहों के नाम पर रखा गया
    • entry point (public server) "taris" है, जो Authelia, headscale, blog जैसी ज़रूरी services देता है
    • headscale, Authelia, LLDAP को external access चाहिए, इसलिए इन्हें सीमित दायरे में public रूप से चलाया गया
    • private services (Foundry VTT, monitoring आदि) को NGINX से proxy करके चुनिंदा रूप से expose किया गया

  • private server

    • मुख्य server "kuat" पर TrueNAS के माध्यम से NixOS VM और ZFS storage pool प्रबंधित किए जाते हैं
    • "files" (ऐसा डेटा जो दोबारा नहीं पाया जा सकता) और "media" (ऐसा डेटा जिसे चाहें तो दोबारा हासिल किया जा सकता है) के रूप में snapshot/backup scope अलग किया गया
    • मुख्य services को "bespin" VM पर NixOS के साथ चलाया गया, और testing के लिए अलग VM ("alderaan") भी बनाया गया

  • अन्य सेवाएँ

    • mission-critical devices को single-purpose appliance के रूप में रखा गया (उदाहरण: smart home के लिए अलग Home Assistant OS)
    • Matrix server और Element client के लिए आधिकारिक Ansible Playbook का उपयोग
    • mail और password management को ProtonMail और Bitwarden जैसी external services को outsource किया गया, ताकि circular dependency न बने

अलग-अलग समस्याएँ और समाधान

  • service start page

    • Flame आधारित simple dashboard, जिससे अलग-अलग users के लिए service accessibility बेहतर हुई
    • कम उपयोग के बावजूद visual quality अच्छी है, इसलिए alternative service अपनाने तक यह व्यावहारिक समाधान रहा

  • Tailscale और अन्य VPN का साथ में उपयोग

    • कुछ OS (खासकर Android, Windows) में multiple VPNs एक साथ चलाना संभव नहीं
    • Tailscale exit node feature और Gluetun (container-based VPN client) के संयोजन से ProtonVPN जैसे external VPN का bypass उपयोग किया गया
    • हालांकि, battery usage बढ़ने और बीच-बीच में speed कम होने जैसे side effects भी हैं

  • authentication पर ध्यान देने योग्य बातें

    • self-hosting services में प्रमुख authentication protocols: OIDC (प्राथमिक), OAuth, LDAP
    • हर service और Authelia के लिए अलग configuration चाहिए
    • admin account को Authelia/LLDAP integration से अलग रखना ज़रूरी है, ताकि authentication समस्या आने पर recovery का रास्ता बना रहे
    • OIDC को support न करने वाली services के लिए NGINX और Authelia proxy integration से access control लागू किया गया
    • Authelia के OIDC और NGINX Proxy access control के लिए अलग-अलग configuration चाहिए

  • DNS और SSL जारी करना

    • public services को सामान्य तरीके से चलाया गया (domain → public IP)
    • internal services के लिए "internal" subdomain और Tailscale IP का उपयोग कर external exposure रोका गया
    • SSL certificates के लिए NixOS के built-in Lets Encrypt support का उपयोग किया गया (public services के लिए HTTP-01, internal services के लिए DNS-01)

  • NixOS VPS installation में सावधानियाँ

    • कई VPS providers पर NixOS installation option उपलब्ध नहीं होता
    • installation की आवश्यकता होने पर community wiki आदि देखकर supported installation path की पुष्टि करनी चाहिए

  • TrueNAS dataset का VM mount

    • TrueNAS का default firewall, VM से host access को block करता है
    • आधिकारिक guide (Bridge network बनाना) के अनुसार NFS dataset mount लागू किया गया

  • व्यक्तिगत सेवाओं के लिए public proxy

    • headscale आधारित setup में, NGINX proxyPass से private services को externally expose किया जा सकता है
    • Tailscale के आधिकारिक Funnel के अलावा, configuration examples और setup references भी दिए गए हैं

अगले कदम और चुनौतियाँ

  • dedicated backup server और recovery verification system जोड़ने की ज़रूरत है
  • Tailscale/headscale के access control का और सक्रिय उपयोग करने की योजना है
  • SSH access आदि के लिए अतिरिक्त security hardening करने की योजना है
  • Pi-hole, AdGuard Home जैसी local DNS encryption/caching solutions अपनाने पर विचार
  • Forgejo, Manyfold, RomM जैसी नई services जोड़ने की संभावना

संदर्भ सामग्री

संबंधित पढ़ाई

2 टिप्पणियां

 
opminsu 2025-07-25

कमाल है!
 
GN⁺ 2025-07-20
Hacker News राय

  • अगर परिवार या दोस्तों के लिए इसे आसानी से इस्तेमाल करने लायक बनाना हो, तो लक्ष्य यही होता है कि हर व्यक्ति के लिए एक लॉगिन अकाउंट हो और वह SSO (single sign-on) के आधार पर कई सेवाओं तक पहुँच सके। यही हिस्सा सबसे कठिन भी है और सबसे शानदार भी। open source और Linux वास्तव में बड़े विरोधाभासी हैं: ये हर जगह इस्तेमाल होते हैं और लगभग सभी प्रोटोकॉल संभाल लेते हैं, लेकिन असली client environment, यानी लोगों को जोड़ना और groupware जैसी चीज़ों को खुद बनाना, उल्टा और जटिल हो जाता है। कई systems को organically जोड़ना और directory infrastructure तक खड़ा करना अपने आप में हैरान करने वाला काम है। कभी सोचा नहीं था कि एक दिन FreeIPA या Windows-compatible directory service खुद चलानी पड़ेगी, लेकिन हाल में लगता है कि OpenID आधारित दुनिया सचमुच अपनी जगह बना रही है

    • सहमति और धन्यवाद के लिए शुक्रिया। आसान लॉगिन और accessibility इस प्रोजेक्ट की सबसे कठिन requirement थी, और मेरा मानना है कि यही तय करती है कि लोग इसे सच में इस्तेमाल करेंगे या नहीं। open source सचमुच हर जगह है, लेकिन जैसे ही आम users खुद कुछ इस्तेमाल करने की कोशिश करते हैं, वहीं से दिक्कतें शुरू हो जाती हैं। मुझे लगता है यह विरोधाभास इसलिए पैदा होता है क्योंकि हर project अपनी तरफ से अलग-अलग innovation करना चाहता है। किसी एक दिशा में खींचने वाला कोई central actor नहीं होना इसका फायदा भी है और नुकसान भी। फिर भी, पिछले 5 सालों में सिर्फ self-hosting ecosystem को देखें, तो installation और usage दोनों ही काफी आसान हुए हैं

    • मैं इस विरोधाभास से पूरी तरह सहमत हूँ। कल ही मैंने अपने validation platform पर लिखा था कि FOSS non-technical लोगों के लिए कितना कम accessible है। इससे यह सोचने पर मजबूर होना पड़ता है कि technical users और non-technical users को जोड़ने वाला system integrator जैसा कोई platform शायद इसका हल हो सकता है

    • असल में यह इतना भी कठिन नहीं है। अगर आप किसी खास service से चिपके रहने के बजाय SSO support को सबसे पहली selection criteria बना लें, तो setup उम्मीद से आसान हो जाता है। मेरे पास भी शुरू में लगभग कोई अनुभव नहीं था, लेकिन caddy और authentik का इस्तेमाल करके मैंने जल्दी ही self-hosted system तैयार कर लिया। एक विकल्प के रूप में yunohost बहुत आसान distribution है, जो SSO तक खुद configure कर देता है

    • मैं authentik के साथ Google, Discord और GitHub SSO authentication इस्तेमाल कर रहा हूँ। यह सबके लिए काफी अच्छी तरह काम कर रहा है

  • मुझे पता है कि हर किसी को अपना एकदम ‘fit’ system ढूँढने में समय लग सकता है। सबके goals, preferences और environment अलग होते हैं, इसलिए मैं अपने final setup की यात्रा को एक blog post में समेटकर साझा करना चाहता हूँ। इसमें goals और requirements, इस्तेमाल की गई technologies, design और problem-solving process शामिल हैं। मेरा तरीका सबके लिए सही नहीं होगा, लेकिन उम्मीद है कि यह दूसरों के लिए भी उपयोगी संदर्भ बनेगा। मैं भी बहुत-सी content और free software की मदद से आगे बढ़ा हूँ, इसलिए मदद आगे बढ़ाते रहना चाहता हूँ

    • homelab में Nix इस्तेमाल करने का आपका अनुभव जानने की उत्सुकता है। मैं खुद 7 साल से भी ज्यादा समय से 25U rack में छोटे kubernetes, ceph और Talos Linux जैसी चीज़ें काफी hardcore तरीके से चला रहा हूँ, लेकिन अब धीरे-धीरे simplification की तरफ जाना चाहता हूँ, और सोचते-सोचते अजीब तरह से निष्कर्ष Nix और ZFS पर आकर टिक जाता है। इससे जुड़ी मुश्किलें मुझे बहुत परिचित लगती हैं। अगर आपके भी कोई सवाल हों तो बेझिझक पूछिए

    • क्या आपने coolify इस्तेमाल करने पर विचार किया है? मैं एक साल से ज्यादा समय से coolify इस्तेमाल कर रहा हूँ, और GitHub से Heroku-जैसे आसान auto-deploy वाला हिस्सा मुझे काफी पसंद है https://coolify.io/

    • क्या आप ZFS encryption feature भी इस्तेमाल करते हैं? पहले मैं FreeIPA वगैरह कई VM को Debian+ZFS पर चलाता था, लेकिन simplification के लिए अब VPS पर सिर्फ Seafile encryption library चलाता हूँ और ZFS send/receive के जरिए घर के server पर backup करता हूँ। वह server हर रात चालू होता है, update और sync करके फिर sleep में चला जाता है। और सुरक्षित बनाने के लिए सोच रहा हूँ कि Linux desktop (Fedora) का ZFS भी full encryption पर चलाऊँ। चूँकि main dataset पहले से encrypted है, इसलिए external drive या cloud sync भी काफी आसान हो गया है। पूरी photo archive को VPS Seafile पर डालना cost की वजह से भारी पड़ता है, इसलिए कोई रास्ता ढूँढ रहा हूँ

    • setup review और detailed explanation काफी उपयोगी लगी। मैं आपकी तरह इसे तुरंत अपनाना तो मुश्किल समझता हूँ, लेकिन dashboard के रूप में flame install करके परिवार के साथ प्रयोग करने का फैसला किया है

    • आपसे मिलकर खुशी हुई, आपका काम सचमुच दिलचस्प है। मैं भी NixOS आधारित एक similar project पर काम कर रहा हूँ। मेरा लक्ष्य ऐसा छोटा box बनाना है जिसे कोई भी modem में plug करे, web install wizard से गुज़रे, और काम खत्म — लगभग zero-config, Apple जैसी feel के साथ। अभी शुरुआती अवस्था में है, लेकिन घर पर पहले से चल रहा है। यह hybrid router (OPNSense/PFSense) और app server (Nextcloud, Synology, Yunohost आदि) दोनों का काम एक साथ करता है। सारी settings भी एक ही Nix module sheet से manage होती हैं। dynamic DNS, Let's Encrypt certificate, हर app के लिए automatic subdomain assignment, ad blocking, और built-in headscale भी है। अभी SSO भी बना रहा हूँ, और आपके लेख से कुछ ideas लेने वाला हूँ। विस्तार से https://homefree.host देख सकते हैं

  • कभी-कभी अपने home network को देखकर मैं सोचता हूँ कि अगर मेरी मौत हो जाए, तो परिवार पर इसका कितना बुरा असर पड़ेगा(?) या कोई बाहरी व्यक्ति मेरी setup को समझने में कितना संघर्ष करेगा। ‘homelab खेलना’ असल में पुरानी पीढ़ी के उन ‘अंकलों’ के शौक जैसा कुछ भरता है जो miniature railway layout बनाते हैं। मैं इसे बुरा कहकर नहीं बोल रहा, लेकिन लगता है कि कुछ लोगों के भीतर अपने absolute control वाले छोटे-से miniature world की इच्छा स्वाभाविक होती है

    • मैं भी बिल्कुल ऐसा ही सोचता हूँ, इसलिए contingency के लिए documentation लिखकर रखी है। भाग 1 में पैसे और जरूरी documents कहाँ हैं, यह है। भाग 2 में घर को कैसे ‘और बेवकूफ’ बनाना है, इसकी instructions हैं। जैसे smart switch हटाकर traditional switch वापस लगाना, Bitwarden जैसी key services को cloud में ले जाना, domain/mail maintenance cost, router को ISP के default equipment पर वापस करना, वगैरह। मेरी पत्नी smart home को लेकर बहुत उत्साहित नहीं थी, लेकिन जब मैंने कहा कि इसे कभी भी फिर से ‘साधारण घर’ बनाया जा सकता है, तो उसे राहत मिली। ईमानदारी से कहूँ तो यह सब हट जाए तो कितनी असुविधा होगी, पता नहीं, लेकिन यह सोचकर सुकून है कि तब वह मेरी समस्या नहीं होगी

    • मैं अपने पारिवारिक फोटो home lab RAID1 में रखता हूँ, और हर रात in-laws के घर रखे कंप्यूटर पर external drive में rsync backup करता हूँ। backup के साथ-साथ यह भी ध्यान रखा है कि अगर कुछ हो जाए तो परिवार आसानी से access कर सके। मेरी पत्नी IT में रुचि नहीं रखती, इसलिए मैंने बस इतना कहा है: "USB लगाओ, सब कुछ वहीं है"

    • मुझे लगता है कि physical disk चोरी जैसे कम उपयोगी threat scenario को नज़रअंदाज़ करना ठीक है। सभी photos और मुख्य documents को बिना encryption के रखना और साथ में आसान explanation छोड़ना ज्यादा practical है। home automation वाली तरफ की चिंता उससे भी ज्यादा है

    • homelab operator के लंबे समय तक अनुपस्थित रहने या किसी अनहोनी की स्थिति में क्या करना है, इस पर पहले से सोचना वास्तव में महत्वपूर्ण है। मैंने इसे आसान बनाने के लिए अलग से बहुत काम नहीं किया, लेकिन लगता है कि इस पर और विचार होना चाहिए। असली बात यह है कि महत्वपूर्ण data और उसे access करने के credentials पीछे छोड़े जाएँ। Nextcloud जैसी service का इस्तेमाल करके data को परिवार के devices में automatically sync कराया जा सकता है, और परिवार व दोस्तों को खुद उपयोग में शामिल करना भी अच्छा है। हमारे घर में भी Home Assistant को जीवनसाथी के साथ इस्तेमाल होने वाली किसी आवश्यक appliance जैसी चीज़ बनाने की कोशिश है। जब यह अलग VM के बजाय किसी physical चीज़ के रूप में मौजूद हो, तो management आसान होता है। बेशक, इसमें काफी आशा भी शामिल है, इसलिए कम-से-कम करीबी परिवार के साथ विस्तृत योजना पहले से बना लेना ज़रूरी है

    • मैंने भी इस हिस्से पर काफी सोचा है। मेरा मानना है कि NAS और Docker services मेरे बिना ठीक से boot नहीं होंगी। offsite password backup भी शायद किसी expert की मदद के बिना recover नहीं हो पाएगा। इसलिए मैं NTFS external hard drive पर cron से हर दिन incremental snapshots नए folder में save करता हूँ। कुल size 50GB से कम है, इसलिए सस्ते में duplicates रखना संभव है। अगर कुछ हो जाए, तो बस वह hard drive लगाकर folders copy करने हैं। हर individual laptop में Seafile की पूरी library की copy भी है। mail domain के लिए 10 साल advance payment किया हुआ है और iCloud hosting पर है। परिवार की photos attachments के कारण mailbox भर जाने और mail bounce होने की समस्या को लेकर migadu पर विचार कर रहा हूँ

  • मुझे भी इस क्षेत्र में काफी दिलचस्पी है। बस चेतावनी देना चाहता हूँ कि अगर आप self-employment/IT startup खुद शुरू करते हैं, तो homelab की इच्छा और बढ़ सकती है। धीरे-धीरे सिर्फ simple container चलाना काफी नहीं लगता, और आप तरह-तरह के documents जमा करके कानूनी DBA और ASN तक ले लेते हैं, फिर अपने IP block/IPV6 के साथ अपना ISP बनाने जैसी दिशा में बढ़ जाते हैं। ingress (बाहरी access) की समस्या को बहुत लोग tailscale से हल करते हैं, लेकिन यही हिस्सा सच में कठिन है। STUN/TURN आधारित architecture में पूरे server के static files को सिर्फ cache करना, और dynamic access को login wall पर email magic link authentication से संभालना — सिद्धांत रूप में मुझे न तो बहुत खतरनाक लगता है, न बहुत महँगा। remote development environment बनाते हुए इन चीज़ों में और गहराई से उतरने का एक नया बहाना भी मिल जाता है। संदर्भ लिंक: https://en.wikipedia.org/wiki/Traversal_Using_Relays_around_NAT, https://en.wikipedia.org/wiki/STUN

    • मैं ingress के लिए Fly.io इस्तेमाल करता हूँ। remote side पर nginx cache है, और ingress pod में Fly Wireguard peer container जोड़ा है। यह तरीका मुफ़्त तो नहीं है, लेकिन घर से सीधे कोई port खोले बिना anycast ingress भी मिल जाता है, और cost के हिसाब से यह सबसे तर्कसंगत लगा

  • हाल में Immich के साथ छेड़छाड़ कर रहा हूँ, और हर बार यही सोचता हूँ कि घर के बाहर से इसे सिर्फ tailscale के जरिए इस्तेमाल करूँ या VPS पर reverse proxy भी चढ़ाऊँ। सबसे बड़ी चिंता यह है कि VPS पर कौन attack attempts कर रहा है, यह बताने वाला कोई user-friendly monitoring/security solution कैसे मिले

    • मैं भी यही सोच रहा हूँ। अगर आपको security/monitoring solution के बारे में कोई जानकारी मिले, तो कृपया साझा करें

  • मेरा setup इससे कहीं ज्यादा simple है

    • एक machine
    • nginx proxy
    • उसी machine पर कई services; कुछ internal use के लिए, कुछ बाहरी रूप से public, लेकिन सब web से accessible
    • internal services के लिए लंबा HTTP basic auth password इस्तेमाल करता हूँ (Firefox built-in password manager)
    • external services public हैं या Google OAuth लगा है
    • सब कुछ scratch से खुद code किया है, और यही homelab का उद्देश्य है
    • image हो या video, browser खुद ही अच्छी तरह चला लेता है
    • मुश्किल हिस्सा हमेशा backend होता है, frontend तो लगभग 90s HTML जैसा है

    • HTTP password को plain text में भेजता है, इसलिए कम-से-कम self-signed certificate तो इस्तेमाल करना ही सुरक्षित रहेगा

    • infra या services को भी code के रूप में खुद बनाना सीखने के लिए कमाल की बात है। अपनी ज़रूरतों पर बिल्कुल सटीक फिट बैठाना भी इसकी बड़ी खूबी है

  • मैं ऐसा homelab चलाना चाहता हूँ, लेकिन समय नहीं निकाल पाता। weekend में install कर सकता हूँ, लेकिन maintenance/update लगातार करते रहने की फुर्सत नहीं है। इसलिए मैं बस cloud provider को यह काम सौंप देता हूँ और दिमाग हटाकर चलता हूँ। अगर मेरी तरह सिर्फ cloud इस्तेमाल करने वाले लोग यहाँ हैं, तो जानना चाहूँगा कि वे किस तरीके से approach करते हैं

    • मेरे पुराने setup में भी maintenance ढंग से नहीं हो पाती थी, जिससे stress होता था। इसी वजह से मुझे NixOS और ZFS पसंद आने लगे। दोनों में rollback बहुत आसान है। update करो, दिक्कत आए तो तुरंत पुराने version पर वापस जाओ, और debugging तब करो जब समय हो। और अगर cloud option आपके अनुभव में संतोषजनक है, तो वह भी बिल्कुल ठीक है। खुद setup करना निश्चित रूप से समय खाता है, इसलिए हर किसी के लिए cost-value comparison ज़रूरी है

    • मैं लगभग 12 self-hosted services चला रहा हूँ, और आम तौर पर upgrade में महीने भर में 1 मिनट भी नहीं लगता। हर service के लिए एक folder है, जिसके अंदर docker-compose stack और data folder है। update के लिए docker compose pull चलाता हूँ और up -d कर देता हूँ, बस। कभी-कभी कोई upgrade configuration change माँग सकती है, लेकिन ज़्यादातर काम कुछ मिनटों में खत्म हो जाता है। बिना VM के, सिर्फ Docker Compose के साथ पूरी तरह automated self-hosting ही मुझे सबसे simple तरीका लगता है

    • यह सिर्फ एक weekend project बनकर नहीं रहता। मेरे मामले में भी शुरुआत सिर्फ Plex install करने से हुई थी, और एक साल बाद यह Proxmox और तरह-तरह की home automation के साथ जुड़ी एक जटिल संरचना बन गई। आधा मज़ाक, आधा सच — अगर minimal setup चाहिए, तो docker compose से शुरुआत करें; management और upgrades दोनों आसान रहते हैं

  • मुझे समझ नहीं आता कि SSO तक जाने की सचमुच जरूरत है या नहीं। अगर परिवार/दोस्त wireguard client इस्तेमाल कर लें (iOS पर भी बहुत आसान है), तो बस एक toggle से वे घर के network से जुड़ सकते हैं और बिना अलग SSO के सारी internal services इस्तेमाल कर सकते हैं। छोटे घरेलू network में इसके फायदे कमियों से कहीं ज्यादा लगते हैं

    • हम जो Nextcloud, Mealie जैसी services इस्तेमाल करते हैं, उनमें per-user account पहले से built-in है। SSO की वजह से सब services में वही एक account इस्तेमाल हो जाता है, और मुझे passwords manage करने की जरूरत भी नहीं पड़ती। setup थोड़ा ज्यादा complex हो जाता है, लेकिन operations असल में आसान हो जाते हैं, इसलिए परिवार के लोग सचमुच इसका इस्तेमाल करें, इसकी संभावना भी बढ़ जाती है

    • मैं 20 apps self-host कर रहा हूँ, और अलग-अलग authentication संभालते-संभालते तंग आ चुका हूँ, इसलिए SSO ला रहा हूँ। जब परिवार के लिए भी कुछ apps खोलने हों, तो authentication को एक ही जगह handle कर पाना मेरे लिए सबसे बड़ा priority point है। ऊपर कही गई approach से मैं सहमत नहीं हूँ

  • flame इस्तेमाल करने की खास वजह क्या है? इससे node, react, redux जैसी दर्जनों या सैकड़ों third-party dependencies को अपने ‘security kingdom’ में बुलाया जाता है, जबकि एक simple start page तो शायद सिर्फ एक HTML page और links की सूची से भी बन सकता है

    • मैंने flame पहले इस्तेमाल किया हुआ था, इसलिए उससे परिचित था और उसी से तुरंत समस्या हल कर सका। उसका design भी पसंद है, और उसे Tailscale और Authelia के पीछे रखा है, इसलिए कोई खास security चिंता नहीं है। आगे चलकर alternatives भी देख सकता हूँ

  • मैं NixOS के साथ self-hosting करना चाहता तो हूँ, लेकिन अभी तक इसे अमल में नहीं ला पाया। मेरा environment कुछ VM और हर VM के लिए एक-एक docker compose file से manage होता है। ansible playbook सिर्फ compose files copy करती है, और Fedora Server OS को release से एक version पीछे रखता हूँ, फिर expiry पर upgrade कर देता हूँ। Mac पर nix-darwin चलाने की वजह से Nix configuration के फायदे समझता हूँ, लेकिन अभी तक मुझे यह नहीं लगा कि अपने पूरे environment को Nix में port करने से efficiency या time-to-value के लिहाज से बहुत बड़ा लाभ मिलेगा। हाँ, अगर LLM (बड़ा AI) config files dictation की तरह लिख दे, तो बात अलग हो सकती है, लेकिन फिलहाल चुनौती लेने की प्रेरणा कम है

    • मैंने भी NixOS आज़माया और एक हफ्ते के भीतर अपना home network और दो real servers तक migrate कर दिए। अब 3–4 महीने हो चुके हैं, और उम्मीद से कहीं ज्यादा संतुष्ट हूँ। server migration, workstation migration से भी आसान लगी। हाल में Jetson Orin Nano वाले अपने खिलौने को भी NixOS पर सेट करके खेल रहा हूँ। अगर पुराना Gentoo होता, तो यह सोच भी नहीं सकता था। Gentoo में सबसे ज़्यादा चिढ़ाने वाली चीज़ पुराने hardware पर बेहिसाब लंबे compile times थे। उदाहरण के लिए, 2019 XPS पर GHC build करने में 6 घंटे लग जाते थे

    • मेरे लिए NixOS का सबसे बड़ा फर्क यह रहा कि जब कुछ गड़बड़ हो जाए तो rollback बहुत आसान है। ansible या compose-based setup में भी backup/recovery किया जा सकता है, लेकिन वह system खुद लिखने का overhead रहता है। फिर भी, अगर आप अपने मौजूदा system से संतुष्ट हैं, तो वही अच्छी बात है

    • अगर आप पहले से कुछ हद तक IaC इस्तेमाल कर रहे हैं, तो NixOS से मिलने वाली अतिरिक्त efficiency उतनी बड़ी नहीं लगती