Vercel Hobby Plan की सीमाएँ (और कब आप उनसे आगे निकल जाते हैं)

यह गुरुवार की रात थी और एक client की Next.js साइट ने जो कुछ मैं सिर्फ एक timeout spiral कह सकता हूँ, उस स्थिति में चली गई। Serverless functions 9.8 सेकंड पर लटके हुए, users को खाली स्क्रीनें मिल रही थीं, और मैं आधी रात को Vercel dashboard को घबराते हुए check कर रहा था यह पता लगाने की कोशिश में कि हम वाकई plan की सीमा तक पहुँचे हैं या code ही बस भयानक था। (यह दोनों ही था, ईमानदारी से कहूँ तो।) वह project Hobby plan पर था। शायद वह नहीं होना चाहिए था।

मैंने Seahawk Media में अपने सालों भर 12,000 से ज़्यादा sites deploy किए हैं। Vercel लगातार हमारे stack का हिस्सा है, खासकर Next.js काम के लिए, कुछ और इसके करीब भी नहीं आता developer experience के लिए। लेकिन Hobby plan में sharp edges हैं जो project को काटने तक अनदेखे रहना आसान है। तो यहाँ मेरी असली समझ है कि वह edges कहाँ हैं और कब उन्हें मायने आने लगता है।

Hobby Plan आपको असल में क्या देता है

चलिए सटीक हो जाते हैं। 2024 तक, Vercel की Hobby plan आपको यह देती है:Vercel's Hobby plan gives you:

• 100 GB bandwidth प्रति महीने
• प्रति माह 6,000 बिल्ड मिनट
• सर्वरलेस फ़ंक्शन एक्जीक्यूशन टाइमआउट 10 सेकंड का10 seconds
• 100 सर्वरलेस फ़ंक्शन इनवोकेशन प्रति दिन... रुकिए, नहीं। वह लिमिट मौजूद नहीं है। लेकिन प्रति माह सर्वरलेस फ़ंक्शन एक्जीक्यूशन की 100 GB-घंटे की कैप है
• प्रति माह Edge फ़ंक्शन एक्जीक्यूशन की 500,000 इनवोकेशन
• एक बार में 1 कंकरेंट बिल्ड
• डिप्लॉयमेंट सिर्फ़ पर्सनल अकाउंट तक सीमित (कोई टीम नहीं)personal accounts only (no teams)
• Vercel की शर्तों के अनुसार कोई कमर्शियल उपयोग की अनुमति नहीं

यह आखिरी वाला किसी भी टेक्निकल लिमिट से ज़्यादा लोगों को उलझन में डालता है। Hobby प्लान स्पष्ट रूप से पर्सनल, गैर-कमर्शियल प्रोजेक्ट के लिए है। अगर आप किसी पेइंग क्लाइंट के लिए बना रहे हैं या इस पर कोई भी बिज़नेस चला रहे हैं, तो आप पहले से ही सर्विस की शर्तों का उल्लंघन कर रहे हैं। मैंने फ्रीलांसरों को यह सालों से करते देखा है और यह एक लायबिलिटी है जो इंतज़ार में है।

10-सेकंड फ़ंक्शन टाइमआउट

यह वह है जो लोगों को परेशान करता है। दस सेकंड बहुत सा लगता है जब तक कि आप कोई थर्ड-पार्टी API कॉल नहीं कर रहे हों जो 4 सेकंड लेता है, कुछ डेटाबेस लॉजिक चलाते हैं जो अतिरिक्त 3 सेकंड जोड़ता है, और फिर रेस्पांस के साथ कुछ करते हैं। अचानक आप 9.2 सेकंड पर हैं और कोई मार्जिन नहीं है।

Pro plan पर यह सीमा 60 सेकंड तक बढ़ जाती है (और Enterprise पर कॉन्फ़िगरेशन के साथ 900 सेकंड तक)। यह कोई मामूली अंतर नहीं है। यह एक काम करने वाले integration और एक ऐसे प्रोडक्ट के बीच का अंतर है जो कुछ use cases के लिए बुनियादी तौर पर टूटा हुआ है।

Build Minutes: जहां वे आपकी सोच से तेजी से गायब होते हैं

महीने में 6,000 build minutes उदार लगते हैं। और एक single personal project के लिए शायद यह है। समस्या यह है कि यह संख्या तब तेजी से घटती है जब आप गंभीरता से iterate करना शुरू करते हैं।

