सेल्फ-होस्टिंग क्यों करनी चाहिए?

• पर्सनल सेवाओं की self-hosting के जरिए Big Tech और सरकार की निगरानी से दूर रहकर privacy और data sovereignty हासिल की जा सकती है
• कैलेंडर, contacts, location data जैसे संवेदनशील व्यक्तिगत डेटा हमारी अपेक्षा से कहीं अधिक जानकारी उजागर करते हैं, इसलिए Google या Apple जैसी कंपनियों पर निर्भर रहने के बजाय इन्हें खुद मैनेज करने की ज़रूरत है
• जब tech कंपनियाँ बिना वजह अकाउंट लॉक कर देती हैं या protocols की जगह proprietary API थोपती हैं, तब standard protocol आधारित अपना server चलाना digital sovereignty सुनिश्चित करता है
• CalDAV/CardDAV server, mail server, Home Assistant, RSS reader, location tracker जैसी व्यावहारिक self-hosting सेवाओं और ठोस software विकल्पों का परिचय दिया गया है
• शुरुआती setup की जटिलता के बावजूद, लंबी अवधि में डेटा पर नियंत्रण और service stability सुनिश्चित करना privacy protection और तकनीकी आत्मनिर्भरता के लिए महत्वपूर्ण है

---

सेल्फ-होस्टिंग क्यों चुननी चाहिए

• हाल ही में अपने Homelab environment को एक सहकर्मी के साथ साझा करते समय मुझसे पूछा गया, “आख़िर तुम खुद server क्यों सेट करते हो, containers क्यों configure करते हो, hardware पर इतना पैसा क्यों खर्च करते हो, और यह सब झंझट क्यों उठाते हो?”
• इसी सवाल के बहाने self-hosting के मुख्य कारणों और वास्तव में किन सेवाओं को self-host किया जा सकता है, यह विस्तार से समझाया गया है

प्राइवेसी

• प्राइवेसी अपने आप मिलने वाला अधिकार नहीं है, बल्कि इसके लिए संघर्ष करना पड़ता है
• Big Tech कंपनियाँ और कुछ सरकारें (जैसे EU का chat control) लगातार लोगों की निजी ज़िंदगी में झाँकने की कोशिश करती रहती हैं
• अगर आप अपनी सेवाएँ खुद host करते हैं, तो निगरानी के जोखिम को कम या खत्म किया जा सकता है, लेकिन इसके लिए तकनीकी ज्ञान ज़रूरी है
• परिवार या परिचितों को भी अपनी सेवाएँ देकर उनकी data independence बढ़ाने में मदद की जा सकती है

• कैलेंडर & contacts

  • कैलेंडर हमारी सोच से कहीं ज़्यादा जानकारी उजागर करता है
    • पहचान संबंधी जानकारी के अलावा नियमित मुलाकातें, परिवार, सहकर्मी, और गोपनीय business meetings की जानकारी
    • medical appointments के ज़रिए स्वास्थ्य संबंधी जानकारी, नींद और exercise routine
    • कानूनी ज़िम्मेदारियाँ, loan schedule या subscription जैसी financial जानकारी
    • protest में शामिल होने के शेड्यूल से राजनीतिक विचारों का अंदाज़ा
    • कब आपसे संपर्क किया जा सकता है, यह समझकर identity theft में उपयोग संभव
  • contact data भी उतना ही संवेदनशील है
    • social graph और metadata (search history, creation date) के ज़रिए निजी जानकारी का अनुमान लगाया जा सकता है
    • उदाहरण: अगर अचानक समान gender के केवल नाम वाले contacts बढ़ जाएँ, तो यह अनुमान लगाया जा सकता है कि आप dating कर रहे हैं; therapist का contact बनना मानसिक स्वास्थ्य उपचार का संकेत हो सकता है
  • अधिकतर लोग यह समझते ही नहीं कि social graph data कहाँ store होता है, जबकि व्यवहार में इसे Google, Apple, Samsung जैसी कंपनियाँ प्रोसेस करती हैं
  • Apple की Advanced Data Protection में भी कैलेंडर और contacts end-to-end encrypted नहीं होते

