Shared hosting बनाम VPS: आपके लिए क्या बेहतर है?

Shared hosting बनाम VPS: संक्षिप्त उत्तर

Shared hosting बनाम VPS का प्रश्न गति का नहीं है। Shared hosting पर आप एक ऐसी मशीन पर अकाउंट किराए पर लेते हैं जिसे कोई और कॉन्फ़िगर करता है, पैच करता है और सैकड़ों ग्राहकों के बीच साझा करता है। VPS (virtual private server) पर आप root access के साथ पूरा ऑपरेटिंग सिस्टम किराए पर लेते हैं, इसलिए आप जो चाहें इंस्टॉल कर सकते हैं और जो आप खराब करते हैं उसे ठीक भी आप ही करते हैं।

तीन चीजें वास्तव में अलग हैं। या तो आपके पास root access होता है या नहीं। आपकी मेमोरी या तो आपको आवंटित की जाती है या एक पूल से उधार ली जाती है। और जब सर्वर आधी रात को जवाब देना बंद कर देता है, तो या तो होस्ट इसे ठीक करता है या आप। फीचर ग्रिड पर सब कुछ इन्हीं तीन बिंदुओं से तय होता है।

यदि आपकी साइट केवल पेज, इमेज और एक कॉन्टैक्ट फॉर्म है, तो Shared hosting सही उत्तर है और यह सस्ता भी है। यदि आपकी साइट को ऐसे प्रोग्राम की आवश्यकता है जो तब भी चलता रहे जब कोई उसे विजिट न कर रहा हो, तो आपको VPS की आवश्यकता है।

Shared hosting वास्तव में आपको क्या प्रदान करता है

एक Linux सर्वर एक साथ कई customer accounts चलाता है। प्रत्येक account एक home directory होती है, जिसमें document root, एक database और एक mailbox होता है। एक ही web server, आमतौर पर Apache या LiteSpeed, उस box पर मौजूद हर site को serve करता है। आपको shell prompt के स्थान पर एक control panel मिलता है। आपके पास root access नहीं होता, इसलिए आप कोई package install नहीं कर सकते, कोई port open नहीं कर सकते या कोई background service start नहीं कर सकते।

अधिकांश shared hosts CloudLinux चलाते हैं, जो प्रत्येक account को उसके अपने container में रखता है। इसमें processor time और एक साथ चलाए जा सकने वाले processes की संख्या पर एक hard cap लगा होता है। process cap पार करने से आपकी site धीमी नहीं होती है। इसके बजाय, सर्वर एक error page दिखाता है जिस पर 508 Resource Limit Is Reached लिखा होता है। वह page यह दर्शाता है कि आपका अपना account अपनी सीमा तक पहुँच गया है, न कि कोई पड़ोसी आपका हिस्सा ले रहा है।

यह समझौता जानबूझकर किया गया है। आप नियंत्रण छोड़ते हैं, और बदले में host kernel को patch करता है, PHP को update करता है, certificate को renew करता है और nightly backup रखता है। बहुत सारी sites के लिए यह एक अच्छा समझौता है।

VPS वास्तव में आपको क्या प्रदान करता है

VPS एक होस्ट सर्वर पर चलने वाली वर्चुअल मशीन है। KVM के अंतर्गत, जो अधिकांश Linux VPS प्लान के पीछे का हाइपरवाइजर है, आपका इंस्टेंस अपना स्वयं का कर्नल बूट करता है और उसके पास अपना IP एड्रेस, अपना फायरवॉल और अपना init सिस्टम होता है। sudo काम करता है। apt install काम करता है। systemd के माध्यम से आपके द्वारा शुरू किया गया प्रोग्राम आपके लॉग आउट करने के बाद भी चलता रहता है, क्रैश होने के बाद रीस्टार्ट हो जाता है, और रीबूट के बाद वापस आ जाता है।

