10 अक्टूबर 2026 को सत्यापित: उस कोड पर जिसे VULK आज चलाता है, और लाइव एंडपॉइंट्स पर।
जब आप VULK से ऐसा ऐप माँगते हैं जिसे चीज़ें याद रखनी हों, जैसे कोई स्टोर, बुकिंग टूल या CRM, तो VULK स्क्रीनों पर नहीं रुकता। उनके पीछे वह तीन चीज़ें बनाता है: प्रोजेक्ट का अपना डेटाबेस, ऐप इस्तेमाल करने वाले लोगों के लिए साइन-इन सिस्टम, और एक REST API जिससे स्क्रीनें बात करती हैं। तीनों api-backend.vulk.dev पर VULK के मैनेज्ड बैकएंड पर चलते हैं, और आपको न कोई सर्वर सेट करना पड़ता है, न डेटाबेस, न auth प्रोवाइडर।
यह लेख हर हिस्से को वैसे ही दिखाता है जैसे वह असल में काम करता है। नीचे का हर आँकड़ा तीन में से किसी एक जगह से आता है: वह कोड जो इन ऐप्स को जेनरेट और सर्व करता है (10 अक्टूबर 2026 को पढ़ा गया), बैकएंड का सार्वजनिक health एंडपॉइंट, और एक ऐसे स्टोर पर भेजी गई लाइव रिक्वेस्ट जो VULK शोकेस में सार्वजनिक है। यहाँ कुछ भी ऐसा बेंचमार्क नहीं है जो हमने किसी और के प्रोडक्ट पर चलाया हो।
VULK जो फ़्रंटएंड लिखता है
वेब ऐप एक React प्रोजेक्ट के रूप में निकलता है, जो Vite से बनता है। वर्शन जेनरेटर में पिन किए गए हैं, उन्हें बदलने के लिए खुला नहीं छोड़ा जाता, इसलिए जिस प्रोजेक्ट का आप प्रीव्यू देखते हैं, वही प्रोजेक्ट आप एक्सपोर्ट करते हैं:
| पैकेज | हर जेनरेट हुए ऐप में वर्शन |
|---|---|
| react / react-dom | 19.2.0 |
| vite | 6.0.7 |
| @vitejs/plugin-react | 4.3.4 |
| typescript | 5.7.3 |
| tailwindcss | 4.3.3 |
| gsap | 3.13.0 |
जब किसी ऐप को डेटा चाहिए होता है, तो VULK प्रोजेक्ट में एक typed क्लाइंट फ़ाइल जोड़ता है। स्क्रीनें कभी हाथ से URL या टोकन नहीं बनातीं; वे उस क्लाइंट को कॉल करती हैं, और क्लाइंट बैकएंड को।
हर प्रोजेक्ट का अपना डेटाबेस
बैकएंड हर प्रोजेक्ट को उसका अपना PostgreSQL डेटाबेस देता है, जिसकी पहचान एक छोटी id से होती है: proj_ और उसके बाद उस बातचीत के पहले आठ हेक्साडेसिमल अक्षर जिसने ऐप बनाया। यह id हर एडिट में वही रहती है, इसलिए जब आप कोई बदलाव माँगते हैं तो आपके ऐप का डेटा बना रहता है।
बैकएंड एक health एंडपॉइंट प्रकाशित करता है जिसे कोई भी पढ़ सकता है। 10 अक्टूबर 2026 को 22:34 UTC पर उसका जवाब यह था:
{
"status": "ok",
"service": "vulk-api-engine",
"database": "connected",
"projects": 1440
}
यानी उस पल इंजन पर 1,440 प्रोविज़न किए गए प्रोजेक्ट डेटाबेस थे।
जेनरेट हुई टेबल कैसी दिखती है
VULK आपके ऐप की ज़रूरतों (प्रोडक्ट, ऑर्डर, अपॉइंटमेंट) से टेबलें तय करता है और अपनी ओर से तीन कॉलम जोड़ता है:
id, एक टेक्स्ट प्राइमरी कीcreated_at, एक टाइमस्टैम्प जिसे डेटाबेस ख़ुद भरता हैuser_id, उन टेबलों पर जहाँ हर पंक्ति किसी एक साइन-इन किए हुए व्यक्ति की होती है
बाक़ी हर कॉलम पाँच में से एक टाइप लेता है: text, number, integer, boolean या datetime। टेबल और कॉलम के नामों में छोटे अक्षर (lowercase), अंक और अंडरस्कोर होते हैं, वे किसी अक्षर से शुरू होते हैं और 48 अक्षरों पर रुक जाते हैं। API camelCase में जवाब देता है, इसलिए created_at आपकी स्क्रीनों तक createdAt बनकर पहुँचता है।
स्कीमा में बदलाव हमेशा सिर्फ़ जोड़ते हैं। जब किसी एडिट को नई टेबल या कॉलम चाहिए, तो बैकएंड उसे जोड़ देता है। कॉलम हटाना या उसका टाइप बदलना कभी अपने आप नहीं होता, क्योंकि यही वह बदलाव है जो डेटा मिटा देता है।
REST API, रूट-दर-रूट
हर टेबल को प्रोजेक्ट के पते के नीचे रूटों का एक ही सेट मिलता है:
| मेथड | रूट | क्या करता है |
|---|---|---|
| GET | /api/<project>/<table> |
पंक्तियों की सूची, पेजों में |
| GET | /api/<project>/<table>/<id> |
एक पंक्ति पढ़ता है |
| POST | /api/<project>/<table> |
एक पंक्ति बनाता है |
| PUT / PATCH | /api/<project>/<table>/<id> |
एक पंक्ति अपडेट करता है |
| DELETE | /api/<project>/<table>/<id> |
एक पंक्ति हटाता है |
| POST | /api/<project>/<table>/bulk |
एक साथ कई पंक्तियाँ बनाता है |
सूचियाँ एक ही envelope में लौटती हैं, { data, meta: { total, page, perPage, totalPages } }। जेनरेट हुआ क्लाइंट हर पेज पर 100 पंक्तियाँ पढ़ता है और 1,000 पर रुक जाता है, और bulk इंसर्ट 1,000 पंक्तियों के हिस्सों में भेजता है। हर प्रोजेक्ट हर क्लाइंट पते से प्रति मिनट 100 रिक्वेस्ट स्वीकार करता है, और बैकएंड हर जवाब में X-RateLimit-Limit: 100 हेडर के ज़रिए यह बताता भी है।
कौन क्या पढ़ और लिख सकता है
यही वह हिस्सा है जिसे जेनरेट हुए बैकएंड सबसे ज़्यादा ग़लत करते हैं, इसलिए यहाँ सटीक होना ज़रूरी है। जिस टेबल की कोई घोषित access policy नहीं है, वह बंद रहती है। VULK पहले पूरे ऐप को चार में से एक ढाँचा देता है:
- निजी अकाउंट: हर व्यक्ति साइन इन करता है और सिर्फ़ अपनी पंक्तियाँ देखता है।
- टीम अकाउंट: एक टीम एक ही पंक्तियों पर काम करती है, और लोग इनवाइट से जुड़ते हैं।
- सार्वजनिक: कोई अकाउंट नहीं।
- मालिक का पैनल: विज़िटर, और साथ में एक हिस्सा जिसे सिर्फ़ मालिक खोल सकता है।
फिर वह हर टेबल को अलग से सेट करता है। कोई टेबल सार्वजनिक रूप से पढ़ी जा सकती है, प्रोजेक्ट की API key से, किसी साइन-इन किए हुए यूज़र द्वारा, या सिर्फ़ मालिक द्वारा। लिखने के लिए भी यही विकल्प हैं, और साथ में "कोई भी", जो संपर्क फ़ॉर्म जैसी चीज़ों के काम आता है। बिना पहचान वाले (anonymous) राइट हर पते से प्रति मिनट 20 तक सीमित हैं। फ़ील्ड निजी रहते हैं, जब तक ऐप का प्लान कुछ और न कहे।
एक लाइव ऐप पर यह policy ऐसी दिखती है। LUMA शोकेस का एक फ़ैशन स्टोर है जो इसी बैकएंड पर proj_266b7c3c के रूप में चलता है। हमने 10 अक्टूबर 2026 को, बिना साइन इन किए, ये रिक्वेस्ट भेजीं:
| रिक्वेस्ट | जवाब |
|---|---|
GET /products |
200, 12 प्रोडक्ट |
GET /categories |
200, 4 कैटेगरी |
GET /reviews |
200, 4 रिव्यू |
GET /orders |
401, JWT_REQUIRED |
बिना टोकन के POST /orders |
401 |
GET /users |
404, Access to this table is not allowed |
कैटलॉग सार्वजनिक है, क्योंकि दुकान को अपने प्रोडक्ट दिखाने ही पड़ते हैं। ऑर्डर के लिए साइन-इन किया हुआ ग्राहक चाहिए। अकाउंट वाली टेबल तो टेबल के रूप में खुली ही नहीं है।
आपके ऐप के यूज़र्स के लिए साइन-इन
हर फ़ुल-स्टैक ऐप को अपने यूज़र अकाउंट मिलते हैं, जो आपके VULK अकाउंट से अलग होते हैं। जेनरेट हुआ क्लाइंट रजिस्ट्रेशन, साइन इन, "मैं कौन हूँ" और पासवर्ड रीसेट संभालता है। बैकएंड में refresh, साइन आउट और पासवर्ड बदलने के रूट भी हैं:
- पासवर्ड PBKDF2-SHA256 से हैश होते हैं, 100,000 iterations और 16-byte रैंडम salt के साथ।
- सेशन ब्राउज़र में रहता है और bearer टोकन के रूप में भेजा जाता है। कोई भी 401 उसे साफ़ कर देता है, ताकि ऐप कभी ऐसा सेशन न रखे जिसे सर्वर पहले ही ठुकरा चुका हो।
- जिस व्यक्ति का प्रोजेक्ट है, वह admin है; रजिस्टर करने वाला हर व्यक्ति सामान्य यूज़र है।
- रजिस्ट्रेशन खुला रखा जा सकता है, या सिर्फ़ इनवाइट से, ऐसे कोड के साथ जो एक ही बार चलते हैं और सात दिन बाद एक्सपायर हो जाते हैं।
स्टूडियो में हर प्रोजेक्ट के डैशबोर्ड में एक Backend टैब है, जिसमें ओवरव्यू, डेटाबेस, ऐप के यूज़र्स, API और उसके secrets होते हैं।
Keys और secrets
हर प्रोजेक्ट को एक API key मिलती है जो vk_ से शुरू होती है और उसके बाद 64 हेक्साडेसिमल अक्षर होते हैं; यह AES-256-GCM से एन्क्रिप्ट करके स्टोर की जाती है। पब्लिश किए गए बंडल में कोई key नहीं होती: बैकएंड का पता पेज लोड होते समय पेज में डाला जाता है, और ऐसी कोई भी चीज़ ब्राउज़र तक नहीं भेजी जाती जिससे कोई विज़िटर मालिक बनकर काम कर सके। आपके ऐप को जिन secrets की ज़रूरत होती है, जैसे किसी third-party API का टोकन, वे write-only हैं। आप उन्हें सेट कर सकते हैं या बदल सकते हैं, पर कोई उन्हें वापस पढ़ नहीं सकता, और हर secret 8 KB तक सीमित है।
पब्लिश करना और कोड अपने साथ ले जाना
पब्लिश करना एक क्लिक का काम है। VULK प्रोडक्शन वर्शन उसी अलग-थलग (isolated) मशीन के अंदर बनाता है जिसने आपका प्रीव्यू चलाया था, फिर उसे HTTPS पर <name>.vulk.space पर सर्व करता है। आपका चुना हुआ नाम आपका ही रहता है। अगर आप अनपब्लिश करते हैं, तो साइट ऑफ़लाइन हो जाती है और पता उसी प्रोजेक्ट के लिए सुरक्षित रहता है। बैकएंड का पता प्रीव्यू और पब्लिश किए गए बिल्ड, दोनों में जुड़ा होता है, इसलिए पब्लिश किया गया ऐप उसी डेटाबेस से बात करता है जिसे आपने टेस्ट किया था।
कोड भी आपका है। हर सशुल्क प्लान पर आप पूरा प्रोजेक्ट ZIP के रूप में डाउनलोड कर सकते हैं या उसे एक नई GitHub रिपॉज़िटरी में push कर सकते हैं, निजी या सार्वजनिक। GitHub एक्सपोर्ट कभी force-push नहीं करता, और हर push में 1,000 फ़ाइलें और 8 MB तक लेता है।
अक्सर पूछे जाने वाले प्रश्न
क्या डेटाबेस असली PostgreSQL है?
हाँ। हर प्रोजेक्ट को अपना PostgreSQL डेटाबेस मिलता है, जिसकी पहचान प्रोजेक्ट की छोटी id से होती है। यह कोई साझा स्प्रेडशीट या ब्राउज़र के अंदर का स्टोर नहीं है।
किन प्लानों में बैकएंड शामिल है?
सभी में। Builder $19.99 प्रति माह है, Pro $39.99 और Max $199 (कीमतें vulk.dev/pricing पर 10 अक्टूबर 2026 को पढ़ी गईं)। मैनेज्ड बैकएंड, पब्लिशिंग और सोर्स एक्सपोर्ट हर प्लान में शामिल हैं।
ऐप एडिट करने पर मेरे डेटा का क्या होता है?
एडिट के बीच प्रोजेक्ट id नहीं बदलती, इसलिए ऐप वही डेटाबेस रखता है। स्कीमा बदलाव सिर्फ़ टेबल और कॉलम जोड़ते हैं; कुछ भी अपने आप हटाया नहीं जाता, न किसी का टाइप बदला जाता है।
क्या कुछ बनाए बिना API को काम करते हुए देखा जा सकता है?
हाँ। LUMA स्टोर खोलें और network टैब देखें: प्रोडक्ट की सूची api-backend.vulk.dev/api/proj_266b7c3c/products से आती है, और ऑर्डर वाला रूट हर उस व्यक्ति को मना कर देता है जिसने साइन इन नहीं किया है।


