क्या GitHub पर वेबसाइट होस्ट की जा सकती है? Pages बनाम VPS

क्या GitHub आपकी वेबसाइट को होस्ट कर सकता है? संक्षिप्त उत्तर

क्या GitHub आपकी वेबसाइट को होस्ट कर सकता है? हाँ, यदि वह वेबसाइट static files का एक फोल्डर है, तो इसे GitHub Pages नामक फीचर के माध्यम से किया जा सकता है। नहीं, यदि साइट को सर्वर पर चलने वाले कोड की आवश्यकता है। GitHub Git repositories के लिए एक होस्ट किया गया स्थान है, साथ ही इसके चारों ओर सहयोग की परत भी है: issues, pull requests, code review, और permissions। यह आपके कोड को स्टोर करता है, लेकिन यह उसे रन नहीं करता है।

वह अंतिम वाक्य ही पूरी उलझन का कारण है, और यह शुरुआती लोगों के हफ्तों बर्बाद कर देता है। प्रोजेक्ट GitHub पर है, कोड वहीं है, tests पास हो रहे हैं, फिर भी साइट ऑनलाइन नहीं है और फॉर्म कुछ भी सेव नहीं कर रहा है। नीचे दी गई हर जानकारी उसी एक पंक्ति का विस्तृत विवरण है।

GitHub वास्तव में क्या स्टोर करता है

Git एक version control tool है जो आपके अपने computer पर चलता है। यह आपकी फाइलों में किए गए हर बदलाव को record करता है, ताकि आप किसी भी पुरानी स्थिति पर वापस जा सकें और देख सकें कि किसने क्या बदला है। एक repository, या repo, एक project और उसके पूरे इतिहास का संग्रह होती है।

GitHub उस repository की एक copy अपने servers पर रखता है और उन सुविधाओं को जोड़ता है जो केवल Git में नहीं होतीं: code के लिए एक web page, काम को track करने के लिए issues, बदलावों का प्रस्ताव देने के लिए pull requests, और यह तय करने के लिए permissions कि कौन push कर सकता है। यही वह product है। अधिक जानकारी के लिए, GitHub क्या है और लोग इसका उपयोग किस लिए करते हैं पढ़ें, और यदि दोनों नाम अभी भी एक जैसे लगते हैं, तो Git और GitHub में क्या अंतर है लेख tool और service के बीच का अंतर स्पष्ट करता है। GitHub किसी repository के लिए एकमात्र स्थान नहीं है, क्योंकि Gitea, Forgejo और अन्य self-hosted Git servers आपके द्वारा नियंत्रित hardware पर वही काम करते हैं।

GitHub Pages क्या serve करेगा और क्या नहीं

GitHub Pages आपके repository की एक branch से फाइलें लेता है और उन्हें एक public URL पर publish करता है। GitHub का अपना documentation इसे एक static site hosting service कहता है, जो सीधे repository से HTML, CSS और JavaScript फाइलें लेती है। Static का अर्थ है कि सर्वर प्रत्येक फाइल को बिल्कुल वैसे ही लौटाता है जैसे वह store की गई है। यह bytes को पढ़ता है और उन्हें भेज देता है। आपके द्वारा लिखा गया कुछ भी GitHub के connection side पर execute नहीं होता है।

इसे चालू करने के लिए, फाइलें push करें, फिर github.com पर repository खोलें, Settings में जाएं और Pages section खोलें। publish करने के लिए branch और folder चुनें, या तो repository root या /docs।

git init
git add index.html style.css
git commit -m "First version of the site"
git branch -M main
git remote add origin https://github.com/YOUR-NAME/YOUR-REPO.git
git push -u origin main

पहला build पूरा होने के बाद, साइट https://YOUR-NAME.github.io/YOUR-REPO/ पर उपलब्ध होती है। एक repository का नाम अलग तरह से काम करता है: YOUR-NAME.github.io नामक repository बिना किसी path के https://YOUR-NAME.github.io/ पर publish होती है। यदि URL एक पेज लौटाता है जिस पर "There isn't a GitHub Pages site here." लिखा है, तो build पूरा नहीं हुआ है, या Pages किसी ऐसी branch या folder की ओर इशारा कर रहा है जिसमें कोई index.html नहीं है।

यहाँ नियम स्पष्ट किया गया है। save.php नामक एक फाइल commit करें जिसमें कोई भी PHP कोड हो, फिर उसे access करें:

curl https://YOUR-NAME.github.io/YOUR-REPO/save.php