वही root एक्सेस इस बात का कारण है कि मशीन की सुरक्षा आपकी जिम्मेदारी बन जाती है। कोई और इसकी निगरानी नहीं कर रहा है। VPS पर लोग जो चीजें चलाते हैं उनकी सीमा ठीक इसी कारण से व्यापक है: यह बॉक्स वह सब कुछ करता है जो एक Linux सर्वर कर सकता है।

अंतर 1: root access, और यह क्या-क्या अनलॉक करता है

Root वह अंतर है जो बाकी सभी अंतर पैदा करता है। इसके साथ आप distribution से कोई भी package install कर सकते हैं, कोई भी port bind कर सकते हैं, एक systemd unit लिख सकते हैं, मशीन पर मौजूद हर log पढ़ सकते हैं और sysctl के साथ kernel settings बदल सकते हैं। इसके बिना आपको केवल वही सूची मिलती है जो पैनल प्रदान करता है: एक PHP version selector, extensions का एक निश्चित सेट और cron jobs के लिए एक फॉर्म।

एक VPS पर आप हमेशा मशीन से पूछ सकते हैं कि कौन सा port listening मोड में है:

ss -ltnp

हर पंक्ति एक open socket और उसके मालिक process को दर्शाती है, इसलिए जो service start होने में विफल रही है, वह एक गायब पंक्ति के रूप में दिखाई देगी। Shared hosting पर इस प्रश्न का कोई उत्तर नहीं होता, क्योंकि port 80 और 443 host के web server के होते हैं और आपके द्वारा लिखा गया कोई भी कोड उन्हें नहीं ले सकता।

अंतर 2: आवंटित मेमोरी बनाम उधार ली गई मेमोरी

Shared hosting इस धारणा पर बेची जाती है कि कुछ ही accounts एक ही समय पर व्यस्त होते हैं। मशीन की मेमोरी एक pool की तरह होती है, और आपका हिस्सा एक reservation के बजाय केवल एक limit होता है। जब आपका हिस्सा समाप्त हो जाता है, तो PHP processes को kill कर दिया जाता है और visitors को 500 या 508 error दिखाई देता है।

VPS पर, आपके plan में दी गई मेमोरी पूरी तरह से आपके instance की होती है। free -m इसकी रिपोर्ट देता है, और आपकी virtual machine के बाहर की कोई भी process इसे आपसे छीन नहीं सकती।

Processor time इसका एक अपवाद है। अधिकांश VPS plans physical cores को guests के बीच साझा करते हैं, और आप इसे स्वयं माप सकते हैं:

vmstat 1 5

st column 'steal time' को दर्शाता है: यह वह समय है जब आपका virtual processor चलने के लिए तैयार था, लेकिन physical core किसी अन्य guest को दिया गया था। कुछ प्रतिशत का स्थिर मान सामान्य है। यदि यह संख्या लगातार दो अंकों (double-digit) में बनी रहती है, तो इसका अर्थ है कि host oversubscribed है, और यह वह आंकड़ा है जिसे आप support ticket में उद्धृत कर सकते हैं। Shared hosting पर इसके समकक्ष कोई reading नहीं होती, क्योंकि इसे दिखाने वाले हर tool के लिए root access की आवश्यकता होती है। Storage भी इसी तरह काम करती है, यही कारण है कि VPS plan के पीछे का disk type मायने रखता है, और sales page पर भरोसा करने के बजाय पहले सप्ताह में नए VPS को स्वयं मापना फायदेमंद होता है।

अंतर 3: खराबी आने पर जिम्मेदारी किसकी है

Shared hosting पर operating system, web server, PHP build, certificates और nightly backup का स्वामित्व host के पास होता है। जब मशीन response देना बंद कर देती है, तो आप एक ticket खोलते हैं और कोई न कोई उस पर काम कर रहा होता है। इसकी कीमत उसी नियम का दूसरा पहलू है: आप उनसे ऐसी कोई चीज़ install करने के लिए नहीं कह सकते जिसे वे support नहीं करते।