• location data

  • कई साल पहले Android और Google Maps इस्तेमाल करते समय मुझे अपने Google account में कई वर्षों का विस्तृत location history मिला
    • ऐसा फीचर, जिसे मैंने कभी खुद चालू नहीं किया था, अपने आप हर आवाजाही और हर visit को geocoordinates के साथ रिकॉर्ड कर रहा था
  • यह अनुभव आकर्षक भी था, लेकिन डराने वाला भी, और इससे यह चाह पैदा हुई कि डेटा पर सीधा नियंत्रण हो और सिर्फ़ मेरी पहुँच हो

• इसके अलावा

  • डेटा को ट्रैक करने के सभी तरीकों और उनसे सतर्क रहने की वजहों की पूरी सूची देना इस लेख की सीमा से बाहर है
  • उद्देश्य सिर्फ़ इतना है कि आप अपनी नई यात्रा शुरू करने के लिए प्रेरित हों

स्वायत्तता

• digital sovereignty का मतलब है अपने डेटा को नियंत्रित करना, यह तय करना कि उसके साथ क्या किया जाए, और यह नियंत्रित करना कि उसे किसके साथ साझा किया जाए

• अकाउंट लॉक होने की समस्या

  • tech कंपनियों द्वारा बिना किसी स्पष्ट कारण अकाउंट लॉक कर देने की घटनाएँ लगातार सामने आती रहती हैं, और ऐसा मैंने अतीत में Google के साथ खुद झेला है
  • मैं ऐसी Big Tech कंपनियों की दया पर निर्भर नहीं रहना चाहता जिनसे संपर्क तक नहीं हो पाता या जहाँ AI chatbot से जूझना पड़ता है
  • यह सवाल बना रहता है कि regulator tech कंपनियों से किसी वास्तविक इंसान से संपर्क का तरीका उपलब्ध कराने की माँग क्यों नहीं करते

• protocols और standards

  • मैं protocols और file standards को प्राथमिकता देता हूँ
    • “Gmail” API के बजाय SMTP और IMAP का उपयोग (ये पुराने हैं, लेकिन फिलहाल सबसे बेहतर विकल्प हैं; नई JMAP initiative का स्वागत है)
  • Microsoft जैसी Big Tech कंपनियाँ AI-Copilot integrated Office 365 software का उपयोग थोपती हैं, और हाल ही में Office 365 accounts के SMTP access को भी disable कर चुकी हैं

क्या self-host करना चाहिए

• hardware

  • मैं enum.co नाम की कंपनी में काम करता हूँ, जहाँ digital sovereignty को महत्व दिया जाता है
  • फिलहाल 3 mini servers से बना high-availability Kubernetes cluster चला रहा हूँ (इसे setup करने में मेरे बॉस की मदद मिली)

• कैलेंडर & contacts

  • चूँकि यह संवेदनशील डेटा है, इसलिए मैं अपना CalDAV/CardDAV server host कर रहा हूँ
  • server विकल्प:
    • Radicale: Python आधारित, basic web UI, केवल single-user support, Apple devices के साथ compatible नहीं
    • ⭐ अनुशंसित Baïkal: PHP आधारित, सक्रिय development, उन्नत web UI, multi-user support
    • DAViCal: PHP आधारित, मैंने आज़माया नहीं
    • Xandikos: Python आधारित, built-in authentication नहीं, web UI नहीं
    • Nextcloud: PHP आधारित, अगर पहले से इस्तेमाल कर रहे हैं तो ठीक है, लेकिन बहुत heavy है
  • कैलेंडर और contact data के प्रति सजग होने का मतलब यह भी है कि किन apps को access permission है, इसकी समीक्षा की जाए

• mail

  • self-hosted mail server लंबे समय से taboo माना जाता रहा है, लेकिन वास्तव में यह उतना कठिन नहीं है
  • Stalwart या Mailcow जैसे हाल के समाधान personal mailbox hosting को आसान बनाते हैं (marketing mail के लिए नहीं)
  • घर से host करना recommended नहीं है (static IP चाहिए, और पूरे internet से पहुँचा जा सकना चाहिए)
  • setup steps:
    • किसी भरोसेमंद hosting provider का चयन
    • clean IP address हासिल करना (mail blacklist चेक करके, ज़रूरत पड़े तो दोहराएँ)
    • server setup के बाद यह जाँचना कि mail receive हो रहा है और सभी protocols सही तरह configure हैं
    • internet.nl online testing tool से verify करना
    • Google, Microsoft, Yahoo addresses पर mail भेजकर देखना कि spam में तो नहीं जा रहा
    • DNS, DMARC, SPF, TLS आदि को बार-बार जाँचना
  • आगे इस पर एक विस्तृत blog post लिखने की योजना है