आपको अपना PHP source कोड वापस मिल जाएगा, एक-एक character वैसा ही। Pages ने फाइल लौटा दी क्योंकि फाइलें लौटाना ही उसका एकमात्र काम है। उस URL के पीछे कोई PHP interpreter नहीं है, इसलिए कोड के चलने के लिए कोई जगह नहीं है। एक .py फाइल भी इसी तरह काम करती है, और बाकी सभी भाषाएं भी।

आपके कॉलेज प्रोजेक्ट में फॉर्म काम क्यों नहीं करता है

डेटा सेव करने वाले फीचर के दो हिस्से होते हैं। ब्राउज़र वाला हिस्सा HTML और JavaScript है, और Pages उस हिस्से को बिना किसी समस्या के सर्व करता है। सर्वर वाला हिस्सा सबमिशन प्राप्त करता है और उसे ऐसी जगह लिखता है जो रिक्वेस्ट पूरी होने के बाद भी सुरक्षित रहे। Pages में कोई सर्वर वाला हिस्सा नहीं होता है, इसलिए /save.php पर पोस्ट किया गया फॉर्म एक ऐसे फाइल सर्वर तक पहुँचता है जिसका एकमात्र काम फाइलें वापस देना है। कहीं भी कुछ भी लिखा नहीं जाता है, और विजिटर को ब्राउज़र के नेटवर्क टैब में एक खाली पेज या फेल्ड रिक्वेस्ट दिखाई देती है।

दो समाधान अक्सर सामने आते हैं, और दोनों में एक ऐसी कमी है जिसे समझना जरूरी है। localStorage में एंट्रीज रखने से वे एक डिवाइस पर एक ब्राउज़र के अंदर स्टोर होती हैं, इसलिए जब आपके शिक्षक उसी लिंक को खोलते हैं तो उन्हें खाली लिस्ट दिखाई देती है, क्योंकि उनके ब्राउज़र का अपना अलग स्टोरेज होता है। अपने JavaScript में डेटाबेस का पता और पासवर्ड डालने से पेज काम तो करने लगता है, लेकिन यह उस पासवर्ड को सार्वजनिक भी कर देता है: Pages द्वारा सर्व की जाने वाली हर फाइल को कोई भी डाउनलोड कर सकता है, और वही फाइल एक पब्लिक रिपॉजिटरी में भी मौजूद रहती है। बाद के किसी कमिट में इसे डिलीट करने से यह समस्या हल नहीं होती, क्योंकि पिछला कमिट अभी भी हिस्ट्री में इसे सुरक्षित रखता है।

होस्टेड फॉर्म सर्विसेज और बैकएंड प्लेटफॉर्म इस कमी को पूरा करते हैं, और क्लास प्रोजेक्ट के लिए यह एक उचित विकल्प है। यह स्पष्ट रखें कि इसका क्या मतलब है: रनिंग कोड किसी और के सर्वर पर चला गया है। GitHub अभी भी केवल आपके सोर्स को स्टोर कर रहा है।

GitHub Actions का उद्देश्य क्या है, यदि यह होस्टिंग नहीं है

Actions एक CI, यानी continuous integration है। यह आपके लिए एक अस्थायी मशीन पर commands चलाता है, जिसे GitHub तब शुरू करता है जब repository में कुछ होता है, जैसे कि push या pull request।

name: build
on: push
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 24
      - run: npm ci
      - run: npm test

उस मशीन को runner कहा जाता है। GitHub इस कार्य के लिए इसे बनाता है और कार्य समाप्त होने पर इसे नष्ट कर देता है, इसलिए npm start का अंतिम चरण कुछ भी होस्ट नहीं करता है। जब तक आपकी प्रक्रिया foreground में रहती है, तब तक कार्य runner को होल्ड करके रखता है, फिर workflow अपनी समय सीमा तक पहुँच जाता है और उसे kill कर दिया जाता है। इस बीच कोई भी visitor इंटरनेट से उस प्रक्रिया तक नहीं पहुँच सकता था। जब कोई step विफल हो जाता है, तो log Process completed with exit code 1 के साथ समाप्त हो जाता है, और कुछ ही सेकंड बाद मशीन गायब हो जाती है।