Unmanaged VPS पर provider का स्वामित्व केवल hypervisor, network और power पर होता है। kernel से ऊपर की हर चीज़ आपकी है। Security updates, firewall, backups, certificate renewal और monitoring का सारा काम आपका है, और support आपकी web server config को debug करने के लिए login नहीं करेगा। पहले दिन से ही इसकी योजना बनाएँ: नए VPS पर शुरुआती दस मिनट, फिर एक firewall जिसे आप समझते हैं, automatic security updates और ऐसे backups जिन्हें आपने कम से कम एक बार restore किया हो।

कब shared hosting सही विकल्प है

एक brochure site इसका सबसे स्पष्ट उदाहरण है: कुछ pages, images, एक contact form, शायद एक caching plugin के साथ WordPress, और प्रतिदिन कुछ हजार visitors। इसमें कोई background jobs नहीं होतीं। कोई असामान्य runtime नहीं होता। ऐसी कोई चीज़ नहीं जिसे requests के बीच memory में रहने की आवश्यकता हो। Shared hosting ऐसी site के लिए उपयुक्त है, यह किसी भी VPS से सस्ती पड़ती है, और maintenance का काम उन लोगों को सौंप देती है जो इसे full-time करते हैं। इसे VPS पर ले जाने से कोई लाभ नहीं होता और यह एक ऐसा काम बढ़ा देता है जो पहले आपके पास नहीं था।

एक दूसरा मामला भी है जिस पर कम ध्यान दिया जाता है। यदि आपकी टीम में कोई भी log file पढ़ने या apt upgrade चलाने का इच्छुक नहीं है, तो shared hosting एक सुरक्षित विकल्प है। एक unpatched VPS जिसमें database port खुला हो, एक ऐसे shared account से कहीं अधिक बुरा है जिसे कोई professional अद्यतन (update) रखता है। Control केवल तभी फायदेमंद होता है जब कोई उसका उपयोग करे।

संकेत 1: आपको एक ऐसे प्रोग्राम की आवश्यकता है जो निरंतर चलता रहे

Daemon एक ऐसा प्रोग्राम है जो मेमोरी में बना रहता है और काम की प्रतीक्षा करता है: जैसे कि API, चैट बॉट, कतार वर्कर (queue worker), या गेम सर्वर। Shared hosting आपके कोड को केवल तभी चलाती है जब कोई अनुरोध (request) आता है, और SSH (secure shell) सत्र से आप जो भी प्रक्रिया चालू छोड़ते हैं, उसे समाप्त कर दिया जाता है, क्योंकि एक लंबी अवधि तक चलने वाली प्रक्रिया खाते की प्रक्रिया सीमा (process cap) के विरुद्ध गिनी जाती है।

VPS पर वही प्रोग्राम एक systemd unit बन जाता है:

sudo systemctl enable --now myapp
systemctl status myapp

systemctl status को एक process ID के साथ Active: active (running) प्रिंट करना चाहिए। यदि यह Active: failed (Result: exit-code) प्रिंट करता है, तो इसका कारण journalctl -u myapp -n 50 में होता है, जो उस क्षण प्रोग्राम का अपना आउटपुट दिखाता है जब वह बंद हुआ था। यूनिट फ़ाइल में Restart=always इसे क्रैश के बाद वापस लाता है, और enable इसे रीबूट के बाद वापस लाता है। systemd services और timers लिखना पहला VPS कौशल है जिसे ठीक से सीखना सार्थक है।

संकेत 2: आपको ऐसे रनटाइम की आवश्यकता है जो पैनल प्रदान नहीं करता है

पैनल आपको एक सूची देता है। यदि आपके एप्लिकेशन को उस सूची से बाहर के किसी भाषा संस्करण, किसी ऐसी लाइब्रेरी जिसे कंपाइल करने की आवश्यकता है, ffmpeg, किसी हेडलेस ब्राउज़र या MySQL के अलावा किसी अन्य डेटाबेस की आवश्यकता है, तो शेयर्ड होस्टिंग में उसे रखने के लिए कोई जगह नहीं होती है। सॉफ़्टवेयर इंस्टॉल करने के लिए root एक्सेस की आवश्यकता होती है, और अकाउंट में न तो कोई कंपाइलर होता है और न ही डेवलपमेंट हेडर, इसलिए कुछ भी तैयार होने से पहले ही बिल्ड विफल हो जाता है।