2021 में मैं एक side project चला रहा था, एक content aggregator जो Next.js पर बना था और इसमें लगभग 400 static pages थे। मेरे पास ISR सेटअप था लेकिन मैं data layer के साथ experiment करते समय बार-बार full rebuilds भी कर रहा था। तीन हफ्तों में लगभग 4,200 build minutes खर्च हो गए। यह इसलिए नहीं कि builds slow थे, बल्कि इसलिए कि मैं उन्हें लगातार trigger कर रहा था।

एक medium-complexity Next.js site पर प्रत्येक build आसानी से 4-8 मिनट चल सकता है। अगर आप सक्रिय development के दौरान main में दिन में 15 बार push कर रहे हैं (जो मेरे लिए सामान्य है), तो एक ही दिन में 60-120 build minutes चले जाते हैं। इसे एक हफ्ते के लिए करें और आप अपने monthly allocation का आधा खर्च कर देंगे।

कोई rollover नहीं है। Minutes महीने दर महीने carry over नहीं होते हैं। और जब आप zero पर पहुंच जाते हैं, आपके deployments रुक जाते हैं। पूरी तरह।

Burn को कैसे धीमा करें

Hobby plan projects पर build minutes को preserve करने के लिए मैं कुछ चीजें करता हूं:

1. Experimental changes के लिए एक non-production branch में push करें। केवल तभी main में merge करें जब कुछ actually ready हो।
2. vercel --prebuilt का उपयोग करें cached outputs के साथ जहां build artefacts meaningfully नहीं बदले हैं।vercel --prebuilt with cached outputs where the build artefacts haven't changed meaningfully.
3. Vercel के ignored build step को सेट करें ताकि सिर्फ कुछ ही फाइलें बदलने पर (जैसे readme अपडेट या non-code commits पर) builds को skip किया जा सके।Vercel's ignored build step to skip builds when only certain files change (like readme updates or non-code commits).
4. Commits को batch करें। 6 छोटी fixes को अलग-अलग push करने की जगह, उन्हें stage करें और एक बार push करें।

यह कुछ नया नहीं है। लेकिन वास्तव में Hobby plans पर ज्यादातर developers बस freely push करते हैं और महीने के 20वें दिन तक minutes खत्म होने का कारण सोचते हैं।

Bandwidth: आमतौर पर ठीक है, कभी-कभी नहीं

प्रति महीने 100 GB bandwidth वह जगह है जहाँ Hobby plan वाकई काफी reasonable है। एक personal project के लिए, एक portfolio के लिए, एक छोटे blog के लिए, यहाँ तक कि कुछ सौ users वाले एक modest SaaS side project के लिए, आप शायद उस सीमा तक नहीं पहुँचेंगे।

जहाँ यह काटता है वह है image-heavy sites जिनके सामने कोई proper CDN layer नहीं है, या sites जिन्हें अचानक spike मिलता है। मेरे पास एक client था, एक musician, जिसकी site transition period के दौरान मेरे personal Vercel account पर थी (मेरी गलती थी, commercial use और सब कुछ)। उनके एक track को एक decent-sized playlist में pick किया गया और site को 48 घंटों में लगभग 40,000 visits मिले। Bandwidth usage बढ़ गया। शुक्र है कि हम cap के नीचे थे लेकिन यह काफी करीब था कि मैंने उन्हें Hobby से तुरंत हटा दिया।

अगर आप Next.js Image Optimisation का उपयोग कर रहे हैं, तो जान लें कि Vercel के माध्यम से परोसी गई optimised images आपकी bandwidth के विरुद्ध count करती हैं। और Hobby plan के पास प्रति महीने optimisation के लिए 1,000 source images की cap है। यह एक ऐसी limit है जिस पर लगभग कोई बात नहीं करता और यह आपको बिल्कुल पकड़ लेगी अगर आप एक photography portfolio या कोई image-heavy content site चला रहे हैं।Next.js Image Optimisation, be aware that optimised images served through Vercel count against your bandwidth. And the Hobby plan has a 1,000 source images cap on optimisation per month. That's a limit that almost nobody talks about and it will absolutely catch you if you're running a photography portfolio or any image-heavy content site.

Commercial Use की बात अधिक ध्यान देने योग्य है

मैं इसे फिर से लाना चाहता हूँ क्योंकि मुझे लगता है कि यह genuinely freelance circles में underappreciated है।

