Heroku के $3,000/महीने के बिल को $55/महीने के सर्वर से बदलना

• गैर-लाभकारी जॉब प्लेटफ़ॉर्म Idealist ने Heroku पर आने वाली महंगी staging environment लागत की समस्या हल करने के लिए कम-लागत वाले dedicated server पर माइग्रेट किया
• Heroku में environment-आधारित billing structure के कारण, हर staging environment की लागत लगभग $500/महीना तक पहुंच रही थी
• इसके विकल्प के रूप में Hetzner CCX33 server ($55/महीना) एक पर कई environments बनाए गए, और Disco के जरिए Heroku जैसा git push और automation अनुभव बरकरार रखा गया
• एक ही सर्वर पर 6 staging environments स्थिर रूप से चल रहे हैं, और CPU usage 2% तथा memory usage 32GB में से 14GB के स्तर पर है, यानी पर्याप्त headroom मौजूद है
• इसके बाद staging environments ‘लागत का बोझ’ से ‘आसानी से बनाए जा सकने वाले resource’ में बदल गए, जिससे development team की experimentation और deployment culture में बड़ा सुधार हुआ

---

व्यावहारिक Heroku लागत-कटौती रणनीति का अनुभव

समस्या: $500/महीने का staging environment

• Idealist.org एक बड़ा गैर-लाभकारी जॉब प्लेटफ़ॉर्म है, जहाँ हर महीने लाखों लोग आते हैं, इसलिए production environment के लगभग समान staging environment आवश्यक है
• Heroku में web·worker dyno और Postgres जैसे ज़रूरी add-ons को मिलाकर एक staging environment की लागत लगभग $500/महीना थी
• सिर्फ dev और main दो environments बनाए रखने पर भी $1,000/महीने से अधिक का fixed cost बन रहा था
• Heroku का pricing model environment-आधारित billing model है, इसलिए dyno कम करने पर भी बचत सीमित रहती है, और application बढ़ने के साथ लागत तेज़ी से बढ़ती है

प्रयोग: single server पर माइग्रेशन

• आदर्श लागत-कटौती के लिए एक Hetzner CCX33 server ($55/महीना) किराये पर लेकर प्रयोग शुरू किया गया
• Disco solution का उपयोग करके Heroku की मौजूदा git push deployment style को सर्वर पर लगभग वैसे ही लागू किया गया
• सभी staging environments में उसी सर्वर के shared Postgres instance का उपयोग किया गया, जिससे managed database की लागत काफी कम हो गई
• testing के लिहाज़ से, developer-वार अलग databases को आसानी से reset किया जा सकता था, इसलिए यह setup उपयुक्त रहा

Disco क्यों: Docker Compose से अलग क्या

• सिर्फ सर्वर पर docker-compose up चलाना developer experience के लिए पर्याप्त नहीं था
• Disco ने ये फायदे दिए
  • Heroku जैसा git push deployment process
  • हर deployment के लिए automatic zero-downtime deployment support
  • branch-आधारित URL के लिए automatic SSL certificate issuance और renewal
  • logs और environment management के लिए सहज web UI
• इस तरह अपनी deployment automation बनाकर और maintain करके अलग मेहनत किए बिना, developer convenience वैसी ही बनी रही

staging environments का विस्तार और server resource efficiency

• Disco के उपयोग से staging environments को बढ़ाना बहुत आसान हो गया
• एक सर्वर पर एक साथ ये environments चलाए जा रहे हैं
  • main branch
  • feature-freeze branch
  • अस्थायी PR के लिए throwaway environment
  • बड़े feature development के लिए long-lived environment आदि
• कुल 6 स्वतंत्र staging environments बिना किसी समस्या के चल रहे हैं
• Heroku पर इसके लिए $3,000/महीना लगते, लेकिन Hetzner पर सिर्फ CPU 2%, memory 14GB (32GB में से) ही उपयोग हो रही है, यानी बहुत कम-लागत वाला ढांचा

trade-offs और व्यावहारिक विचार