VPS पर आप इसे apt install के साथ इंस्टॉल करते हैं, या आप इसे कंटेनर में चलाते हैं और होस्ट को क्लीन रखते हैं। जब एप्लिकेशन में एक से अधिक गतिशील हिस्से (moving parts) शामिल हो जाते हैं, तो VPS पर Docker Compose का उपयोग करना सामान्य तरीका है।

संकेत 3: आपका cron job समय पर चलना चाहिए

Shared hosts एक फॉर्म के माध्यम से cron jobs स्वीकार करते हैं और न्यूनतम अंतराल निर्धारित करते हैं, जो आमतौर पर पांच या पंद्रह मिनट होता है। जो job अकाउंट की प्रोसेसर सीमा से अधिक समय तक चलता है, उसे बीच में ही बंद (kill) कर दिया जाता है। यह चुपचाप विफल हो जाता है, क्योंकि ऐसी किसी लॉग फाइल में कुछ भी नहीं लिखा जाता जिसे आप पढ़ सकें।

एक VPS पर crontab -e आपके द्वारा लिखे गए किसी भी शेड्यूल को स्वीकार करता है, और systemd timer इससे भी बेहतर विकल्प है:

systemctl list-timers
journalctl -u cron -n 20

list-timers प्रत्येक timer के लिए अगली रन और अंतिम परिणाम को प्रिंट करता है, और cron log प्रत्येक कमांड को उसके चलने के समय दिखाता है। जब कोई job नहीं चलता है, तो आप यह बता सकते हैं कि वह कभी शुरू ही नहीं हुआ या शुरू होकर विफल हो गया। यह अंतर ही किसी scheduled task को डीबग करने का मुख्य हिस्सा है।

संकेत 4: आपके पड़ोसी आपके रिस्पॉन्स टाइम को प्रभावित कर रहे हैं

यह लक्षण विशिष्ट है। आपके कोड में बिना किसी बदलाव के, वही पेज रात में जल्दी लोड होता है और शाम सात बजे धीमा हो जाता है। किसी और को दोष देने से पहले इसे अपनी मशीन से मापें:

for i in $(seq 1 20); do curl -o /dev/null -s -w '%{time_starttransfer}\n' https://example.com/; sleep 5; done

time_starttransfer रिस्पॉन्स के पहले बाइट तक का समय है, जिसे सेकंड में मापा जाता है। यदि ये बीस संख्याएँ एक-दूसरे के करीब हैं, तो समस्या आपके सर्वर में नहीं है और इसका समाधान आपके कोड या डेटाबेस क्वेरी में है। यदि ये रात के 3 बजे स्थिर रहती हैं और पीक आवर्स के दौरान कई सौ मिलीसेकंड तक बदल जाती हैं, तो आप एक व्यस्त मशीन को उन अकाउंट्स के साथ साझा कर रहे हैं जिन्हें आप देख नहीं सकते। यह वह समस्या है जिसे आप बेहतर कोड से ठीक नहीं कर सकते, क्योंकि इसका कारण अकाउंट बाउंड्री के दूसरी ओर स्थित है।

स्थानांतरण की वास्तविक लागत

ये अगस्त 2026 तक प्रत्येक श्रेणी में सबसे छोटे प्लान के लिए सामान्य विज्ञापित कीमतें हैं। इन्हें एक सटीक कोटेशन के बजाय एक अनुमान के रूप में देखें, और खरीदारी से पहले वर्तमान कीमत की जांच करें।

