यह गुरुवार की रात थी और एक 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 आपको यह देती है:
100 GB bandwidth प्रति महीने
प्रति माह 6,000 बिल्ड मिनट
सर्वरलेस फ़ंक्शन एक्जीक्यूशन टाइमआउट 10 सेकंड का
100 सर्वरलेस फ़ंक्शन इनवोकेशन प्रति दिन... रुकिए, नहीं। वह लिमिट मौजूद नहीं है। लेकिन प्रति माह सर्वरलेस फ़ंक्शन एक्जीक्यूशन की 100 GB-घंटे की कैप है
प्रति माह Edge फ़ंक्शन एक्जीक्यूशन की 500,000 इनवोकेशन
एक बार में 1 कंकरेंट बिल्ड
डिप्लॉयमेंट सिर्फ़ पर्सनल अकाउंट तक सीमित (कोई टीम नहीं)
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 करने के लिए मैं कुछ चीजें करता हूं:
Experimental changes के लिए एक non-production branch में push करें। केवल तभी main में merge करें जब कुछ actually ready हो।
vercel --prebuilt का उपयोग करें cached outputs के साथ जहां build artefacts meaningfully नहीं बदले हैं।
Vercel के ignored build step को सेट करें ताकि सिर्फ कुछ ही फाइलें बदलने पर (जैसे readme अपडेट या non-code commits पर) builds को skip किया जा सके।
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 चला रहे हैं।
Commercial Use की बात अधिक ध्यान देने योग्य है
मैं इसे फिर से लाना चाहता हूँ क्योंकि मुझे लगता है कि यह genuinely freelance circles में underappreciated है।