• यह पूरी तरह परफेक्ट विकल्प नहीं है, और कुछ operational burden बढ़ता है
• हर नए environment के लिए DNS, CDN setup जैसी infrastructure tasks अभी automated नहीं हैं
• server monitoring, security updates, और outage की स्थिति में response जैसी operational responsibility भी आती है
• Hetzner में US regions सीमित हैं, इसलिए अमेरिकी users को target करने वाली production service के लिए यह उपयुक्त नहीं हो सकता
• server failure की स्थिति में reinstall स्वीकार करनी पड़ सकती है, यानी availability trade-off मौजूद है
• application को Docker networking के अनुसार ढालने में लगभग एक दिन का engineering effort लगा

मिले insights और बदलाव

• 6 महीने से अधिक समय तक चलाने के बाद यह infrastructure स्थायी setup की तरह स्थापित हो गया
• सबसे बड़ा बदलाव सिर्फ लागत-कटौती नहीं, बल्कि staging environment को भरपूर और स्वतंत्र resource के रूप में देखने का बदलाव था
• अब developers बिना approval या लागत की चिंता के, ज़रूरत पड़ने पर pull request-आधारित environments स्वतंत्र रूप से बना सकते हैं
• टीम ने यह सीखा कि सिर्फ लागत नहीं, बल्कि इस्तेमाल करने में हिचकिचाहट भी असली नुकसान थी
  • "आर्थिक बोझ development speed और experimentation को सीमित कर रहा था"

[GN⁺]

Hacker News राय

• htop का स्क्रीनशॉट देखकर सबसे पहले यह दिखा कि swap नहीं है, इसलिए सिफारिश है कि जब कोई सर्विस असामान्य रूप से memory खा जाए तो पूरे server के डाउन होने से बचाने के लिए earlyoom चालू किया जाए; Linux kernel का OOM killer आमतौर पर बहुत देर से सक्रिय होता है। zram चालू करके RAM को compress कर pro की तरह overprovisioning करने का तरीका भी है। लंबे समय तक चलने वाले software में अक्सर memory leak हो जाते हैं, और compress करने पर यह काफ़ी असरदार होता है। Hetzner bare metal server पर Ansible से इसे लागू करने का तरीका एक gist में लिखा है, और VM पर भी यही काम करता है.

  • इससे बिल्कुल सहमत नहीं हूँ। एक बार swap तक पहुँच गए तो ज़्यादातर apps गंभीर समस्या झेलते हैं। यह बहुत अच्छी तरह जाना-पहचाना तथ्य है, और AWS EC2 instances में भी swap डिफ़ॉल्ट रूप से बंद रहता है। हाँ, AWS ज़्यादा RAM बेचना चाहता होगा, लेकिन आज की अपेक्षाओं के हिसाब से swap फिट नहीं बैठता। 90s में किसी click पर 2–3 सेकंड इंतज़ार कर लेते थे, लेकिन अब अगर response न मिले तो लोग समझते हैं कि सिस्टम मर गया और तुरंत reboot कर देते हैं.

  • एक और विकल्प है ज़्यादा memory जोड़ना, और app के हिसाब से oom_score समायोजित करना ताकि गैर-ज़रूरी apps को ऊँचा kill weight मिले और महत्वपूर्ण apps को negative weight। उदाहरण के लिए OpenSSH में oom_score_adj पहले से -1000 पर सेट होता है। staging/production servers पर overcommit को लगभग निष्क्रिय कर देना भी बहुत उपयोगी है। RAM की मात्रा के आधार पर min_free और reserve values एक formula से निकालकर सेट की जाती हैं। 50,000 physical servers को 10 साल से ज़्यादा बिना swap चलाने के दौरान इसका वास्तविक लाभ देखा है। OOM सिर्फ तब हुआ जब code deploy के दौरान memory requirement का गलत अंदाज़ा लगाया गया, या जब Java best practices का पालन नहीं हुआ—वह अलग लंबी कहानी है। cgroup से app-वार memory limit लगाने का तरीका भी है, लेकिन यहाँ छोड़ रहा हूँ। अगर पूरी तरह in-memory server है जिसे disk पर लिखना ही नहीं है, तो OOM को पूरी तरह रोककर उसे अपने-आप self-healing करने देना भी recommend करूँगा। crash messages capture करने के लिए DRAC/iLO को समय देने और panic reboot settings (kernel.panic, vm.panic_on_oom आदि) भी उपयोगी हैं। जानकारी के लिए, NFS diskless system में failure recovery के दौरान इसे जानबूझकर पूरे farm restart trigger के रूप में भी इस्तेमाल किया जा सकता है.

  • अच्छी जानकारी, धन्यवाद। मैं system limits (systemd) से RAM threshold नियंत्रित कर रहा हूँ, लेकिन जानना चाहता हूँ कि process के अनियंत्रित behavior से पूरी instance के unresponsive होने को रोकने के लिए earlyoom बेहतर विकल्प है या नहीं.

  • contingency के लिए बहुत थोड़ा swap, जैसे 1GB, रखना मुझे अच्छा विचार लगता है.

  • 2010 के बाद से swap इस्तेमाल नहीं किया.