[
  {
    "plan": "Shared hosting",
    "first_term_usd": 3,
    "renewal_usd": 12
  },
  {
    "plan": "VPS, 1 vCPU 1 GB",
    "first_term_usd": 5,
    "renewal_usd": 6
  },
  {
    "plan": "VPS, 2 vCPU 4 GB",
    "first_term_usd": 12,
    "renewal_usd": 15
  },
  {
    "plan": "Managed VPS, 2 vCPU 4 GB",
    "first_term_usd": 25,
    "renewal_usd": 30
  }
]

मुख्य अंतर 3 से 5 अमेरिकी डॉलर प्रति माह के बीच है, और केवल यह संख्या ही सब कुछ तय नहीं करती है। Shared hosting एक शुरुआती दर का विज्ञापन करती है जिसके लिए आमतौर पर एक से तीन साल का भुगतान अग्रिम करना पड़ता है, और यह 12 डॉलर के आसपास रिन्यू होती है। रिन्यूअल की तुलना रिन्यूअल से करें तो स्थिति बदल जाती है: shared account के लिए 12 डॉलर बनाम entry VPS के लिए 6 डॉलर।

इस तुलना को सावधानी से करें, क्योंकि दोनों का आकार समान नहीं है। एक 1 vCPU, 1 GB वाला VPS वेब सर्वर और डेटाबेस को एक छोटे बॉक्स पर चलाता है, जो वास्तविक ट्रैफिक आने पर WordPress के लिए बहुत कम पड़ सकता है। रिन्यू किए गए shared plan के साथ वास्तविक तुलना 2 vCPU, 4 GB वाले प्लान से होती है, जिसकी कीमत लगभग 15 डॉलर है। इसलिए, वास्तविक अतिरिक्त लागत प्रति माह कुछ डॉलर ही है, न कि कई गुना।

बड़ी लागत कभी भी इनवॉइस पर नहीं दिखती है। एक VPS सेटअप में एक घंटा, अपडेट के लिए हर महीने कुछ मिनट, और पहली बार कुछ खराब होने पर आपकी एक पूरी शाम खर्च करवा सकता है। यदि आप इसे अपनी प्रति घंटा दर के अनुसार आंकें, तो यह अंतर जल्दी ही समाप्त हो जाता है। व्यवहार में VPS की लागत क्या है लेख में आकारों का अधिक विस्तार से विवरण दिया गया है।

ट्रैफिक खोए बिना साझा होस्टिंग (shared hosting) से साइट को स्थानांतरित करना

1. एक दिन पहले, डोमेन के लिए DNS (domain name system) TTL (time to live) को घटाकर 300 seconds कर दें, ताकि बदलाव घंटों के बजाय मिनटों में प्रभावी हो जाए।
2. नया सर्वर तैयार करें और DNS को छूने से पहले साइट को उसके IP address पर चालू करें।
3. फाइलों को कॉपी करें, फिर डेटाबेस का डंप लें और उसे नए सर्वर पर रिस्टोर करें।
4. अपने लैपटॉप की hosts फाइल के माध्यम से परीक्षण करें, जो डोमेन को केवल आपकी मशीन के लिए नए IP पर पॉइंट करती है।
5. नए सर्वर पर TLS (transport layer security) सर्टिफिकेट जारी करें, A record बदलें, और साझा खाते (shared account) को एक सप्ताह तक सक्रिय रखें।

dig example.com A +noall +answer
rsync -avz ~/public_html/ deploy@203.0.113.10:/srv/www/example.com/
mysqldump --single-transaction -u dbuser -p dbname > site.sql

dig अपने उत्तर के दूसरे कॉलम में TTL प्रिंट करता है, इसलिए आप किसी भी बदलाव से पहले यह पुष्टि कर सकते हैं कि कम मान (lower value) लाइव है। --single-transaction टेबल को लॉक किए बिना एक सुसंगत स्नैपशॉट लेता है, जो तब महत्वपूर्ण होता है जब पुरानी साइट पर आपके काम करने के दौरान भी ऑर्डर आ रहे हों। नए सर्वर पर, उसी दिन सर्टिफिकेट चालू करें: Let's Encrypt on Ubuntu with nginx में कुछ ही मिनट लगते हैं, बशर्ते DNS record उस बॉक्स पर पॉइंट कर रहा हो।