• smart home

  • कई साल पहले मैंने Home Assistant instance host करना शुरू किया था; उस समय Apple Homekit मेरे लिए काफ़ी था, लेकिन यह एक प्रयोग के तौर पर शुरू हुआ
  • उसके बाद कई smart home कंपनियाँ बंद हो गईं, उनकी cloud services बंद हुईं, prices बढ़ीं, या free services paid हो गईं
  • कुछ हफ़्ते पहले जब यह खबर मिली कि Philips Hue अब users को account बनाने के लिए मजबूर कर रहा है, तब Home Assistant की अहमियत साफ़ दिखी
    • जिन lights के लिए आप पहले ही पैसे दे चुके हैं, उनकी सारी functionality इस्तेमाल करने के लिए account चाहिए
    • मैं हमेशा smart home devices के external network traffic को block करने के लिए firewall rules सेट करता आया हूँ
    • ऐसा लगता है कि local network पर भी Philips Hue app-only features (जैसे candle simulation animation) का उपयोग नहीं किया जा सकता
    • उम्मीद है कि इस feature को emulate करने वाला कोई community plugin हो
  • सिर्फ़ local use वाले devices के लिए मैं कभी online account नहीं बनाऊँगा
  • इन दिनों मैं energy usage tracking में काफ़ी रुचि ले रहा हूँ, और machine vision के जरिए gas meter की energy usage track करने वाला Raspberry Pi + camera device बनाने की योजना है

• RSS aggregator

  • मैं RSS के ज़रिए कई news sites और blogs subscribe करता हूँ, और RSS खुद में पहले से ही decentralized और sovereign है
  • इसलिए RSS aggregator की self-hosting वैकल्पिक है और आख़िरी चरण जैसा है
  • iPhone और Mac पर मैं NetNewsWire इस्तेमाल करता हूँ
    • यह बेहतरीन RSS reader है, open source है, और शानदार लोगों द्वारा supported है
    • FreshRSS के साथ native integration देता है
  • FreshRSS feed aggregator के रूप में filtering जैसी और अधिक सुविधाएँ देता है
    • ऐसे sources को भी subscribe किया जा सकता है जो by default RSS feed नहीं देते

• location tracker

  • मैंने dawarich instance deploy किया है (जर्मन में अर्थ: “मैं वहाँ था”)
    • यह geolocation data collect और view करने वाला server है
    • वर्तमान location को server तक भेजने के लिए कई mobile apps में से चुनाव किया जा सकता है
  • उपलब्ध apps:
    • official dawarich app: iOS notch में हमेशा navigation icon दिखाता है
    • Overland: battery बहुत ज़्यादा खपत करता है
    • ⭐ Owntracks: iOS पर सबसे अच्छा चलता है, लेकिन app settings बहुत उलझी हुई हैं
    • PhoneTrack

आइडिया & आगे की दिशा

• हाल ही में मैंने अपने homelab को फिर से तैयार करके एक बड़े single server से 3-node Kubernetes cluster में बदला है
  • इससे host की जा सकने वाली applications के प्रकारों में काफ़ी अधिक flexibility मिली है
• apps और tools की सूची जिन्हें मैं देखना चाहता हूँ:
  • EteSync: end-to-end encrypted CalDAV & CardDAV
  • AnyType: अपना AnyType server instance host करना
  • Immich या ente: iCloud Photos से self-hosting की ओर जाना
  • Passbolt: password manager (Bitwarden पसंद नहीं)
  • BirdNET: माइक्रोफोन के जरिए बाहरी पक्षी प्रजातियों की monitoring
  • penpot: Figma जैसा, लेकिन free & open source
  • Habitica: habit manager
  • vert: file converter
  • InvoiceShelf: invoice manager
• selfh.st self-host किए जा सकने वाले applications खोजने के लिए एक शानदार resource है

[GN⁺]

Hacker News राय