Actions जिस काम में वास्तव में अच्छा है, वह आपके app से संबंधित कार्य है। यह उन static files को build करता है जिनसे आपकी साइट बनी है, जैसे कि Vite या Jekyll build चलाना और output को Pages पर प्रकाशित करना। यह हर pull request पर आपके tests भी चलाता है, ताकि merge होने से पहले ही कोई खराब बदलाव पकड़ा जा सके। और यह आपके स्वामित्व वाले सर्वर से कनेक्ट होकर वहाँ deploy भी कर सकता है, जो कि अगला भाग है।

वे प्रोजेक्ट्स जिनके लिए आप यह सेवा इस्तेमाल कर सकते हैं

• एक पोर्टफोलियो या रिज्यूमे साइट, जिसे हाथ से लिखा गया हो या किसी static site generator से बनाया गया हो: हाँ। Pages को इसी उद्देश्य के लिए बनाया गया है।
• बिना backend वाली React या Vue ऐप: हाँ। build प्रक्रिया static files तैयार करती है। सबसे पहले base path को /YOUR-REPO/ पर सेट करें, अन्यथा built page डोमेन रूट पर /assets/index.js की मांग करेगा, वह path मौजूद नहीं होगा, और browser console 404 errors से भर जाएगा।
• प्रोजेक्ट डॉक्यूमेंटेशन, जिसमें ऐसी docs साइट भी शामिल है जिसका search index build के समय तैयार होता है: हाँ।
• एक contact form, या कोई भी पेज जो रिकॉर्ड स्टोर करता है: नहीं। सबमिशन प्राप्त करने और उसे सुरक्षित रखने के लिए किसी चीज़ की आवश्यकता होती है।
• username और password के साथ लॉगिन: नहीं। password चेक करने का मतलब है ऐसा कोड चलाना जिसे visitor पढ़ न सके, जबकि Pages द्वारा serve की जाने वाली हर फाइल visitor के लिए पढ़ने योग्य होती है।
• आपकी mobile app के लिए एक छोटी API (application programming interface): नहीं। API एक ऐसा प्रोग्राम है जो चलता रहता है और requests का जवाब देता है, जबकि Pages पर कोई प्रोग्राम नहीं चलता।
• कोई भी ऐसी चीज़ जिसे API key की आवश्यकता हो, जैसे कि payment service या AI model: नहीं, क्योंकि key ऐसी फाइल में होगी जिसे पूरा इंटरनेट डाउनलोड कर सकता है।
• एक पेज जो शेड्यूल के अनुसार रिफ्रेश होने वाला डेटा दिखाता है: हाँ, सीमित तरीके से। एक Actions workflow हर रात चल सकती है, डेटा fetch कर सकती है, एक अपडेटेड JSON फाइल commit कर सकती है, और फिर Pages उस फाइल को serve कर सकता है। पेज static ही रहता है और डेटा उतना ही पुराना होता है जितना कि पिछला रन।

विकल्प कैसा दिखता है: एक सर्वर जो आपका ऐप चलाता है

जिस क्षण किसी प्रोजेक्ट को कोड चलाने की आवश्यकता होती है, उसे एक ऐसे कंप्यूटर की आवश्यकता होती है जो चालू रहे और उसे चला सके। सामान्य उत्तर एक VPS (virtual private server) है: एक भौतिक मशीन का हिस्सा, जिसे मासिक किराए पर लिया जाता है, जिसमें अपना Linux इंस्टॉलेशन, अपना IP address और आपके लिए root access होता है। आपका ऐप वहां एक ऐसी service के रूप में चलता है जो बूट होने पर शुरू होती है, Nginx जैसा एक web server इसके सामने ports 80 और 443 पर स्थित होता है, और database उसी बॉक्स पर या दूसरे पर चलता है। शुरुआत से VPS की व्याख्या मशीन को कवर करती है, और लोग वास्तव में एक पर जो चीजें चलाते हैं इसके दायरे का अंदाजा देती है।

आपकी repository कहीं नहीं जाती है। GitHub वह स्थान बना रहता है जहाँ कोड रहता है और जहाँ review होता है, और सर्वर वहां से कोड pull करता है। सबसे सरल deployment सर्वर पर एक git pull है जिसके बाद service को restart किया जाता है। इससे अगला कदम एक Actions workflow है जो tests पास होने के बाद SSH (secure shell) के माध्यम से connect होता है और आपके लिए वही काम करता है, जहाँ CI एक वास्तविक host से मिलता है। आप वह जिम्मेदारी लेते हैं जिसे Pages चुपचाप संभाल रहा था: system updates, firewall, backups, और TLS (transport layer security) certificates। Gunicorn और Nginx के पीछे Django का एक कार्यशील deployment उस स्वरूप को एक छोर से दूसरे छोर तक दिखाता है, और managed बनाम unmanaged का प्रश्न यह तय करता है कि रखरखाव का कितना हिस्सा आपके पास रहेगा।