• कल Nate Berkopec का Rails performance पर इसी तरह का एक लेख देखा था, जिसमें कहा गया कि performance के हिसाब से Heroku 25–50 गुना महँगा है। सच में ऐसा लगता है कि उन्हें price competition की कोई इच्छा ही नहीं है। अगर Sidekiq की तरह पूरे stack को reasonable price पर सिर्फ license कर देते, hardware अलग रखना पड़े तब भी वह कहीं बेहतर होता। 2025 में 1GB RAM dyno का $50 होना लगभग लूट है, खासकर जब standard Rails apps के resource pattern पहले से बहुत बड़े नहीं हुए, बल्कि वे और efficient ही हुए हैं। कीमतें उल्टा बढ़ गईं और quality गिर गई। यह लगभग हास्यास्पद है कि इतने developer हर महीने सैकड़ों डॉलर देकर Heroku पर apps चला रहे हैं, जबकि उन्हें ऐसी machines मिल रही हैं जो development MacBook से भी धीमी हैं। अंत में यह आजकल की दुनिया जैसा ही है: अच्छे products को reasonable price पर आम लोगों तक पहुँचाने के बजाय सिर्फ सबसे अमीर top customers पर ध्यान देना और prices बढ़ाते जाना.

  • समस्या सिर्फ price hike की नहीं है। मुझे लगता है Heroku और cloud vendors psychological price anchor effect का फ़ायदा उठाते हैं। जब user किसी service का इस्तेमाल शुरू करता है, तो वह एक price anchor बना लेता है, और उसके बाद उसकी expectations सिर्फ linear रूप से बदलती हैं। असल computing hardware exponential रूप से तेज़ होती जाती है, लेकिन users उसे linear रूप में महसूस करते हैं। Heroku की कीमतें कम-से-कम 7 साल से नहीं बदलीं, जबकि hardware बहुत आगे बढ़ चुकी है। इसलिए जो धोखे जैसा महसूस होता है, वह असल में 2025 के reference point की तुलना mid-2010s की pricing से करना है। बड़े cloud vendors नए hardware performance को unlock करने या SKU updates जैसी बाधाएँ जोड़ते हैं। Heroku के पास ऐसी competition नहीं थी, इसलिए उसने price स्थिर रखी, और इस तरह की पोस्ट हर बार सामने आती है जब नए engineers hardware performance को महसूस करते हैं.

  • आपने कहा कि $50 में 1GB RAM dyno लूट है, लेकिन AWS भी बहुत अलग नहीं है। $50/महीना में m7a.medium मिलता है, जिसमें 1vCPU और 4GB RAM है। RAM ज़्यादा है, लेकिन समझ आता है कि AWS इतना पैसा क्यों बना रहा है.

  • कम दाम पर पूरे software stack को reasonable license देने वाला मॉडल Sidekiq जैसा होना चाहिए—इस बात से सहमत होकर हमने canine.sh को open source बनाया। हमें लगा कि PaaS providers को पहले से markup लगे cloud पर एक और बेहिसाब markup लगाने की ज़रूरत नहीं है.

  • यह वैसा ही है जैसे कहना कि स्थानीय garage में oil change या restaurant में steak महँगा है, जबकि घर पर खुद करके सस्ता पड़ता है.