जिम्मेदारी के बिना संसाधन

यदि चार संकेत आपकी साइट पर लागू होते हैं लेकिन आप रखरखाव नहीं करना चाहते, तो मध्यम विकल्प एक managed VPS है। आप आवंटित memory और root-level क्षमता बनाए रखते हैं, और प्रदाता patching, monitoring और आमतौर पर एक panel की जिम्मेदारी लेता है। ऊपर दिया गया चार्ट unmanaged VPS के लिए 15 की तुलना में इसके लिए लगभग 30 डॉलर का खर्च दर्शाता है। यह अंतर उस समय के लिए है जब रात में सर्वर काम करना बंद कर दे और आपको किसी और की सहायता मिल सके।

यदि यह आपके लिए सही विकल्प लगता है, तो managed बनाम unmanaged VPS का निर्णय अगला सही लेख है। यदि आप पहले से ही एक व्यस्त VPS चला रहे हैं और peak hours के दौरान भी steal time अधिक है, तो इसके बाद का अगला कदम बिना किसी पड़ोसी वाला एक dedicated server है।

FAQ

क्या VPS, shared hosting से तेज होता है?

हमेशा नहीं। एक शांत shared server, single WordPress page के लिए 1 vCPU वाले VPS से बेहतर प्रदर्शन कर सकता है। VPS आपको निरंतरता (consistency) प्रदान करता है: आपके प्लान में आवंटित memory केवल आपकी है, इसलिए response time मशीन पर मौजूद अन्य व्यस्त accounts के बजाय आपके कोड पर निर्भर करता है। यदि आपके pages रात के 3 बजे और शाम के 7 बजे, दोनों समय धीमे हैं, तो इसका कारण आपका कोड या database queries हैं। उसी कोड को VPS पर ले जाने से समस्या भी साथ चली जाएगी।

क्या मैं shared hosting पर Node.js या Python app चला सकता हूँ?

कभी-कभी, और केवल सीमित दायरे में। कुछ panels Passenger के माध्यम से आपके लिए application start कर देते हैं, जो request आने पर चलती है। आप अपना खुद का port bind नहीं कर सकते, क्योंकि host का web server 80 और 443 ports का उपयोग करता है। आप requests के बीच worker को memory में नहीं रख सकते, क्योंकि account की process limit किसी भी long-lived process को समाप्त कर देती है। एक bot, queue worker या websocket server के लिए VPS की आवश्यकता होती है।

क्या VPS चलाने के लिए मुझे Linux जानना जरूरी है?

unmanaged VPS के लिए, हाँ। आपको SSH keys, firewall, updates, backups की जानकारी होनी चाहिए और logs पढ़ने की आदत डालनी होगी। शुरुआती सेटअप के लिए एक घंटा और उसके बाद हर महीने कुछ मिनट का समय निकालें। यदि आप यह काम नहीं करना चाहते, तो एक managed plan आपको आवंटित resources तो देता है, लेकिन रखरखाव की जिम्मेदारी provider को सौंप देता है। managed बनाम unmanaged VPS hosting में इस अंतर को विस्तार से समझाया गया है।

क्या shared hosting से VPS पर migrate करते समय मेरी साइट down हो जाएगी?

नहीं, यदि आप पहले DNS TTL को कम कर लें और दोनों accounts को चालू रखें। एक दिन पहले TTL को 300 seconds पर सेट करें, files और database को copy करें, अपने laptop की hosts file के माध्यम से नए server का परीक्षण करें, और फिर A record बदलें। कुछ मिनटों के लिए कुछ visitors पुराने server पर और कुछ नए server पर पहुँचेंगे, इसलिए shared account को एक सप्ताह तक चालू रखें। अंतिम database dump के दौरान साइट को read-only mode में रखें, या उस अंतराल में हुए किसी भी बदलाव के खोने को स्वीकार करें।