पिछले साल एक सोमवार की सुबह एक क्लायंट ने मुझे फोन किया। मैसेज नहीं। फोन कॉल। यह कभी अच्छा नहीं होता। उसने पिछले गुरुवार को Vercel के Pro प्लान पर एक Next.js मार्केटिंग साइट डिप्लॉय की थी, सप्ताहांत पर एक प्रोडक्ट लॉन्च किया, और जागकर अपने इनबॉक्स में $340 का इनवॉइस देखा। साइट शानदार रही थी। ट्रैफिक स्पाइक हुई। और Vercel ने चुपचाप उनके नेटवर्क से निकलने वाले हर गीगाबाइट डेटा को मापा। उसके पास कोई स्पेंडिंग कैप सेट नहीं था। कोई अलर्ट कॉन्फ़िगर नहीं। कुछ नहीं।
वह कॉल ही कारण है कि अब मैं किसी भी प्रोडक्शन-ग्रेड डिप्लॉयमेंट से पहले हर क्लायंट के साथ Vercel बिलिंग हाइजीन पर बीस मिनट खर्च करता हूँ।
यहाँ देखें कि आपको Vercel पर बैंडविड्थ चार्जेस कैसे होते हैं, यह मुद्दा लोगों को आश्चर्यजनक क्यों लगता है, और इसके बारे में वास्तव में क्या करें।
---
Vercel पर "Egress" का असली मतलब क्या है
Egress वह डेटा है जो Vercel के नेटवर्क से बाहर निकलकर अंतिम उपयोगकर्ता तक पहुंचता है। हर इमेज, हर JavaScript बंडल, हर API प्रतिक्रिया, हर फॉन्ट फाइल। अगर यह उनके edge से निकलकर ब्राउज़र तक पहुंचती है, तो गिनी जाती है।out of Vercel's network to the end user. Every image, every JavaScript bundle, every API response, every font file. If it leaves their edge and hits a browser, it counts.
Hobby प्लान पर आपको प्रति माह 100GB बैंडविड्थ मिलता है, शामिल है। Pro पर यह 1TB है। सुनने में बहुत लगता है। लेकिन बात यह है: अगर आप बड़ी इमेजें serve कर रहे हैं, भारी JSON पेलोड वाले पेजों पर सर्वर-साइड रेंडरिंग कर रहे हैं, या आपके ऐप को अचानक ट्रैफिक स्पाइक आता है, तो आप 1TB को जितना सोचते हैं उससे कहीं तेजी से पार कर सकते हैं। Vercel इस लेखन के समय Pro पर overage के लिए $0.15 प्रति GB चार्ज करता है (हमेशा उनके मौजूदा pricing पेज को चेक करें क्योंकि यह बदलता रहता है)।their current pricing page because this moves).
तो 500GB आपकी limit से ऊपर $75 है। विनाशकारी नहीं। लेकिन एक viral moment, एक गड़बड़ाया गया image optimisation सेटअप, या कोई scraper आपके API routes को hammer कर रहा हो? यह हजारों तक जा सकता है।
यह लोगों को अचंभित क्यों करता है
बात यह है कि local development आपको शून्य संकेत देता है। आप तेजी से बनाते हैं, तेजी से deploy करते हैं, सब कुछ ठीक लगता है। Vercel का dashboard बैंडविड्थ उपयोग दिखाता है लेकिन यह चीखता नहीं है। अगर आपने proactively एक billing alert सेट नहीं किया, तो आप जानते हैं जब invoice आता है।
---
वह Configs जो आपके Bill को तबाह करने की सबसे अधिक संभावना रखते हैं
मैंने Seahawk पर बहुत सारे deployments को audit किया है। मुझे चार culprits बार-बार दिखाई देते हैं।
1. Unoptimised Images जो next/image को Bypass करते हैं
next/image वास्तव में अपने काम में अच्छा है। यह resize करता है, WebP में convert करता है, और cache करता है। लेकिन मैंने ऐसी projects देखी हैं जहां developers सीधे एक <img> tag से इमेजें pull कर रहे थे जो S3 bucket में full-resolution फाइलों की ओर point करता था, Vercel API route के through proxied। हर request एक 4MB JPEG को Vercel के नेटवर्क के through pull कर रहा था बजाय 200KB WebP के एक CDN edge से। इसे 50,000 page views से गुणा करें और गणित करें। is genuinely good at what it does. It resizes, converts to WebP, and caches. But I've seen projects where developers were pulling images straight from an <img> tag pointing at full-resolution files in an S3 bucket, proxied through a Vercel API route. Every request was pulling a 4MB JPEG through Vercel's network instead of a 200KB WebP from a CDN edge. Multiply that by 50,000 page views and do the maths.
हमेशा next/image का उपयोग करें और सही remotePatterns config के साथ करें। अगर image source बाहरी है, तो सुनिश्चित करें कि वह CDN cache को hit कर रहा है और आपके serverless functions के through कोई round trip नहीं बना रहा है।next/image with a proper remotePatterns config. If the image source is external, make sure it's hitting the CDN cache and not making a round trip through your serverless functions.
2. API Routes जो Fat Payloads Return करते हैं
2021 में मैंने एक UK retailer के लिए एक e-commerce product catalogue बनाया था। उनका API route अपने database से product listing fetch कर रहा था और पूरे product object को return कर रहा था, उन fields सहित जिन्हें front end कभी use ही नहीं करता था। Description, internal SKU notes, variant metadata — सब कुछ। हर response लगभग 80KB था जबकि उसे केवल 12KB की जरूरत थी।entire product object, including fields the front end never used. Description, internal SKU notes, variant metadata, the lot. Each response was around 80KB instead of the 12KB it needed to be.
अपने API responses को trim करें। केवल वे fields return करें जिन्हें client वास्तव में consume करता है। अगर आप Prisma जैसी किसी चीज़ का उपयोग कर रहे हैं, तो select का उपयोग करें और जो pull करते हैं उसे सीमित करें। अगर आप किसी third-party API का उपयोग कर रहे हैं, तो payload को transform और slim करें उसे downstream भेजने से पहले।select to limit what you pull. If you're using a third-party API, transform and slim the payload before sending it downstream.
3. ISR With Short Revalidation Windows on High-Traffic Routes
Incremental Static Regeneration सिद्धांत में शानदार है। व्यवहार में, अगर आप revalidate: 30 को एक page पर सेट करते हैं जिसे प्रति मिनट 10,000 hits मिलते हैं, तो आप सही तरीके से cache कर रहे हैं। लेकिन अगर आप revalidate: 1 पर सेट करते हैं क्योंकि आप near-real-time updates चाहते थे और इसे change करना भूल गए... तो आप मूलतः SSR कर रहे हैं extra steps के साथ और हर near-miss cache response पर egress के लिए payment कर रहे हैं।revalidate: 30 on a page that gets 10,000 hits per minute, you're still caching correctly. But if you set it to revalidate: 1 because you wanted near-real-time updates and forgot to change it... you're basically doing SSR with extra steps and paying for the egress on every near-miss cache response.
अपने revalidation windows के बारे में जानबूझकर सोचें। अधिकांश content को हर सेकंड revalidate करने की जरूरत नहीं है।
4. Serverless Functions With No Caching Headers
यह एक सूक्ष्म बात है। अगर आपके serverless function response में Cache-Control header नहीं है (या Vercel का s-maxage / stale-while-revalidate combo), तो response edge पर cache नहीं होता है। हर request function को hit करता है और पूरा round trip travel करता है। आप CDN benefit पूरी तरह से खो देते हैं और हर single response पर egress के लिए payment करते हैं।Cache-Control header (or Vercel's s-maxage / stale-while-revalidate combo), the response is not cached at the edge. Every request hits the function and travels the full round trip. You lose the CDN benefit entirely and pay egress on every single response.
`` Cache-Control: s-maxage=3600, stale-while-revalidate=86400 `` Cache-Control: s-maxage=3600, stale-while-revalidate=86400 ``
उस हेडर ने अकेले ही क्लाइंट्स के लिए असल पैसे बचाए हैं। गंभीरता से। Vercel के अपने ही कैशिंग डॉक्स हेडर बिहेवियर को विस्तार से समझाते हैं। एक बार सही से पढ़ लीजिए।Vercel's own caching docs explain the header behaviour in detail. Read them once properly.
---
बिलिंग अलर्ट सेटअप कैसे करें (इससे पहले कि आपको जरूरत पड़े)
किसी भी प्रोडक्शन डिप्लॉय से पहले यह पहला स्टेप होना चाहिए। सातवां नहीं।
- अपनी Vercel टीम सेटिंग्स में जाइए।
- Billing के अंतर्गत Spend Management खोजें।Billing , find Spend Management.
- एक स्पेंड लिमिट सेट करें (हार्ड कैप, जहां Vercel लिमिट के बाद रिक्वेस्ट्स सर्व करना बंद कर देता है) या एक नोटिफिकेशन थ्रेसहोल्ड (सॉफ्ट अलर्ट, जब आप किसी नंबर तक पहुंचें तो आपको ईमेल भेजता है)।spend limit (hard cap, where Vercel stops serving requests after the limit) or a notification threshold (soft alert, emails you when you hit a number).
- मैं सुझाव देता हूं कि 50% पर एक नोटिफिकेशन सेट करें — जो आपको दर्दनाक लगता है उसका — और एक हार्ड लिमिट अपने अपेक्षित मासिक बिल के करीब 120% पर रखें।
हार्ड कैप दोधारी चीज है। अगर आप इसे हिट करते हैं, तो आपकी साइट डाउन हो जाती है। तो सोच-समझ कर निर्णय लीजिए। एक मार्केटिंग साइट के लिए? ठीक है, इसे सख्ती से कैप करें। एक SaaS के लिए पेइंग यूजर्स के साथ? उदार नोटिफिकेशन्स सेट करें और डैशबोर्ड पर नजर रखें।
---
भारी काम को कहीं और भेज देना
Vercel एक CDN नहीं है स्टैटिक असेट्स के लिए। मतलब, इसके पास CDN तो है, लेकिन आप इसके लिए प्रति गीगाबाइट पेमेंट कर रहे हैं। बड़ी मात्रा में स्टैटिक असेट्स के लिए, इन्हें कहीं सस्ते में रखें।
मैं लगभग अठारह महीने से Cloudflare R2 के माध्यम से बड़ी मीडिया फाइलें भेज रहा हूँ। R2 के कोई एग्रेस फीस नहीं हैं। आप स्टोरेज और ऑपरेशन्स के लिए पेमेंट करते हैं, डेटा निकालने के लिए नहीं। इमेज-भरी वेबसाइटों के लिए यह गंभीर बचत है। मेरे एक क्लाइंट के पास फोटोग्राफी पोर्टफोलियो प्लेटफॉर्म है और वह Vercel एग्रेस में लगभग $180/माह पेमेंट कर रहा था। हमने सभी फुल-रेज इमेजेज और गैलरी असेट्स को R2 में स्थानांतरित किया, थंबनेल को next/image के माध्यम से रखा, और Vercel का बिल $40 से नीचे गिर गया।Cloudflare R2 for about eighteen months now. R2 has zero egress fees. You pay for storage and operations, not for the data going out. For image-heavy sites this is a serious saving. A client of mine runs a photography portfolio platform and was paying around $180/month in Vercel egress. We moved all the full-res images and gallery assets to R2, kept the thumbnails going through next/image, and the Vercel bill dropped to under $40.
जानने लायक विकल्प:
- Cloudflare Pages स्टैटिक डिप्लॉयमेंट के लिए जहाँ आपको Vercel की edge सुविधाओं की जरूरत नहीं है। उदार फ्री टियर, कोई एग्रेस फीस नहीं। for static deployments where you don't need Vercel's edge features. Generous free tier, no egress fees.
- AWS CloudFront S3 के सामने अगर आप पहले से AWS इकोसिस्टम में हैं। ट्रांसफर लागत Vercel की ओवरेज दरों से स्केल पर कम है। in front of S3 if you're already in the AWS ecosystem. Transfer costs are lower than Vercel's overage rates at scale.
- BunnyCDN शुद्ध असेट डिलीवरी के लिए सस्ता और तेज़ है। मैंने इसे कुछ उच्च-ट्रैफिक WordPress-to-Next.js माइग्रेशन्स पर इस्तेमाल किया है जहाँ असेट वॉल्यूम बड़ा था। is cheap and fast for pure asset delivery. I've used it on a few high-traffic WordPress-to-Next.js migrations where the asset volume was large.
मुद्दा यह है: Vercel आपके Next.js एप्लिकेशन लॉजिक चलाने के लिए सही जगह है। यह हमेशा आपके गीगाबाइट्स मीडिया परोसने के लिए सही जगह नहीं है।
---
रीयल टाइम में उपयोग की निगरानी करना
महीने के अंत में अपने डैशबोर्ड को चेक न करें। यही वजह है कि मेरा क्लाइंट सोमवार को मुझे फोन करने के लिए मजबूर हुआ।
कुछ चीजें जो मैं वास्तव में उपयोग करता हूं:
- Vercel Analytics आपको पेज-लेवल डेटा देता है और यह पहचानने के लिए उपयोगी है कि कौन से रूट सबसे ज्यादा ट्रैफिक (और इसलिए सबसे ज्यादा egress) जेनरेट कर रहे हैं। gives you page-level data and is useful for spotting which routes are generating the most traffic (and therefore the most egress).
- Axiom Vercel के log drains के साथ साफ-सुथरे तरीके से इंटीग्रेट करता है और आपको समय के साथ request size को क्वेरी करने देता है। मैंने इसे 2022 के अंत में उपयोग करना शुरू किया और यह बड़े प्रोजेक्ट्स पर ट्रैफिक स्पाइक्स को egress jumps के साथ correlate करने के लिए उपयोगी रहा है। integrates cleanly with Vercel's log drains and lets you query request size over time. I started using it in late 2022 and it's been useful on bigger projects for correlating traffic spikes with egress jumps.
- एक सरल cron सेट करें (Vercel के पास अब native cron support है) जो उनके API को हिट करे और जब bandwidth एक threshold पार करे तो Slack चैनल पर पोस्ट करे। मैंने Seahawk के अपने infrastructure के लिए इसका एक lightweight version बनाया। दो घंटे लगते हैं, बहुत सारी चिंता बचाता है।
Vercel REST API deployment और usage डेटा को expose करता है। यह दुनिया का सबसे elegant API नहीं है लेकिन यह basic alerting के लिए जो चाहिए वह करता है।Vercel REST API exposes deployment and usage data. It's not the most elegant API in the world but it does what you need for basic alerting.
---
आर्किटेक्चर का फैसला जिस पर कोई बात नहीं करता
यहां कुछ ऐसा है जो मुझे पर्याप्त चर्चित नहीं दिख रहा: कभी-कभी Vercel गलत default होता है।
अगर आपका प्रोजेक्ट कोई real dynamic functionality के बिना एक static marketing site है, तो आपको Vercel की जरूरत नहीं है। Cloudflare Pages या Netlify का free tier zero egress concerns के साथ काम कर देगा। आप Vercel को "बर्बाद" नहीं कर रहे, आप बस workload के लिए सही टूल में नहीं हैं।
दूसरी ओर, अगर आप edge middleware, server components और असली काम करने वाले API routes के साथ एक सही Next.js app बना रहे हैं, तो Vercel के लिए पैसे देना काबिले-ग़ौर है। DX सच में शानदार है और edge network तेज़ है। बस शुरुआत से ही इसे सही तरीक़े से डिज़ाइन करो।
मैंने अपने करियर की शुरुआत में (2016 के आस-पास, जब Vercel का अस्तित्व ही नहीं था, जब मैं Heroku और Netlify पर deployment को समझ रहा था) जो ग़लती की वह यह थी कि deployment platform को एक free afterthought मानना। Platform का चुनाव आपके cost profile को उतना ही shape करता है जितना आपके database का चुनाव करता है। इसे गंभीरता से लो।
---
FAQ
अगर मैं 100GB से ज़्यादा चली जाऊँ तो Hobby plan पर egress charges लगते हैं?
नहीं। Hobby plan पर Vercel overage का charge नहीं करता; जब तुम limit तक पहुँचो तो वह deployment को throttle या suspend कर देता है। किसी भी तरीक़े से बहुत अच्छा नहीं है, लेकिन तुम्हें कोई आश्चर्य वाला बिल नहीं आएगा। आश्चर्य वाले बिल Pro और Enterprise पर होते हैं जहाँ included amount के ऊपर usage metered होता है।
क्या Vercel का image optimisation egress में count होता है?
हाँ। next/image के ज़रिए serve किए गए optimised images भी egress में count होते हैं। बचत file size में है: तुम 3MB वाली JPEG की जगह 180KB WebP serve कर रहे हो, तो image के लिए egress बहुत कम है। Optimisation वही चीज़ है जो cost को कम करती है, कोई special exemption नहीं।next/image still count as egress. The saving is in file size: you're serving a 180KB WebP instead of a 3MB JPEG, so the egress per image is much lower. The optimisation itself is what reduces the cost, not some special exemption.
क्या मैं egress कम करने के लिए Vercel के सामने एक custom CDN use कर सकता हूँ?
तुम Cloudflare का proxy अपनी Vercel deployment के सामने रख सकते हो। Cloudflare अपने edge पर responses को cache करता है, जिसका मतलब वह requests जो Cloudflare के cache में hit होती हैं वह Vercel तक पहुँचती ही नहीं। यह egress और function invocations दोनों को significantly कम कर सकता है। Preview deployments और header handling के साथ कुछ caveats हैं, लेकिन production के लिए यह एक common और legitimate approach है। Cloudflare की proxying के बारे की documentation में setup है।Cloudflare's documentation on proxying covers the setup.
Vercel के बिलों में अचानक बढ़ोतरी का सबसे बड़ा एकल कारण क्या है?
मेरे अनुभव में: इमेज हैंडलिंग। या तो पूरी रेजोल्यूशन की इमेजें बिना ऑप्टिमाइजेशन के सर्व की जा रही हैं, या फिर इमेज ऑप्टिमाइजेशन रूट्स हर रिक्वेस्ट पर बिना सही कैशिंग के कॉल हो रहे हैं। पहले अपनी इमेज पाइपलाइन को ठीक करो, बाकी सब कुछ दूसरे नंबर पर।
क्या Vercel आपको अपने आप नोटिफाई करता है अगर उपयोग में स्पाइक आए?
डिफ़ॉल्ट रूप से नहीं। आपको इसे कॉन्फ़िगर करना होगा। कोई बिल्ट-इन अलर्ट नहीं है जो कहे "आपने 80% बैंडविड्थ का उपयोग कर लिया है।" यही खामी है। अपनी प्रोडक्शन डिप्लॉयमेंट सेट अप करने के उसी दिन अपनी स्पेंड मैनेजमेंट थ्रेशोल्ड सेट करो। बाद में नहीं।
---
Vercel एक शानदार प्लेटफॉर्म है। मैं इसे इस्तेमाल करता हूँ, Seahawk भी इसे इस्तेमाल करता है, और सही प्रोजेक्ट्स के लिए मैं इसकी सिफारिश करते रहूँगा। लेकिन यह एक मीटर्ड सर्विस है जो असली इंफ्रास्ट्रक्चर पर चल रही है, और कीमत उसी के अनुसार है। जो डेवलपर्स अचानक बिलों से परेशान होते हैं वे लगभग हमेशा वही होते हैं जिन्होंने इसे एक फ्री CDN की तरह ट्रीट किया और कभी बिलिंग सेटिंग्स पर नजर नहीं डाली। डिप्लॉय करते समय पाँच मिनट की कॉन्फ़िगरेशन आपको एक बहुत ही अनचाहे सोमवार की सुबह की फोन कॉल से बचा लेगी।