• Cloud आपको यह भुला देता है कि एक ही server से कितना कुछ किया जा सकता है। सिर्फ staging environment को भी महँगे cloud पर चलाना मुझे समझ नहीं आता, हालाँकि आजकल cloud में कई चीज़ें जटिल रूप से जुड़ी होती हैं इसलिए उसकी आवश्यकता समझ में आती है.

  • कई developers को cloud basics सिखाना और कुछ cloud experts रखना काफ़ी समय तक cost-effective होता है। अगर staging/prod environments को काफ़ी मिलता-जुलता रखा जाए तो गलतियाँ भी जल्दी पकड़ी जा सकती हैं। बाद में वह बिंदु आता है जहाँ cloud bill labor cost से भी ज़्यादा हो जाता है, और तब cloud से बाहर निकलना सचमुच फ़ायदेमंद होता है। अंततः मुझे लगता है कि self-hosted servers पर जाने पर वह समय ज़रूर आता है जब लागत team और hardware दोनों की combined price से आगे निकल जाती है.

  • लगता है cloud की वजह से developers खुद Linux servers से डरने लगे हैं। मुझे लगता है अधिकांश margin developer anxiety की क़ीमत है। लेकिन self-hosting वास्तव में आसान और मज़ेदार है। मुझे Heroku, Vercel जैसी चीज़ों का आकर्षण कभी समझ नहीं आया, और मेरा मानना है कि शुरुआत में खुद server खड़ा करके देखने से बेहतर अनुभव कोई नहीं। मैं हर developer को सलाह दूँगा कि इसे ख़ुद आज़माए.

  • production जैसी operating conditions को दोहराते हुए prod environment की पूरी नकल बनाना बहुत मददगार होता है। deployment process भी मिलती-जुलती रहती है, समय बचता है, और testing असली prod के ज़्यादा करीब होती है.

  • इस पर आधारित infra learning site बनाना मज़ेदार होगा। जैसे cloud पर X resources दिए जाएँ और तय load संभालने के लिए setup करना हो, फिर लोग performance score पर एक-दूसरे से मुकाबला कर सकें.

  • लगभग 2006 में AWS की सबसे छोटी machine भी एक ठीक-ठाक dev desktop के आकार की होती थी, इसलिए कम-से-कम 2 साल rent पर लेने के बाद ही उसका पैसा वसूल होता था। आजकल AWS machines mobile phone या सस्ते laptop के स्तर की हैं, और 3–6 महीने rent करने पर ही hardware खरीदना ज़्यादा लाभदायक हो जाता है। जब तक 75% discount न मिल रहा हो, on-premises cloud से manpower और cost दोनों में बेहतर है.

• नमस्ते, मैं अपने दोस्त Antoine Leclair के साथ Disco नाम का open source PaaS बना रहा हूँ। आजकल self-hosting और cloud exit पर बहुत चर्चा हो रही है, इसलिए अगर कोई सवाल हो तो बेझिझक पूछें.

  • आपने कहा था कि “server resource usage बहुत कम था”; htop में load average CPU core के हिसाब से होता है, यह याद करें तो बात और प्रभावशाली लगती है। उदाहरण के लिए, 8 cores हों तो load average 0.1 कुल CPU capacity का लगभग 1.25% होता है। ब्लॉग पढ़कर मज़ा आया, ऐसे pattern देखकर मुझे भी अच्छा अनुभव मिलता है.

  • जानना चाहूँगा कि Coolify जैसे tools की तुलना में Disco खास तौर पर क्या अलग देता है। मैं अपने ज़्यादातर services Hetzner VPS पर host कर रहा हूँ, इसलिए Disco की कोई unique strength हो तो जानना चाहूँगा.