• मैं यह कहना चाहता हूँ कि सिर्फ़ personal services को खुद self-host करना ही नहीं, बल्कि software या SaaS small businesses को भी ज़्यादा direct hosting approach पर विचार करना चाहिए
  cloud vendors complexity और scale की वजह से दावा करते हैं कि वे अनिवार्य हैं, लेकिन वास्तव में ज़्यादातर software projects या businesses को उसकी उतनी ज़रूरत नहीं होती
  उदाहरण के लिए, NextJS deploy करने के लिए Vercel या Netlify पर निर्भर होने की कोई मजबूरी नहीं है; Ubuntu वाले VPS पर Nginx या Caddy (मुझे Caddy पसंद है) चलाना काफ़ी है
  लगभग 90% से ज़्यादा projects के लिए नीचे दिए गए तरीके से self-hosting काफ़ी है

  • एक अच्छी तरह secured VPS और ज़रूरी security controls लागू करना (root login disable, SSH key-based login आदि)

  • Caddy/Nginx जैसे reverse proxy की setup से static files या website serve की जा सकती हैं; अगर रोज़ लाखों requests नहीं हैं तो CDN भी ज़रूरी नहीं

  • Supervisor या systemd से backend/API चलाना

  • वही reverse proxy backend और दूसरी services को भी proxy कर सकता है

  • mysql/postgres database खुद चलाना और security settings लागू करना

  • backup scripts/cron से सब backups संभव हैं, और उन्हें नियमित रूप से test करना चाहिए

  • DOS/DDOS protection के लिए Cloudflare layer जोड़ी जा सकती है
    आख़िर में architecture कुछ ऐसा बनता है: Cloudflare/DNS→Reverse Proxy(Caddy/Nginx)→app
    deployment के लिए ज़्यादातर मामलों में git pull ही काफ़ी है, और ज़रूरत हो तो extra build steps भी जोड़े जा सकते हैं
    Docker या containers भी अनिवार्य नहीं हैं; small to medium projects के लिए इनके बिना भी काम चल जाता है
    यह मुश्किल लग सकता है, लेकिन वास्तव में उतना मुश्किल नहीं है; ज़्यादातर projects को बड़े webscale की ज़रूरत नहीं होती

  • मेरे लिए सबसे चिंताजनक बात पूरी OS को manage करने से जुड़ा security risk है, जिसमें kernel और userland दोनों शामिल हैं
    firewall सही तरह configured है या नहीं, और latest CVE पर जल्दी response हो रहा है या नहीं, यह चिंता रहती है
    इसलिए मुझे उल्टा यह ज़्यादा stable लगता है कि GitHub Actions से workflow बनाया जाए → container image build करके private registry में push किया जाए → k8s config के ज़रिए वही image service पर deploy की जाए
    यह सीधे VM पर deploy करने जितना ही simple है, और इससे मुझे सिर्फ़ अपने app और उसके interface की ज़िम्मेदारी लेनी पड़ती है

  • मैंने canine.sh इसी वजह से बनाया, क्योंकि मैं ऊपर बताई गई सारी setup को one-click बनाना चाहता था
    पहले मैंने एक छोटे SaaS को co-found किया था, और हमारा cloud bill सालाना 5 लाख डॉलर से ऊपर था
    production चलाते हुए जल्दी समझ आ गया कि sentry ज़रूरी है, और server logs में errors ढूँढने के बजाय cloud sentry लगभग 40 डॉलर प्रति माह में मिल जाता था
    data monitoring के लिए datadog भी चाहिए था, जिस पर 300 डॉलर महीना लगता था
    customer presentations के dashboards के लिए Looker/Tableau/Omni जैसे BI tools पर सालाना 20,000 डॉलर
    data warehouse और replication पर सालाना 150,000 डॉलर
    ऐसी external services की लागत लगातार जुड़ती जाती है, और आख़िरकार मैं इस निष्कर्ष पर पहुँचा कि इन external services को अपनी infra पर maintain और operate करना सबसे बेहतर है
    उदाहरण के तौर पर Cloud Sentry→Self Hosted Sentry, Datadog→Prometheus/Grafana, Looker→Metabase, Snowflake→Clickhouse, ETL→Airbyte
    यही वजह है कि ज़्यादातर कंपनियाँ आख़िर में Kubernetes चुनती हैं
    indie hackers को शायद समझ न आए कि Kubernetes की complexity क्यों चाहिए, लेकिन यही वजह है कि सब कुछ एक single VPS पर नहीं रखा जा सकता

  • मैं इस बात से सहमत हूँ कि “ज़्यादातर projects को webscale की ज़रूरत नहीं होती”
    आजकल major cloud platforms की marketing देखकर लगता है कि YAGNI (You Ain't Gonna Need It) infra पर भी लागू होता है
    मैं 2000 के शुरुआती दशक से sysadmin के रूप में काम कर रहा हूँ, इसलिए यह देखना मज़ेदार है कि लोग अपनी services को खुद host करने की धारा को किसी innovation की तरह देख रहे हैं
    Docker आने से पहले भी हम LXC, BSD Jails आदि से code isolation करते थे; यह DevOps से भी पुरानी परंपरा है
    आज के developers को यह सब नए सिरे से खोजते देखना दिलचस्प है
    आख़िर में, पुराने अनुभवी sysadmins के साथ काम करना या उनके साथ कॉफ़ी पर बैठकर मदद लेना अच्छा रहेगा
    बहुत से लोग अभी भी पुराने तरीके से infra manage करने में खुश होते हैं, और उनके पास काफ़ी practical know-how होता है

  • self-hosting का एक और फ़ायदा यह है कि cloud services के उलट, system skills और knowledge ज़्यादा portable होती हैं
    अगर आपने systemd, ufw, ssh का काम करना सीख लिया, तो वह दूसरे systems पर भी सीधे लागू होता है
    उल्टा मुझे लगता है कि Docker और container layer-by-layer builds तथा तरह-तरह की tricks सीखने में लगने वाला समय और लागत, एक सामान्य Debian web server manage करने से ज़्यादा है

  • कुल मिलाकर मैं सहमत हूँ, और अपनी राय साझा करने के लिए धन्यवाद
    एक बात जहाँ मैं अलग सोचता हूँ, वह है “CDN सिर्फ़ बड़े scale पर चाहिए”
    मेरे हिसाब से CDN सिर्फ़ origin requests बाँटने के लिए नहीं, बल्कि user experience में latency कम करने के लिए भी अहम है
    महसूस होने वाली speed दरअसल सबसे महत्वपूर्ण features में से एक है; premature optimization से सावधान रहना चाहिए, लेकिन कम से कम static assets को users के पास edge से serve करना पिछले 10 साल से baseline spec जैसा हो चुका है

• शानदार विषय है, और मैं अपने अनुभव के आधार पर एक नज़रिया साझा कर सकता हूँ
  खुद homelab चलाने का सबसे बड़ा फ़ायदा cost savings या data privacy भर नहीं, बल्कि असली गहराई वाला practical knowledge पाना है
  Docker, networking, Linux administration के बारे में पढ़कर सीखना एक बात है, और अपने परिवार द्वारा इस्तेमाल की जाने वाली services को खुद चलाते हुए DNS बंद हो जाए या Docker container reboot के बाद fail हो जाए और आपको खुद उसे ठीक करना पड़े, यह बिल्कुल दूसरी बात है
  लेकिन इसमें एक दूसरी हक़ीक़त भी है
  शुरुआत में यह एक मज़ेदार project होता है, लेकिन जैसे ही आप password manager या file sync जैसी critical services भी self-host करने लगते हैं, आप 24/7 on-call owner बन जाते हैं
  backups, security patches, uptime—सबकी ज़िम्मेदारी आपकी होती है, और उस बिंदु पर यह सिर्फ़ hobby नहीं रह जाती, बल्कि “job” बन जाती है
  आख़िरकार self-hosting data control और बड़ी satisfaction दोनों दे सकता है, लेकिन यह SaaS की cost को आपके समय और mental load के रूप में IT admin की भूमिका से replace कर देता है
  फिर भी, HN users के लिए यह करने लायक चीज़ है

• मैंने लिखा था कि मैं खुशकिस्मत हूँ कि enum.co जैसी कंपनी में काम कर सकता हूँ जो digital sovereignty को महत्व देती है, लेकिन जब मैंने info.addr.tools से mail server देखा, तो MX smtp.google.com निकला और TXT records में भी Google की कई properties थीं
  यह सिर्फ़ कोई “नारा” नहीं, बल्कि DNS में दिखने वाली हक़ीक़त है
  digital sovereignty की बात करते हुए Google mail service पर निर्भर रहना विरोधाभासी है
  https://info.addr.tools/enum.co

  • enum के बचाव में कहूँ तो, उनकी services k8, S3-compatible storage, और DevOps से जुड़ी हैं
    अगर वे self-hosting/email sovereignty बेच रहे होते और खुद gmail इस्तेमाल कर रहे होते, तो बात बिल्कुल अलग होती
    वे पूरी तरह 100% independent नहीं हैं, और OP ने भी यह कहा था कि “self-hosted mail server को अक्सर बहुत बड़ा taboo समझा जाता है, लेकिन उससे उतना डरने की ज़रूरत नहीं”
    सभी इस issue को समझते हैं, और सुधार की गुंजाइश अभी भी है

  • नमस्ते, मैं enum का founder हूँ
    वह बात सही है और अच्छा point है
    सच कहूँ तो, हमने अपने internal email के लिए Google Workspace इसलिए चुना क्योंकि शुरुआत में core product development पर focus करना एक practical choice था
    startups में यह बहुत आम choice है, और हम आने वाले कुछ हफ़्तों में switch करने वाले हैं
    लेकिन हमारी customer-facing platform और सारा data हमेशा 100% sovereign रहा है
    infra पूरी तरह Big Tech से independent है
    यह बात उठाने के लिए धन्यवाद

  • सिर्फ़ email को मैं self-hosting का exception मानता हूँ
    मैं बाकी सारी services self-host करता हूँ, लेकिन email 3rd party को देता हूँ

  • DNS में Google-related records होने की बात को इतनी मज़बूती से पकड़ने पर मैं प्रभावित हूँ
    सच में काबिल-ए-तारीफ़ है

  • TXT में मौजूद "google-site-verification=..." वाला हिस्सा अपने-आप में कोई “बुरी” चीज़ नहीं है; यह एक practical compromise है ताकि Google mail भेजते समय आपको spam न माने

• अगर email self-host कर रहे हों, और digital sovereignty privacy से ज़्यादा महत्वपूर्ण हो
  तो मैं gmail पर custom domain इस्तेमाल करता हूँ, और अपना email server self-host करके mbsync से gmail से emails लगातार download करता रहता हूँ
  storage और reading मेरे server पर होती है, लेकिन sending के लिए अभी भी gmail का इस्तेमाल करता हूँ
  अगर Google मेरे account access को block भी कर दे, तब भी emails मेरे पास रहेंगी, और provider बदलना हो तो सिर्फ़ DNS बदलना होगा
  sent mail की deliverability की भी समस्या नहीं होती

  • मैंने SPF, DMARC जैसी DNS settings के साथ 6 साल पहले mail self-hosting शुरू की थी
    मुझे मुश्किलें सिर्फ़ एक-दो बार हुईं, और ज़्यादातर परेशानी services, random outages, IP changes, backup automation वगैरह से आई; mail server खुद उतनी समस्या नहीं बना
    बल्कि mail server तो बस चुपचाप ठीक से चलता रहता है

  • अगर पूछें कि mail sending भी self-host क्यों नहीं करते
    तो शायद वजह deliverability issue है?

  • email की असली sovereignty custom domain पर निर्भर करती है
    अगर वह सुरक्षित आपके पास है, तो आप कभी भी कई providers में से चुन सकते हैं और आसानी से move कर सकते हैं

• self-hosting वाकई शानदार है
  एक साल पहले software engineer से SaaS founder बनने की शुरुआत करने के बाद से मैं Coolify और Hetzner के 20 डॉलर वाले server पर Postgres, पुराना Minio, Nuxt, NextJs, Umami analytics, Open WebUI, static sites आदि खुद host कर रहा हूँ
  शुरुआत में सीखना पड़ा, लेकिन setup पूरा होने के बाद नई service उठाना plug-and-play जितना आसान हो गया
  मैं अभी server resources का 1/4 भी इस्तेमाल नहीं कर रहा (users कम हैं, haha)
  https://coolify.io/docs/

• मैं IT professional हूँ, लेकिन घर पर self-hosting या NAS setup को टालता रहा और आख़िरकार Ugreen NAS का 4-bay model खरीदकर तुरंत TrueNAS CE install कर लिया
  मैंने ChatGPT को अपना docker-compose file वगैरह context भी दिया और उसी के साथ setup किया
  Docker, networking आदि का मुझे पुराने student days से थोड़ा-बहुत अनुभव था, उसके अलावा लगभग कोई knowledge नहीं थी
  लेकिन अब मैं यह सब चला रहा हूँ

  • कई Dockerized apps
  • हर app stack के लिए अलग network
  • Traefik+Docker labels से web UI exposure manage करना
  • सिर्फ़ Traefik port 443 को बाहर खोलना, और port forwarding केवल ज़रूरत पर
  • optional Cloudflare tunnels
  • domain के लिए automatic Traefik TLS termination (LAN/WAN दोनों)
  • LAN/WAN के लिए Split-DNS
  • सभी exposed containers पर CrowdSec
  • Cloudflare से exposed services पर MFA
  • Technitium से local DHCP/DNS
  • automatic ZFS snapshots/remote backups
  • DB, logs जैसी volatile data SSD पर, और बड़े files HDD पर
    इसी तरह चला रहा हूँ

• self-hosting अच्छा है, लेकिन असली समस्या backups और upgrades हैं
  मैं कई resources self-host करता हूँ, लेकिन critical data या ऐसी चीज़ें जिन पर दूसरे लोग निर्भर हों, उन्हें खुद host नहीं करता
  अगर app recovery या upgrade आसान न हो, तो मैं उस पर निर्भर नहीं होता
  सच कहूँ तो self-hosted apps में बहुत कम ऐसे हैं जिनका backup/restore एक-दो lines में हो जाए
  वैसे, घर पर सुरक्षित self-hosting के लिए Tailscale और Pangolin किसी वरदान से कम नहीं हैं

  • मैं जानना चाहूँगा कि आप किस तरह का backup solution expect करते हैं
    मेरी सारी self-hosted apps Docker में चलती हैं, इसलिए container volume folders और docker-compose.yml का backup काफ़ी है
    restore करने के लिए folder वापस रखो और docker compose up चलाओ, बस
    मुझे नहीं लगता कि हर app में अलग backup feature implement करना चाहिए; वह developers के समय की बर्बादी है

  • Tailscale की जगह self-hosted netbird ज़ोरदार सिफ़ारिश है
    उस पर बहुत active development हो रहा है, और UI भी शानदार है
    https://github.com/netbirdio/netbird

  • Pangolin क्या है, यह जानने की जिज्ञासा है
    search करने पर तो बस जानवर ही दिखता है

• मेरा self-hosting stack

  1. immich
  2. jellyfin
  3. ghost
  4. wallabag
  5. freshrss
  6. vaultwarden
  7. nextcloud
  8. overleaf/sharelatex
  9. matrix server
  10. atproto के लिए pds
  • मैं जानना चाहूँगा कि आप upgrades कैसे करते हैं, security patches कैसे apply करते हैं, backups कैसे करते हैं, और क्या उन्हें नियमित रूप से test भी करते हैं
    कई बार latest version upgrades या security patch guidance कमज़ोर होती है, या फिर सभी versions को क्रम से पार करना पड़ता है

• अगर “self-hosting” को बहुत ज़्यादा सिर्फ़ घर के server तक सीमित कर दिया जाए, तो वह हमेशा niche ही बना रहेगा
  हमें open source non-subscription apps, पुराने तरह के Windows PC applications, आसानी से portable cloud apps—यानी SaaS से बाहर हर तरह के विकल्प को बढ़ावा देना चाहिए
  मेरा मानना है कि असली self-hosting का लक्ष्य किसी भी तरह के lock-in से बचना और users को control देना है

  • फिर भी, शब्द का अर्थ इतना धुंधला नहीं होना चाहिए
    कोई cloud app standard protocol से portable हो, तब भी अगर वह आपके अपने ownership/control वाले server पर नहीं है, तो operator कभी भी data policy या collection policy बदल सकता है
    आपको यक़ीन नहीं हो सकता कि data अचानक collect नहीं किया जाएगा, या service बंद होने से पहले data migration संभव होगा भी या नहीं

  • Windows installable software भी self-hosting की category में आ सकता है
    असल में कई लोग Windows executable या Docker से शुरू करते हैं और फिर धीरे-धीरे आगे बढ़ते हैं

  • कम-से-कम, अगर आपके पास root access है और आप किसी दूसरे के datacenter (जैसे colocation) में server चला रहे हैं, तो उसे भी self-hosting मानना चाहिए

• 20 साल पहले दादाजी लोग भी limewire.com से setup.exe डाउनलोड करके next->next->next दबाकर एकदम सही file server और client install कर लेते थे
  2007 में दुनिया के 1/3 computers पर limewire था
  लेकिन आज बहुत basic self-hosting software भी practically सिर्फ़ pro engineers ही install कर सकते हैं
  SSH, Docker, Tailscale, TLS certificates जैसी complex चीज़ें manage करनी पड़ती हैं, ऊपर से backups और न जाने कितनी automation...
  सोचता हूँ कि ऐसा “self-hosting” software apt-get install जितना आसान क्यों नहीं होता
  इसी वजह से कोई भी खुद host नहीं करता
  https://en.wikipedia.org/wiki/LimeWire

  • कुछ software सच में apt-get install से install हो जाते हैं, लेकिन अगर आप उसे internet पर expose करना चाहते हैं, तो domain name और HTTPS setup से शुरुआत करनी पड़ती है
    Limewire या BitTorrent जैसे clients domain के बिना इसलिए चल जाते थे क्योंकि उनके पीछे central servers (जैसे trackers) थे

  • बहुत से लोग limewire जैसे installer को self-hosting नहीं मानेंगे
    वह बस local program install करना है

  • Ubuntu ने snap के ज़रिए server-side apps को आसानी से install करने लायक बनाना चाहा था, लेकिन community के तेज़ विरोध की वजह से बात नहीं बनी
    snap की अपनी कमियाँ हैं, लेकिन वह format server apps deploy करना आसान बनाने के लिए बनाया गया था
    उदाहरण के तौर पर, आज भी nextcloud को snap से install किया जा सकता है
    यह कुछ वैसा है जैसे perfection के चक्कर में practical “good enough” को भी ठुकरा दिया गया हो

  • Limewire एक client था, server नहीं
    सही upload के लिए firewall/port forwarding करना पड़ता था, और UPnP allow करना भी पड़ सकता था (जिसकी मैं सिफ़ारिश नहीं करता)
    self-hosted servers पूरी तरह अलग दुनिया हैं
    एक ऐसी दुनिया जहाँ beginners भी शायद सब auto कर सकते थे, लेकिन malicious hackers की वजह से setup और operations की कठिनाई बढ़ गई
    experts भी pro penetration testers या nation-state hackers के सामने असुरक्षित रह सकते हैं

  • मुझे लगता है कि आजकल software development खुद ही बहुत ज़्यादा complex हो गया है
    यह कुछ-कुछ ऐसी bureaucracy जैसा है जो अपने jobs बनाए रखने के लिए बेकार की समस्याएँ पैदा करती है
    ज़्यादातर लोगों को self-hosting तक की ज़रूरत नहीं होती; बस software computer पर चले और कभी-कभी local network से access हो जाए, इतना काफ़ी है
    लेकिन business model नहीं है, और developers special layers तथा बेवजह की complex architecture पर अटके रहते हैं
    नतीजा यह होता है कि server software, webview-based apps, data और local environment के बीच दूरी, और manage करने के लिए और devices बढ़ते जाते हैं
    ज़्यादातर computers खाली पड़े रहते हैं, जबकि सिर्फ़ admin layers बढ़ती जाती हैं
    मुझे लगता है कि laptop trends भी इस गड़बड़ी का हिस्सा हैं
    अच्छे local Mac apps गायब हो गए हैं, और cloud subscription-based products की भरमार है
    open source में भी आख़िरकार Docker images, complex configuration, और ढेर सारे gotchas मिलते हैं
    अगर simple install और management संभव होता, तो लोग इसके लिए पैसे भी देने को तैयार होते
    लेकिन अभी तो यह भी पता नहीं चलता कि कितना समय लगेगा, इसलिए लोग बस Big Tech पर छोड़ देते हैं
    web technologies interactive documents के लिए अच्छी हैं, लेकिन इस use case से बाहर अब भी usability की बड़ी समस्याएँ हैं