यूज़र अपलोड के लिए ऑब्जेक्ट स्टोरेज: अपने सर्वर की डिस्क भरना बंद करें

लोकल डिस्क आपको धोखा क्यों देती है

अपलोड से भरा फोल्डर तब तक ठीक चलता है जब तक अचानक सब रुक न जाए। डिस्क चुपचाप पीछे-पीछे भरती रहती है, और पहला लक्षण अक्सर यह होता है कि आपका डेटाबेस या आपके लॉग फेल हो जाते हैं, क्योंकि अपलोड फोल्डर ने आखिरी गीगाबाइट भी खा लिया। और भी बुरा: कई डिप्लॉय सेटअप पूरी रिलीज़ डायरेक्टरी बदल देते हैं — एक डिप्लॉय, और यूज़र्स ने जो भी फ़ाइलें आप पर भरोसा करके दी थीं, सब गायब।

फिर आती है स्केलिंग। जैसे ही आप लोड बैलेंसर के पीछे दूसरा सर्वर जोड़ते हैं, आधी रिक्वेस्ट ऐसी मशीन पर पहुँचती हैं जिसके पास वह फ़ाइल है ही नहीं। स्टिकी सेशन और rsync के जुगाड़ समस्या को बस टालते हैं। जो फ़ाइलें एक मशीन की डिस्क पर रहती हैं, वे परिभाषा से ही सिंगल पॉइंट ऑफ़ फेल्योर हैं।

अपलोड का वह फ्लो जो सच में काम करता है

पैटर्न सीधा है: क्लाइंट फ़ाइल आपके API को भेजता है (या presigned URL से सीधे बकेट में), आपका API उसे Nest Storage बकेट में डालता है, और बकेट बदले में एक ऑब्जेक्ट की (key) लौटाता है। डेटाबेस में आप वही की स्टोर करते हैं — फ़ाइल नहीं।

आपका डेटाबेस छोटा और तेज़ रहता है, आपके सर्वर स्टेटलेस रहते हैं, और फ़ाइल खुद ऐसी जगह रहती है जो टिकाऊपन के लिए ही बनी है। पूरा फ्लो बस दो लाइनों में:

const { key } = await nest.upload("avatars", file);
await db.user.update({ id, avatarKey: key });

प्राइवेट बनाम पब्लिक बकेट

हर फ़ाइल के साथ एक जैसा व्यवहार ठीक नहीं। लोगो, प्रोडक्ट इमेज और साइट के दूसरे एसेट पब्लिक बकेट में रह सकते हैं और सीधे सर्व हो सकते हैं — बेहतर हो तो कस्टम डोमेन वाले CDN के ज़रिए। उन्हें कोई भी पढ़ सकता है, और यही तो मकसद है।

यूज़र के दस्तावेज़ अलग बात हैं। इनवॉइस, कॉन्ट्रैक्ट और पहचान से जुड़े अपलोड प्राइवेट बकेट में रहने चाहिए, और आपका API कुछ मिनटों में एक्सपायर होने वाले साइन्ड URL बनाकर एक्सेस देता है। फ़ाइल कभी सार्वजनिक रूप से उपलब्ध नहीं होती; सिर्फ वह लिंक होता है जो आपने अभी-अभी बनाया।

• इमेज और स्टैटिक एसेट के लिए पब्लिक बकेट
• दस्तावेज़ों के लिए प्राइवेट बकेट और एक्सपायर होने वाले साइन्ड URL
• हर एनवायरनमेंट के लिए अलग बकेट, ताकि स्टेजिंग कभी प्रोडक्शन की फ़ाइलों को छू न सके

नेमिंग, वर्ज़निंग और सफाई

ऑब्जेक्ट की (key) ही आपका फाइलिंग सिस्टम हैं, इसलिए प्रीफ़िक्स सोच-समझकर चुनें: avatars/{userId}/… या invoices/2026/04/… जैसे प्रीफ़िक्स से फ़ाइलों को यूज़र या तारीख के हिसाब से लिस्ट करना, माइग्रेट करना और डिलीट करना आसान हो जाता है। साफ-सुथरी की-संरचना वाला nest:// URI खुद अपनी कहानी कहता है।

जिन बकेट में गलती से हुआ ओवरराइट नुकसान पहुँचा सकता है, वहाँ वर्ज़निंग चालू करें — पुराना वर्ज़न हमेशा के लिए खोने की बजाय बस एक API कॉल की दूरी पर रहता है। और अनाथ फ़ाइलों की सफाई के लिए लाइफसाइकिल नियम जोड़ें: जिन अपलोड की डेटाबेस पंक्ति डिलीट हो चुकी है, या हफ्ते भर से पुरानी टेम्प फ़ाइलें — ये अपने आप साफ हो जाती हैं, हमेशा के लिए पैसे खर्च कराने की बजाय।

खर्च कितना आता है

Nest Storage में आप सिर्फ दो चीज़ों के पैसे देते हैं: जितना स्टोरेज आप वाकई इस्तेमाल करते हैं और जितनी बैंडविड्थ आप वाकई सर्व करते हैं। न हर रिक्वेस्ट पर चिल्लर वसूली, न बिल में कोई चौंकाने वाली लाइन — कीमतें ₹ में हैं, अनुमान लगाने लायक और पहले से समझने लायक।

एक फ्री टियर है जो साइड प्रोजेक्ट के लिए काफी उदार है, इसलिए इस वीकेंड आप जो अवतार अपलोड फीचर बनाएँगे, उसका खर्च तब तक शून्य है जब तक असली यूज़र नहीं आते। और जब वे आते हैं, तो वही बकेट, वही API और वही की काम करती रहती हैं — बस कोटा बड़ा हो जाता है।