GitHub Pages की सीमाएं और उन्हें कहां देखें

Free plan के आंकड़े बदलते रहते हैं, इसलिए किसी लेख में दिए गए आंकड़ों पर भरोसा करने के बजाय GitHub के आधिकारिक पेज को देखें। सितंबर 2026 तक, GitHub Pages limits page के अनुसार प्रकाशित साइट का आकार 1 GB से अधिक नहीं होना चाहिए और प्रति माह 100 GB की soft bandwidth सीमा है। यह classic build path के लिए प्रति घंटे दस builds की soft limit का भी उल्लेख करता है।

उसी पेज पर एक नियम दिया गया है जो किसी भी संख्या से अधिक महत्वपूर्ण है। Pages का उपयोग किसी ऑनलाइन व्यवसाय या e-commerce साइट के लिए free web hosting के रूप में नहीं किया जाना चाहिए, और वहां मौजूद साइटों को पासवर्ड या कार्ड नंबर जैसे संवेदनशील लेनदेन को हैंडल नहीं करना चाहिए। Actions का समय एक अलग कोटा है, जिसमें public और private repositories की गणना अलग-अलग की जाती है, और GitHub ने इसे अपने Actions billing page पर प्रलेखित किया है। किसी भी योजना को बनाने से पहले दोनों पेजों की जांच करें।

FAQ

क्या मैं GitHub Pages पर Node.js या Python ऐप होस्ट कर सकता हूँ?

नहीं। Pages फाइलों को बिल्कुल वैसे ही लौटाता है जैसे वे स्टोर की गई हैं, इसलिए Node के लिए लिखी गई .js फाइल, या .py फाइल, ब्राउज़र में निष्पादित (execute) होने के बजाय टेक्स्ट के रूप में भेजी जाती है। यदि आप इसे curl के साथ रिक्वेस्ट करेंगे, तो आपका अपना सोर्स कोड वापस आ जाएगा। सर्वर कोड चलाने के लिए एक ऐसी मशीन की आवश्यकता होती है जो हमेशा चालू रहे, जैसे कि VPS या कोई ऐसा प्लेटफॉर्म जो आपके लिए एप्लिकेशन चलाता हो। GitHub Actions भी इस कमी को पूरा नहीं करता है, क्योंकि जॉब खत्म होते ही इसका रनर डिलीट कर दिया जाता है।

मेरी GitHub Pages साइट "There isn't a GitHub Pages site here." क्यों दिखा रही है?

यह पेज तब दिखाई देता है जब URL मौजूद तो होता है लेकिन उसके अंतर्गत कुछ भी पब्लिश नहीं होता है। इसके सामान्य कारण हैं: बिल्ड का पूरा न होना, या Pages का किसी ऐसी ब्रांच या फोल्डर की ओर इशारा करना जिसमें index.html मौजूद न हो। Settings खोलें, फिर Pages पर जाएं, और पुष्टि करें कि कौन सी ब्रांच और फोल्डर चुने गए हैं। जांचें कि फाइल का नाम छोटे अक्षरों में index.html है, क्योंकि URL केस-सेंसिटिव होते हैं। यदि कोई वर्कफ़्लो साइट को बिल्ड करता है, तो पुष्टि करें कि उसका नवीनतम रन सफलतापूर्वक पूरा हो गया है।

क्या GitHub Pages साइट डेटाबेस में डेटा सेव कर सकती है?

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

क्या GitHub Pages पोर्टफोलियो साइट के लिए पर्याप्त है?

हाँ। पोर्टफोलियो एक स्टेटिक कंटेंट है, जिसे Pages सबसे बेहतर तरीके से हैंडल करता है। आपको HTTPS के साथ एक पब्लिक URL मिलता है और हर पुश पर साइट फिर से बिल्ड हो जाती है। कस्टम डोमेन भी काम करता है: अपने DNS रिकॉर्ड्स को GitHub की ओर पॉइंट करें और Pages सेटिंग्स में डोमेन सेट करें। सर्वर पर तभी जाएं जब आप कुछ ऐसा जोड़ें जिसे रन करने की आवश्यकता हो, जैसे कि कोई कॉन्टैक्ट फॉर्म जो प्राप्त संदेशों को स्टोर करता हो।