• Hack Club में हमारा भी कुछ ऐसा ही अनुभव रहा। हमारी non-profit high school students को coding और electronics में शुरुआत कराने पर केंद्रित है। पहले हम Heroku इस्तेमाल करते थे, लेकिन सिर्फ लागत ही नहीं, यह सवाल भी उठता था कि क्या यह छोटा utility app सच में $15/महीना देने लायक है। इस साल Coolify के साथ self-hosting करते हुए हम Hetzner के $300/महीना वाले एक server पर 300 services चला रहे हैं। नतीजा यह हुआ कि हम बहुत ज़्यादा code deploy कर सके। सबसे बड़ी सीख यह थी कि अगर आपको 99.99% नहीं बल्कि सिर्फ 99% uptime चाहिए, तो दुनिया बहुत बड़ी हो जाती है। ज़्यादातर developer tools 99.99% पर अटके रहते हैं, लेकिन अगर 99% काफ़ी हो तो चीज़ें काफ़ी कुशलता से चलाई जा सकती हैं। Disco में भी दिलचस्पी पैदा हुई है, ज़रूर आज़माऊँगा.

  • धन्यवाद, और अगर Disco service के बारे में कुछ पूछना हो तो कभी भी Discord पर पूछ सकते हैं। ऐसे दो मिलते-जुलते cases हैं: Puerto Rico के एक bootcamp/dev school में छात्रों के final projects सबको एक ही VPS पर deploy कराया गया, और Recurse Center में एक Raspberry Pi पर 75 web projects host किए जा रहे हैं (लिंक).

  • और अगर सच में 99.99% चाहिए, तो मुझे लगता है hyperscaler से बचना ही चाहिए। हाल में AWS का कई घंटों का outage इसका उदाहरण है.

  • 300 services? जानना चाहूँगा कि उनमें से हर एक क्या काम करती है.

• मौजूदा हालत देखकर self-hosting सच में आकर्षक समाधान लगती है, लेकिन लेख के बारे में भी एक बात कहना चाहता हूँ। यह लेख ऐसा लगता है जैसे इसे AI ने काफ़ी heavily edit किया हो, और वास्तव में “Bridging the Gap: Why Not Just Docker Compose?” वाला भाग Disco product landing page के “Powerful simplicity” हिस्से की लगभग 1:1 copy-paste है। यह blog post उनकी main page पर दिखाई जाने वाली इकलौती case study भी है.

  • बिल्कुल सही बात है। मैं इसके तीन कारण देना चाहता हूँ (मज़ाक कर रहा हूँ), लेकिन हमारी library open source है और Idealist ने पैसे बचाए—इस पर हमें गर्व है। अगर गर्व दिखाना promotion है, तो मैं खुशी-खुशी उसे promotion मान लूँगा.

  • आप कह रहे हैं कि marketing post समस्या है, लेकिन मुझे जानना है कि आप उसे समस्या क्यों मानते हैं। क्या यह Hacker News guidelines में मना है, या आपका मानना है कि हर marketing को label करना चाहिए? दुनिया में लगभग कोई भी चीज़ marketing से पूरी तरह मुक्त नहीं है.

  • price competition पर marketing blog post लिखना, लेकिन अपनी website पर actual pricing न देना और सिर्फ meeting booking लेना—मेरे लिए price से जुड़ा सबसे बड़ा red flag यही है.

  • मैं भी तुरंत revenue model देखने गया था, लेकिन सिर्फ इतना लगा कि शायद यह जल्द सामने आएगा.

  • यह पहली बार नहीं है कि किसी लेख में marketing मिली हुई हो। मुझे समझ नहीं आता कि case-study आधारित marketing में समस्या क्या है। यह काफ़ी हल्का उदाहरण है, और marketing angle होने के बावजूद मुझे यह रोचक और उपयोगी लगा.