Vercel की terms स्पष्ट हैं। Hobby personal, non-commercial projects के लिए है। जिस पल एक client आपको Hobby पर कुछ बनाने के लिए pay करता है, या जिस पल एक project revenue generate करता है (ads, subscriptions, sales), आप terms के बाहर हैं। यह Vercel का aggressive होना नहीं है, यह सिर्फ है कि plan कैसे structured है।

मैंने फ्रीलांसरों से बात की है जो क्लाइंट का काम Hobby पर डिप्लॉय करते हैं ताकि खर्च बचा सकें। कुछ लोगों ने इसे सालों तक बिना किसी समस्या के किया है। लेकिन Vercel इसे लागू करता है। वे commercially active दिखने वाले accounts को contact कर सकते हैं और करते हैं। terms violation की वजह से साइट हटना जबकि क्लाइंट का बिजनेस उस पर निर्भर है — यह एक ऐसी बातचीत नहीं है जो आप करना चाहते हैं।

Pro plan $20/month प्रति member है। किसी भी actual client work के लिए, वह cost आपके project budget में शामिल होना चाहिए। यह negotiable नहीं है।

जब Single Concurrent Build वाकई समस्या बन जाती है

Personal projects के लिए एक concurrent build मायने नहीं रखता। यह तब मायने रखने लगता है जब आप किसी काम पर collaboratively काम कर रहे हों, भले ही informal तरीके से। दो लोग जल्दी-जल्दी commits push करते हैं तो दूसरा build पहले के पीछे queue में लग जाता है।

Solo work के लिए, यह कोई समस्या नहीं है। लेकिन अगर आपके पास कोई contributor है, कोई co-founder है, या कोई designer है जो commit भी कर सकता है, तो आप queue time notice करेंगे। Pro पर आपको 12 concurrent builds तक मिलते हैं। यह jump काफी बड़ा है।

Seahawk के पास इस साल की शुरुआत में एक छोटा internal tools project था जहाँ दोनों लोग एक sprint के दौरान same Next.js codebase पर quickly iterate कर रहे थे। हमने उसके लिए Pro पर थे (commercial reason की वजह से अकेले), और फिर भी overlapping builds कभी-कभी friction पैदा करते थे। Hobby पर यह noticeably बदतर होता।

Hobby vs Pro: असली Decision Tree

मैं इसके बारे में practically सोचता हूँ:

• Personal project, कोई revenue नहीं, solo dev, 50 pages से कम: Hobby ठीक है। वहीं रहें। Hobby is fine. Stay there.
• Side project जिसे real traffic मिल रहा है (5,000+ monthly visits): अपनी bandwidth और function execution hours पर नजर रखना शुरू करें। Hobby अभी भी काम करता है लेकिन आप edges के करीब हैं। Start watching your bandwidth and function execution hours. Hobby still works but you're closer to edges.
• किसी भी तरह का क्लाइंट वर्क: Pro. बस इतना ही। Pro. Full stop.
• API-heavy ऐप जहाँ serverless functions नियमित रूप से 5+ सेकंड के पास पहुँचते हैं: Pro. 10-सेकंड की timeout इस बिंदु पर आरामदायक ceiling नहीं है। Pro. The 10-second timeout is not a comfortable ceiling at that point.
• अकाउंट पर कई team members की जरूरत है: Pro. Hobby team accounts की अनुमति नहीं देता। Pro. Hobby doesn't allow team accounts.
• ई-कॉमर्स, subscriptions, या कोई भी transactional flow चला रहे हैं: Pro, और शायद ध्यान से सोचें कि क्या Vercel का serverless model आपकी architecture के लिए उपयुक्त है। Pro, and probably think carefully about whether Vercel's serverless model suits your architecture anyway.

जो कुछ भी Pro से भी आगे निकल जाए, Vercel के पास Enterprise tier है custom limits के साथ। मैंने Enterprise को सिर्फ दो बार छुआ है, दोनों बार ऐसे क्लाइंट्स के लिए जिनके पास बहुत specific SLA requirements थीं। इस text को पढ़ने वाले अधिकांश लोगों के लिए, Pro/Hobby decision ही relevant है।

जानने लायक विकल्प

