एक क्लाइंट ने मुझे जनवरी की शुरुआत में कॉल किया, बिल्कुल उत्साहित। "गौतम, मैंने अभी पढ़ा कि Vercel अब Docker करता है। हम अपनी DigitalOcean droplets को बंद कर सकते हैं, हाँ?" वह तीन droplets चला रहा था, दो $24/month की, एक $48 की। उसके पास एक स्प्रेडशीट तैयार थी। वह पैसे बचाना चाहता था और वह इसे तुरंत बचाना चाहता था।
मैंने उसे दो हफ्ते रुकने के लिए कहा जबकि मैं इसे actually test करता। सौभाग्य से उसने सुना।
बात यह है: Vercel का container support genuinely impressive है। और एक VPS अभी भी मरा हुआ नहीं है। ये दोनों बातें एक ही समय में सच हैं, और इन दोनों के बीच का nuance समझने लायक है इससे पहले कि आप सब कुछ Vercel के infrastructure पर docker push करने लगें और सोचने लगें कि आपके WebSocket connections क्यों keep dropping हो रहे हैं।
Vercel ने Actually क्या Announce किया
Vercel का Docker support, जो उनके Build Output API के जरिये roll out किया गया और बाद में general use के लिए formalize किया गया, आपको एक Dockerfile ship करने देता है और Vercel container runtime को handle करता है। अब Next.js conventions या serverless function file structures तक सीमित नहीं। आप अपना Dockerfile लिखते हो, Vercel उसे build करता है, चलाता है।
यह एक असली बदलाव है। इससे पहले, अगर आपके पास FastAPI बैकएंड या कोई कस्टम Node सर्वर था जो कुछ असामान्य काम कर रहा था, तो आप दोनों में से एक कर रहे थे: या तो इसे serverless function के आकार में तोड़-मरोड़ रहे थे या अपने Vercel फ्रंटएंड के साथ एक VPS चलाते रहते थे। हमने ज्यादातर दूसरा किया। यह झंझट था लेकिन काम करता था।
Runtime असल में कैसा दिखता है
Vercel का container runtime bare-metal Docker नहीं है। यह managed container service पर जो मिलता है उसके करीब है। आपका container एक रिक्वेस्ट पाता है, Vercel इसे रूट करता है, container इसे हैंडल करता है। Persistent processes काम करती हैं। आप Python WSGI सर्वर या Go HTTP binary जैसा कुछ चला सकते हैं। एक single request lifecycle में long-running tasks ठीक हैं।
लेकिन constraints मायने रखती हैं। Containers zero तक scale हो सकते हैं। Cold starts exist करती हैं। और महत्वपूर्ण बात: आपको persistent disk storage नहीं मिलता। अगर आपका app local filesystem में write करता है और अगली रिक्वेस्ट पर उन फाइलों के वहां होने की उम्मीद करता है, तो आपके लिए मुश्किल होने वाली है।
Vercel Containers असल में कहां शानदार हैं
मैं मार्च से Vercel containers पर एक Django REST API चला रहा हूं। यह एक media client के लिए एक relatively simple read-heavy service है, ज्यादातर GET requests, Neon Postgres database को hit कर रहा है। कोई file writes नहीं। कोई background jobs नहीं। कोई WebSockets नहीं।
यह शानदार रहा है। Deploy previews काम करते हैं। GitHub integration का मतलब है कि हर PR को अपना environment मिलता है। इस particular container पर cold start latency idle के बाद पहली hit पर करीब 800ms से 1.2 सेकंड है, जो bad लगता है लेकिन तब acceptable है जब क्लाइंट का traffic bursty और predictable हो।
उस service की cost? Vercel की Pro plan के साथ करीब $20/महीना। DigitalOcean App Platform पर equivalent similar होगा। एक raw droplet सस्ता होगा, लेकिन हम इसे खुद manage कर रहे होते।
यह वह scenario है जहां यह एक clear win है
typical agency project के बारे में सोचें। एक headless CMS के साथ marketing site, एक contact form या कुछ custom logic के लिए एक lightweight API, और fast deploys की जरूरत। पहले आपके पास फ्रंटएंड के लिए Vercel और little API के लिए एक $6 droplet होता। अब आप सब कुछ Vercel पर डाल सकते हैं, एक dashboard use कर सकते हैं, API के लिए भी deploy previews रख सकते हैं। कम चीजें maintain करनी हैं। कम चीजें भूलने के लिए हैं।
पाँच से पन्द्रह क्लाइंट साइटों को संभालने वाले फ्रीलांसरों के लिए, वह ऑपरेशनल सरलता वास्तविक पैसा बचाती है, भले ही कंप्यूट लागत थोड़ी अधिक हो।
जहाँ VPS अभी भी जीतता है। स्पष्ट रूप से।
ठीक है। यहाँ मुझे सीधा होने की जरूरत है, क्योंकि Vercel कंटेनरों के आसपास की उत्साही सोच ने कुछ डेवलपर्स को महँगी गलतियाँ करने के लिए प्रेरित किया है।
persistent फाइलसिस्टम ऑपरेशन्स। अगर आपका ऐप PDFs जेनरेट करता है और उन्हें S3 में भेजने से पहले स्थानीय रूप से स्टोर करता है, ठीक है, वह विशिष्ट ऑपरेशन काम करता है। लेकिन अगर आप एक self-hosted Meilisearch इंस्टेंस चला रहे हैं जो अपना इंडेक्स डिस्क पर लिखता है, तो आपको persistent storage की जरूरत है। Vercel आपको एक mounted वॉल्यूम नहीं देता। आपको एक managed Meilisearch सेवा जोड़नी होगी या इसे VPS पर चलाना होगा। बस।
WebSockets और long-lived कनेक्शन्स। Vercel के serverless और कंटेनर environments में request timeouts हैं। मुझे यह एक Seahawk प्रोजेक्ट के साथ 2024 के अंत में मिला, Docker सपोर्ट लैंड करने से पहले भी। हम एक छोटे SaaS क्लाइंट के लिए real-time सहयोगी टूल बना रहे थे। serverless infrastructure पर इसे काम कराने के लिए सब कुछ आजमाया। आखिरकार WebSocket सर्वर को $12/माह वाले Hetzner VPS में स्थानांतरित किया। समस्या चली गई। VPS तब से बिना रुके चल रहा है।
background workers और scale पर cron। हाँ, Vercel के पास cron jobs हैं। वे सरल scheduled tasks के लिए ठीक हैं। लेकिन अगर आप Celery workers जैसा कुछ चला रहे हैं जो लगातार कामों की एक queue को प्रोसेस करता है, तो आप एक ऐसी प्रक्रिया चाहते हैं जो बस... चले। VPS यह तुच्छ रूप से करता है। Vercel कंटेनर्स पर, आप अनाज के विरुद्ध काम कर रहे हैं।
volume पर लागत। यह वह है जो लोगों को हैरान करता है। कम से मध्यम ट्रैफ़िक पर, Vercel कंटेनर्स प्रतिस्पर्धी हैं। लेकिन genuinely उच्च request volumes पर, per-request pricing जुड़ने लगती है। एक $48/माह Hetzner dedicated सर्वर उतना ट्रैफ़िक संभालता है जो Vercel पर peak पर कई सौ डॉलर खर्च करेगा। मेरा क्लाइंट जो अपने droplets बंद करना चाहता था? उनमें से एक high-traffic आंतरिक dashboard चला रहा था। मैंने नंबर निकाले। droplet को रखना occasional रखरखाव के समय को account करने के बाद भी £18/माह सस्ता था।
विशिष्ट Workloads जिन्हें मैं कभी भी Vercel में स्थानांतरित नहीं करूँगा
मुझे concrete होने दीजिए। ये वह चीजें हैं जिन्हें मैं सक्रिय रूप से एक VPS को रूट करता हूँ, भले ही Vercel कुछ भी रिलीज़ करे:
- Self-hosted databases। यहाँ तक कि read performance के लिए एक छोटी Postgres प्रतिकृति। Vercel एक database होस्ट नहीं है। इसे Neon, Supabase, या PlanetScale के साथ use करें, लेकिन Postgres को स्वयं वहाँ चलाने की कोशिश न करें।
- मीडिया प्रोसेसिंग। FFmpeg जॉब्स, इमेज रिसाइजिंग कतारें, कोई भी CPU-गहन काम जिसके रनटाइम अप्रत्याशित हों। एक $20 Hetzner VPS 2 vCPU के साथ इसे बेहतर और सस्ते में संभालता है।
- इंटरनल टूलिंग जो 24/7 चलती रहे। मॉनिटरिंग एजेंट्स, लॉग एग्रीगेटर्स, कस्टम प्रॉक्सी सर्वर्स। ये बस चलते रहने चाहिए। हमेशा। जीरो तक स्केल करना यहाँ दुश्मन है।
- कोई भी चीज जो GPU को छुए। स्पष्ट है, लेकिन कहने लायक है।
और इसके विपरीत, यहाँ वो कुछ है जो मैं आज आत्मविश्वास से Vercel कंटेनर्स पर डालूँ:
- हल्के-फुल्के REST API (FastAPI, Express, Gin) बिना किसी स्थायी स्टेट के
- कंटेनराइज्ड Next.js या Remix ऐप्स कस्टम सर्वर कॉन्फ़िगरेशन के साथ
- इंटरनल API जिन्हें सिर्फ काम के घंटों में हिट किया जाता है (स्केल-टू-जीरो यहाँ वाकई शानदार है)
- कोई भी सेवा जहाँ आप सचमुच per-PR डिप्लॉय प्रीव्यूज चाहते हैं
छिपी हुई लागत जिसके बारे में कोई बात नहीं करता: ऑपरेशनल कॉम्प्लेक्सिटी
मैंने Seahawk में सालों के दौरान 12,000 से ज्यादा साइट्स बनाई हैं। एजेंसीज और फ्रीलांसर्स को सबसे ज्यादा नुकसान कंप्यूट लागत नहीं, बल्कि ऑप्स ओवरहेड से होता है।
एक VPS $6/माह पर सस्ता लगता है। और है सस्ता। लेकिन फिर आप इसे पैच कर रहे हैं, इसकी निगरानी कर रहे हैं, Nginx कॉन्फ़िगर कर रहे हैं, fail2ban सेट अप कर रहे हैं, कभी-कभी रात 11 बजे SSH से लॉग इन कर रहे हैं क्योंकि कुछ अजीब तरीके से काम कर रहा है। वह फ्री नहीं है। वह समय है, और समय महंगा है।
Vercel यह सब हटा देता है। Railway, Render और Fly.io भी करते हैं। यहाँ असली प्रतिस्पर्धा "Vercel बनाम एक VPS वैक्यूम में" नहीं है। यह "मैनेज्ड प्लेटफॉर्म टैक्स बनाम ops समय टैक्स" है। एकल ऑपरेटरों और छोटी एजेंसियों के लिए, मैनेज्ड प्लेटफॉर्म टैक्स आमतौर पर बेहतर डील है।
2019 में एक क्लाइंट ने मुझे एक ब्रीफ दी जिसमें उनके Ubuntu सर्वर का प्रबंधन शामिल था। मैंने तदनुसार कोट दिया। छह महीने बाद मैं अभी भी एक सर्वर पर डिस्क स्पेस अलर्ट के लिए पेज जा रहा था जिसे मैंने तकनीकी रूप से "प्रबंधित" किया था लेकिन पूरी तरह से प्राथमिकता हटा दी थी। तब से मैं इस बारे में बहुत अधिक सचेत रहा हूँ कि मैं किस बुनियादी ढाँचे का स्वामित्व लेता हूँ बनाम किस चीज़ के लिए मैं एक प्लेटफॉर्म को स्वामित्व देता हूँ।
फ्रेमवर्क जिसका मैं वास्तव में उपयोग करता हूँ फैसला लेने के लिए
जादुई फ्लोचार्ट नहीं। बस सवालों का एक सेट जो मैं हर नई परियोजना पर पूछता हूँ:
- क्या यह सेवा डिस्क में लिखती है और उन लेखन को बने रहने की उम्मीद करती है? अगर हाँ, तो इसे एक VPS या मैनेज्ड स्टोरेज की जरूरत है।
- क्या यह सेवा लंबे समय तक चलने वाले कनेक्शन रखती है (WebSockets, SSE, gRPC स्ट्रीम)? अगर हाँ, तो VPS या Fly.io जैसा एक प्लेटफॉर्म जो इसे स्पष्ट रूप से समर्थन करता है।
- क्या यह सेवा विस्तारित अवधि के लिए CPU-बाध्य है? Vercel कंटेनर के पास CPU सीमा है। VPS जीतता है।
- क्या टीम को बिना सोचे deploy previews और GitOps की जरूरत है? Vercel जीतता है।
- क्या ट्रैफिक सुसंगत और उच्च-वॉल्यूम होगा? नंबर चलाएँ। एक निश्चित सीमा के ऊपर VPS आमतौर पर सस्ता होता है।
- क्या यह एक व्यक्ति का काम है या कोई छोटी एजेंसी जो सर्वर के बारे में सोचना नहीं चाहती? Vercel प्रीमियम के लायक है।
अगर सवाल 1, 2, या 3 हाँ हैं, तो मैं Hetzner या DigitalOcean की ओर जा रहा हूँ। बाकी सब कुछ बातचीत है।
2026 में इंफ्रास्ट्रक्चर वास्तव में कैसा दिखेगा
प्लेटफॉर्म परसिस्टेंट स्टोरेज में बेहतर हो रहे हैं। Fly.io के पास Fly Volumes हैं। Render के पास परसिस्टेंट डिस्क हैं। Vercel संभवतः कुछ समान जोड़ेगा, यह देखते हुए कि यह कितनी बार मांगा जाता है। "मैनेज्ड प्लेटफॉर्म" और "पूर्ण नियंत्रण वाली VPS" के बीच का अंतर सीमित हो रहा है।
लेकिन सीमित होना बंद होने जैसा नहीं है। और रॉ कंप्यूट की अर्थशास्त्र मौलिक रूप से नहीं बदली है। €3.79/माह पर एक Hetzner CAX11 ARM इंस्टेंस सही वर्कलोड के लिए अभी भी बेहद अच्छा मूल्य है। कोई भी इसे समतुल्य कंप्यूट के लिए किसी मैनेज्ड प्लेटफॉर्म पर नहीं हरा रहा है।
2026 की ईमानदार स्थिति यह है: VPS मर नहीं गया है। VPS तेजी से वैकल्पिक हो रहा है। ये अलग चीजें हैं।
अधिकांश नई प्रोजेक्ट जो मैं अब Seahawk पर शुरू करता हूँ, Vercel या Railway को डिफॉल्ट करते हैं जब तक कि ऊपर दी गई प्रश्न सूची में कुछ अलग उत्तर ट्रिगर न करे। हमने संभवतः पिछले अठारह महीनों में सक्रिय VPS इंस्टेंस की संख्या को लगभग 40% कम कर दिया है। लेकिन जो बचे हैं वे अच्छे कारणों से हैं, और वे कहीं नहीं जा रहे हैं।
FAQ
क्या Vercel कंटेनर्स लोकल-टू-प्रोडक्शन पैरिटी के लिए Docker Compose की जगह ले सकते हैं?
कुछ हद तक, लेकिन वास्तव में नहीं। Docker Compose कई सेवाओं को स्थानीय रूप से एक साथ ऑर्केस्ट्रेट करने के बारे में है। Vercel प्रति डिप्लॉयमेंट एक ही कंटेनर चलाता है। अगर आपके स्टैक में वेब सर्वर, वर्कर और Redis सभी Compose फ़ाइल में परिभाषित हैं, तो Vercel वेब सर्वर भाग को संभाल सकता है। आपको अभी भी मैनेज्ड Redis (Upstash सामान्य विकल्प है) की ओर इशारा करना होगा और वर्कर को अलग से संभालना होगा। लोकल पैरिटी पहले से बेहतर है, लेकिन Compose-से-Vercel सीधा अनुवाद नहीं है।
जब Vercel कंटेनर स्केल करके शून्य पर जाते हैं तो क्या होता है?
कंटेनर प्रोसेस बंद हो जाती है। जब नया रिक्वेस्ट आता है, Vercel इसे फिर से शुरू करता है। वह बूट टाइम आपकी cold start latency है। compiled binaries (Go, Rust) के लिए यह अक्सर 500ms से कम होता है। बड़े रuntimes जैसे JVM-आधारित ऐप्स के लिए, यह 2 से 4 सेकंड हो सकता है। staging में इसे परीक्षण करना काबिले-गौर है क्योंकि कुछ क्लाइंट्स बिल्कुल 3-सेकंड के पहले लोड को नोटिस करेंगे।
क्या Vercel की container support free Hobby plan पर उपलब्ध है?
शुरुआती 2026 तक, नहीं। Container deployments के लिए कम से कम Pro plan की जरूरत है। Hobby tier अभी भी serverless functions और static sites को support करता है। Vercel के pricing page को सीधे चेक करना लायक है क्योंकि यह पहले बदल चुका है और फिर से बदलने की संभावना है।
मुझे कब Fly.io का इस्तेमाल करना चाहिए Vercel या raw VPS की जगह?
Fly मेरा पहली पसंद है जब मुझे persistent processes की जरूरत हो, global distribution users के करीब चाहिए, और server configuration को manage नहीं करना चाहता। यह एक दिलचस्प बीच की जगह बैठता है। आप containers deploy करते हो, लेकिन आपको regions, machine sizes, और persistent volumes पर ज्यादा control मिलता है जो Vercel offer करता है। मैं इसे long-running APIs के लिए और किसी भी चीज़ के साथ use करता हूँ जिसमें WebSocket requirements हों और जिसे multiple regions में होना पड़े। trade-off यह है कि DX Vercel के GitHub integration की तुलना में थोड़ा ज्यादा involved है।
---
VPS कोई ऐसी चीज़ नहीं है जिसे आप आदत से default करें। लेकिन यह कोई ऐसी चीज़ भी नहीं है जिसे आप उत्साह से त्याग दें। अपने workload को जानो। नंबर्स चलाओ। और शायद कुछ भी बंद करने से पहले दो हफ्ते इंतज़ार करो।
संबंधित पढ़ना: 2026 में AI सर्च कीवर्ड रिसर्च: यह क्या है, पारंपरिक क्यों, तकनीकी SEO, और AI सर्च।