• Heroku की pricing सचमुच पागलपन है। करीब 10 साल पहले जिस startup में मैं था, वहाँ सिर्फ email में दिखाने के लिए HTML table के रूप में QR code बनाने वाली एक service पर हर महीने $10,000 से ज़्यादा खर्च हो रहे थे। हिसाब से यह लगभग $0.15 प्रति piece पड़ता था। development lead ने कभी code profiling भी नहीं की थी; बाद में इसे घटाकर $0.01 प्रति piece तक लाए, लेकिन तब भी यह बेहूदा था.

  • समझ नहीं आता कि कोई खास बात न होते हुए भी एक QR code बनाने में इतना पैसा क्यों लगे। edge cloud hosting से भी यह मुफ्त में हो सकता है.

• समझ नहीं आता कि 6 staging servers (हर एक $500) की ज़रूरत क्यों है। अगर यह बड़े team size की वजह से है, तो $3,000 server cost सालाना $100k+ labor की तुलना में बहुत छोटी नहीं है? मैंने idealist.org देखा; वह तो बस एक job board है, इसलिए यह कुछ ज़्यादा ही लगा.

  • 6 staging servers इसलिए थे ताकि main, dev, और कई branches को non-developer QA लोग सीधे देख सकें। हर staging deployment में Performance-M dyno, कई Standard dynos, RabbitMQ, database वगैरह लगते-लगते लागत जल्दी बढ़ जाती है। Idealist service रोज़ 100,000 users तक पहुँचती है, इसलिए उसकी reliability और speed के पीछे काफ़ी technology लगी है.

  • पढ़कर लगा कि कई staging servers इसलिए चाहिए थे क्योंकि वे हर developer के लिए कई services एक साथ चलाने वाले dev environments के रूप में भी काम कर रहे थे.

  • असली cost calculation में लोग labor (man-days) का हिसाब अक्सर भूल जाते हैं.

• अगर Heroku छोड़ना हो और सिर्फ Django site और database को dump करके बिना सीधे system management के इस्तेमाल करना हो, तो सबसे अच्छा विकल्प क्या होगा?

  • Render.com शायद सबसे करीब है, और मुझे इसे इस्तेमाल करके बहुत संतोष हुआ है। workflow लगभग Heroku जैसा ही है, यह सस्ता भी है, और nightly restart या Python के latest versions के support—सब ठीक लगा.

  • Docker Swarm सीखने की भी सिफारिश करूँगा। deployment बस एक container push करके और एक command से हो जाता है। मैंने rove.dev नाम का एक free CLI tool भी बनाया है जो deployment और service diff—दोनों के लिए काम आता है। या फिर VM-based PaaS भी अच्छे विकल्प हैं। Semaphore, Dokku, Dokploy वगैरह देख सकते हैं.

  • अपनी पसंद का VPS चुनिए—price/performance/location/support जो ठीक लगे—और उस पर Coolify, Dokploy जैसे deployment tools जोड़कर इस्तेमाल कीजिए। हाल ही में मैंने Coolify और Mythic Beasts के साथ Django/Postgres को Google App Engine से आसानी से migrate किया। मेरी skills काफ़ी जंग खा चुकी थीं, फिर भी migration सच में बहुत आसान थी.

  • Hetzner पर एक server चलाकर nginx और systemctl services सेट कर दें, मुझे लगता है वही काफ़ी है.

  • PythonAnywhere(लिंक) भी ठीक है.

• शानदार project है। docs देखकर लगा कि GitHub integration, Disco के लिए अनिवार्य शर्त है—क्या यह सही है? और क्या मैं बिना अलग build process के, अपनी registry में मौजूद existing Docker image को सीधे deploy कर सकता हूँ (कुछ-कुछ Kamal के --skip-push --version latest जैसा)?

  • हाँ, अभी के लिए GitHub integration ज़रूरी है। लेकिन Disco मौजूदा Docker image को सीधे pull करके deploy भी कर सकता है (हम RabbitMQ को इसी तरह self-host करते हैं)। उदाहरण के लिए Meilisearch image deploy करने का तरीका यहाँ और इस tutorial में देख सकते हैं। वैसे क्या आप आमतौर पर build करके registry में push करते हैं? आपका deployment process और विस्तार से सुनना चाहूँगा.