अगर budget सचमुच constraint है, तो Vercel आपका एकमात्र विकल्प नहीं है। Netlify का free tier Vercel Hobby के समान shape है 300 build minutes प्रति महीने के साथ (Vercel से कम, दरअसल) लेकिन 100 GB bandwidth। Static sites के लिए minimal serverless needs के साथ, Netlify एक reasonable comparison है।Netlify's free tier has similar shape to Vercel Hobby with 300 build minutes per month (lower than Vercel, actually) but 100 GB bandwidth. For static sites with minimal serverless needs, Netlify is a reasonable comparison.

Cloudflare Pages विचार करने लायक है अगर आपका use case Workers के लिए fit करता है। Free tier पर unlimited bandwidth, generous build allowances, और Pages platform काफी mature हो गया है। मैं इसे static sites के लिए use करता हूँ जहाँ मुझे Next.js-specific features की जरूरत नहीं है। is worth considering if your use case fits Workers. Unlimited bandwidth on the free tier, generous build allowances, and the Pages platform has matured significantly. I use it for static sites where I don't need Next.js-specific features.

Railway और Render full-stack apps के लिए अच्छे हैं जहाँ आप serverless deployment model से ज्यादा control चाहते हैं। विभिन्न tradeoffs, बिल्कुल Vercel competitors नहीं, लेकिन आपके toolkit में होने लायक हैं।

FAQ

क्या Vercel Hobby plan में कस्टम डोमेन की अनुमति है?

हाँ। आप Hobby पर कस्टम डोमेन बिना कुछ भुगतान किए जोड़ सकते हैं। SSL स्वचालित रूप से Let's Encrypt के माध्यम से शामिल है। यह Hobby की वास्तव में शानदार चीजों में से एक है, कस्टम डोमेन पर कोई कृत्रिम सीमा नहीं है।

जब आप Hobby plan की बैंडविड्थ सीमा तक पहुंच जाते हैं तो क्या होता है?

Vercel तुरंत आपकी साइट को बंद नहीं करता। वे आपको सूचित करेंगे और अपग्रेड करने का विकल्प देंगे। लेकिन एक बार जब आप सीमा से अधिक हो जाते हैं तो आप एक अस्पष्ट क्षेत्र में होते हैं और Vercel थ्रॉटल कर सकता है या अगर आप बिना अपग्रेड किए लगातार सीमा से अधिक रहते हैं तो निलंबित कर सकता है।

अगर मैं ज्यादा चार्ज नहीं कर रहा हूँ तो क्या मैं Vercel Hobby का उपयोग क्लाइंट प्रोजेक्ट के लिए कर सकता हूँ?

आप कितना चार्ज करते हैं यह Vercel की शर्तों के लिए अप्रासंगिक है। व्यावसायिक उपयोग का मतलब व्यावसायिक उपयोग है। अगर कोई आपको भुगतान कर रहा है, तो यह व्यावसायिक है। Pro में जाएँ।

क्या 10-सेकंड फंक्शन टाइमआउट एक कठोर सीमा है या नरम?

कठोर। फंक्शन को Hobby पर 10 सेकंड पर मार दिया जाता है। आप एक 504 टाइमआउट त्रुटि देखेंगे। Hobby स्तर पर इसे बढ़ाने के लिए कोई कॉन्फ़िगरेशन उपलब्ध नहीं है।

क्या दो लोग Hobby प्रोजेक्ट पर सहयोग कर सकते हैं?

साझा टीम खाते के माध्यम से नहीं। Hobby केवल व्यक्तिगत खातों के लिए है। आप किसी विशिष्ट प्रोजेक्ट में सहयोगी जोड़ सकते हैं (वे Git के माध्यम से कोड में योगदान दे सकते हैं), लेकिन Vercel खाता और बिलिंग एक व्यक्ति के पास रहता है। वास्तविक टीम वर्कफ़्लो के लिए आपको Pro की आवश्यकता है।

---

Hobby योजना वास्तव में इसके लिए अच्छी है जो वह कहती है: शौक की परियोजनाएँ। सीमाएँ व्यक्तिगत उपयोग के लिए उचित हैं। लोग जहाँ परेशानी में पड़ते हैं वह है इसे एक मुफ्त Pro tier मानना। यह नहीं है। सीमाओं को जानिए, व्यावसायिक उपयोग की शर्तों का सम्मान करिए, और जब कोई परियोजना पैसा कमाने लगे या असली उपयोगकर्ताओं को सेवा देने लगे, तो $20 प्रति माह का भुगतान करिए। यह जोखिम लायक नहीं है।