ब्लैक फ्राइडे सेल60% तक की छूट
  • सालाना प्लान के पहले साल पर 60% छूट
  • लाइफ़टाइम लाइसेंस पर 45% छूट
खत्म होगा
ऑफ़र पाएँ
तकनीक · Self-hosted ERP

आपका पूरा कारोबार चलाने के लिए बना—आपके अपने server पर।तेज़, सुरक्षित और आगे बढ़ने के लिए तैयार।

Store Console एक modular monolith है—एक पूरा ERP, जिसमें commerce शामिल है। यह एक ही एप्लिकेशन और एक ही डेटाबेस के रूप में आता है, जिसे आप उस infrastructure पर install करते हैं जिसका मालिक आप हैं। इस पेज पर बताया गया है कि यह कैसे बना है, कितनी तेज़ी से चलता है और आपका डेटा कैसे सुरक्षित रहता है।

PHP 8.4 · Laravel 13 · React 19PostgreSQL 15+ या MySQL 8+Docker किसी भी Linux server पर चलेहर हफ़्ते एक नया release आता है
आर्किटेक्चर का एनिमेशन: स्टोरफ्रंट, स्टाफ़, ऐप्स और चैट से आने वाले अनुरोध एक ही एप्लिकेशन में जाते हैं। modules ऐसे इवेंट्स पर प्रतिक्रिया देते हैं, जैसे OrderPlaced और StockReserved, और सारा डेटा एक ही डेटाबेस में आता है।
लाइव व्यू: हर अनुरोध, हर इवेंट—एक ही डेटाबेस।
फ़िल्म देखें

अपने server पर चलने के लिए बनाया गया।

पूरा कारोबार आपके अपने server पर। एक app, एक database, और एक क्लिक में updates—जो अपने आप rollback हो जाते हैं।

Store Console · अपने server पर चलने के लिए बनाया गया0:50
voiceover वाली एक छोटी फ़िल्म। आपका पूरा कारोबार, एक ही कंसोल में।
83–89 msहर पेज का server समय, बिना page cache
≈0.4 sएक सामान्य पेज—2 vCPU पर एक साथ 40 ग्राहक
99.97%हमारे लोड टेस्ट में कुल कितने अनुरोध serve हुए
14,000+हर release पर automated tests चलते हैं
यह कैसे बनाया गया है

एक ही एप्लिकेशन—अंदर हर module की सीमा साफ़।

40+ modules एक ही कोडबेस, एक ही डेटाबेस और एक ही रिलीज़ पर चलते हैं. हर module अपनी टेबल्स, नियम और स्क्रीन खुद संभालता है. OrderPaid और StockReserved जैसे इवेंट्स से आपस में जुड़ते हैं, इसलिए ज़्यादातर बदलाव एक module में ही सीमित रहते हैं.

एक सिस्टम, अलग-अलग modules

एक सिस्टम की भरोसेमंदता, अलग-अलग सर्विसेज़ की साफ़ी.

Modules के बीच नेटवर्क हॉप नहीं होता और किसी चीज़ को सिंक नहीं करना पड़ता. बिज़नेस बढ़ने पर ज़रूरत के modules चालू कीजिए; कोर वैसा ही रहता है.

अपना डेटाहर module अपनी टेबल्स और माइग्रेशन्स खुद संभालता है
इवेंट्स, कॉल्स नहींOrderPaid या StockReserved इवेंट्स modules को आपस में जोड़ते हैं
हर रूट पर अलग परमिशनहर स्क्रीन और एक्शन के लिए नाम वाली परमिशन की जाँच होती है
ज़रूरत पर लोडरिक्वेस्ट में जिस काम की ज़रूरत नहीं, module उसे करता ही नहीं.
ERP + उत्पादन

सैल्स ऑर्डर से लेजर तक — सब एक ही ट्रांज़ैक्शन ट्रेल में.

ज़्यादातर ERP उत्पादन के लिए अलग-अलग products में बँट जाते हैं. यहाँ फ़ैक्ट्री सैल्स, स्टॉक और अकाउंट्स के वही रिकॉर्ड साझा करती है, इसलिए प्लानिंग, शॉप फ़्लोर, क्वालिटी और कॉस्टिंग हमेशा एक-दूसरे से मेल खाते हैं.

  • Versions, phantom assemblies और alternate parts के साथ कई स्तरों के BOMs
  • MRP नेटिंग और drag-and-drop कैपेसिटी बोर्ड
  • वर्क ऑर्डर्स, शिफ़्ट्स, डाउनटाइम, OEE और मेंटेनेंस
  • SPC चार्ट्स, AQL सैंपलिंग, NCMR/CAPA और Gauge R&R
  • लॉट जीनियलॉजी, रिकॉल्स, ई-सिग्नेचर्स और टैम्पर-एविडेंट ऑडिट चेन
  • FIFO, भारित या मानक लागत — चुनी हुई कॉस्टिंग सीधे अकाउंटिंग में post होती है.
एक बिक्री ऑर्डर MRP, वर्क ऑर्डर, सामग्री, गुणवत्ता, तैयार माल, लागत और डिलीवरी के चरणों से गुज़रता है, और हिसाब-किताब संतुलित रहता है।
Headless API + रियल-टाइम

हर स्टोरफ्रंट के लिए एक API. लाइव अपडेट हर जगह.

पहले से बना स्टोरफ्रंट, आपका अपना Next.js फ्रंटएंड और मोबाइल ऐप्स — सब एक ही कैटलॉग, कार्ट, checkout और अकाउंट सर्विसेज़ पर चलते हैं. Reverb WebSockets बदलाव होते ही भेज देते हैं.

  • 207 एंडपॉइंट्स /api/storefront/v1 के अंतर्गत, और हर इंस्टॉल पर OpenAPI 3.1 रिफ़रेंस
  • कॉन्ट्रैक्ट टेस्ट्स रिफ़रेंस और कोड को हमेशा एक-दूसरे के साथ रखते हैं
  • ETag और 304 रिस्पॉन्स के साथ, हर बदलाव पर ऑप्शनल CDN purge भी
  • ग्राहकों को ऑर्डर स्टेटस, चैट रिप्लाई और नोटिफ़िकेशन लाइव दिखते हैं
  • शॉप-फ़्लोर बोर्ड्स 94 लाइव उत्पादन इवेंट्स से update होते हैं
चार तरह के स्टोरफ्रंट्स से रिक्वेस्ट्स एक API में आती हैं, और लाइव इवेंट्स WebSockets के ज़रिए वापस भेजे जाते हैं — ऑर्डर स्टेटस, चैट, अलर्ट्स, कैटलॉग रिफ्रेश और शॉप-फ़्लोर बोर्ड्स.
डेटा

हर तरह का डेटा, सही जगह पर।

लाइव रिकॉर्ड एक ही डेटाबेस में रहते हैं, जहाँ लेन-देन एक साथ पूरे होते हैं. जब सालों का इतिहास जमा होने लगे, तो एक ही सेटिंग से एक्टिविटी लॉग, चैट हिस्ट्री, CRM ईमेल और शॉप-फ़्लोर इवेंट्स को MongoDB या दूसरे डेटाबेस में ले जाएँ, और लाइव टेबल को छोटा व तेज़ रखें।

रिकॉर्ड लाइव डेटाबेस, कैश और फ़ाइल स्टोरेज में आते हैं. फिर सालों का इतिहास एक ही सेटिंग से MongoDB में चला जाता है, जबकि लाइव टेबल छोटे रहते हैं।
परफ़ॉरमेंस

तेज़ इसलिए कि इसे सही तरीके से बनाया गया है, इसलिए नहीं कि server कितना बड़ा है।

हमने 2 vCPU server पर एक लाइव store की load test की, जिसमें खरीदारों के अपने देश की असली शॉपिंग journey थीं. एक आम page, 40 shoppers के एक साथ आने पर भी, लगभग 0.4 s में खुला. यह सब सादे PHP-FPM पर हुआ, बिना किसी अलग runtime के।

लोड टेस्ट का रिप्ले: 2 vCPU server पर खरीदारों की संख्या एक साथ 40 तक बढ़ी, जबकि आम पेज में लगभग 0.4 s लगा, CPU पर load के लिए जगह बची रही और मेमोरी स्थिर रही।
स्केलिंग

एक server से शुरू करें, सॉफ़्टवेयर बदले बिना आगे बढ़ें।

शुरुआत में सब कुछ एक ही मशीन पर रखें. जैसे ही कारोबार बढ़े, डेटाबेस को अलग मशीन पर ले जाएँ, लोड बैलेंसर के पीछे ऐप server जोड़ें और बैकग्राउंड काम के लिए अलग नोड्स दें—सब कुछ एक ही रिलीज़ और डेटा पर चलता रहे।

  • ऐप server के पास कोई लोकल स्टेट नहीं होता: सेशन और कैश Redis में रहते हैं।
  • फ़ाइलें लोकल डिस्क, S3 या Cloudflare R2 पर रहती हैं।
  • भारी रिपोर्टिंग और ट्रैफ़िक के लिए रीड रेप्लिका और CDN।
एक server को चार चरणों में बढ़ा सकते हैं: database अलग होगी, load balancer के पीछे app servers बढ़ेंगे और workers के अलग nodes बनेंगे। हर चरण पर वही release और data रहेंगे।
सुरक्षा

आपका डेटा आपके server पर ही रहता है, कई परतों से सुरक्षित।

ऐसा कोई साझा cloud tenant नहीं है जिसे हैक किया जा सके, और किसी vendor के पास भी आपके रिकॉर्ड की कॉपी नहीं होती। हर जगह access की जाँच होती है, AI के लिखे बदलाव किसी व्यक्ति की मंज़ूरी का इंतज़ार करते हैं, और recovery पहले से तैयार रहती है।

अज्ञात device से होने वाला sign-in रोक दिया जाता है। फिर मंज़ूर किया गया request network, पहचान, अनुमति, डेटा, AI और recovery के checks पास करने के बाद ही आगे बढ़ता है।
गुणवत्ता

अपडेट से पहले जाँच, लगते ही सुरक्षा।

हर बदलाव static analysis और 14,000 से ज़्यादा अपने-आप चलने वाले टेस्ट से पास होता है। हर release को sandbox में बनकर जाँचा जाता है, और server पर कुछ भी बदलने से पहले safety snapshot ले लिया जाता है।

हर बदलाव पाँच जाँचों से गुज़रता है: code review, static analysis, 14,000 से ज़्यादा tests, signed sandbox build और आपके server पर सुरक्षित update।
एक क्लिक में अपडेट

अपडेट लगते वक़्त भी store सुरक्षित रहता है।

admin panel में एक क्लिक करें। पहले safety snapshot बनता है, फिर signed release बनकर live site के बगल में health check होता है। हर check पास होने पर ही अपडेट live होता है।

एक click वाला update: safety snapshot, signed release, live site के बगल में build, migrations की जाँच, health check और switch—fail होने पर automatic roll back।
नए release

हर हफ्ते Store Console थोड़ा और बेहतर होता है।

हर हफ्ते सुधार और नई सुविधाएँ एक नए release में आते हैं। हर अपडेट admin panel से लगता है, और उससे पहले safety snapshot बन जाता है।

2026 के दस हफ़्तों में हर हफ़्ते के releases: कुल 89, जिनमें 1,500 से ज़्यादा सुधार और नई सुविधाएँ थीं।
तकनीक का ढांचा

हर हिस्सा भरोसेमंद और आम-इस्तेमाल है। रखरखाव के लिए कोई अनोखी तकनीक नहीं।

PHP और React जानने वाली कोई भी टीम इसे चला सकती है, इसमें बदलाव कर सकती है और पूरी जाँच कर सकती है। हर हिस्सा आसानी से host किया जा सकता है, और उसके लिए अच्छे दस्तावेज़ भी मिलते हैं।

ऐप्लिकेशन

PHP 8.4 और Laravel 13 की साफ़-सुथरी लेयरिंग में: कंट्रोलर, सर्विसेज़ और रिपॉज़िटरी।

PHP 8.4Laravel 13

इंटरफ़ेस

React 19 और TypeScript के साथ Inertia server rendering और Tailwind CSS 4।

React 19SSR

डेटाबेस

PostgreSQL 15+ pgvector के साथ या MySQL 8+ चुनें। बड़े डेटा के लंबे इतिहास के लिए MongoDB भी एक विकल्प है।

PostgreSQLMySQLMongoDB

कैश और क्यूज़

Redis 7 कैश, सेशन और क्यूज़ के लिए, Horizon की निगरानी के साथ।

Redis 7Horizon

रियल टाइम

Reverb WebSockets लाइव ऑर्डर, चैट, नोटिफिकेशन और शॉप-फ़्लोर बोर्ड को तुरंत अपडेट करते हैं।

WebSockets

AI

OpenAI, Anthropic या अपनी API keys के साथ लोकल मॉडल चुनें, और pgvector पर सेमेंटिक सर्च पाएं।

आपकी API keys

हेडलेस

एक वर्ज़न वाला REST API, OpenAPI 3.1 रेफ़रेंस, Next.js स्टोरफ़्रंट और मोबाइल ऐप्स के साथ।

RESTOpenAPI

डिप्लॉयमेंट

Docker Compose किसी भी 64-bit Linux पर चलता है—मानक PHP-FPM, nginx और अपने-आप TLS के साथ।

DockerPHP-FPM

गुणवत्ता की जाँच

PHPStan लेवल 7 के साथ 14,000 से ज़्यादा इकाई, फीचर, कॉन्ट्रैक्ट और ब्राउज़र टेस्ट।

PHPStan 7Playwright
अपडेट और सहायता

हर हफ़्ते बेहतर, हर बार लोगों के साथ।

self-hosted सॉफ़्टवेयर खरीदने का मतलब यह नहीं कि आप अकेले छोड़ दिए जाएँ। Store Console लगातार बेहतर होता रहता है, और जो टीम इसे बनाती है, वही आपके सवालों के जवाब देती है।

हर हफ़्ते एक नया संस्करण

अगस्त 2026 से 80 से ज़्यादा संस्करण, 1,500 से ज़्यादा सुधार और नए फीचर के साथ।

एक क्लिक में अपडेट

एडमिन पैनल से इंस्टॉल करें। पहले सुरक्षा का स्नैपशॉट बनता है, और नया संस्करण लाइव होने से पहले सेहत जाँच से गुज़रता है।

अपने आप रोल बैक

अगर अपडेट कभी फेल हो जाए, तो Store Console पिछला संस्करण वापस लाता है और स्नैपशॉट से आपका डेटा बहाल कर देता है।

बनाने वालों से मदद

[email protected] पर ईमेल करें या टिकट खोलें, और इसे बनाने वाले इंजीनियरों से साफ़ जवाब पाएँ।

आपकी रफ़्तार

अपडेट कभी ज़बरदस्ती नहीं आते। जब आप चाहें, तब इंस्टॉल करें, और पहले टेस्टिंग कॉपी पर आज़मा लें।

पूरी जानकारी

इंस्टॉल गाइड, module गाइड और API रेफ़रेंस हर इंस्टॉल के साथ आते हैं और हमेशा अपडेटेड रहते हैं।

तकनीकी सवाल

इंस्टॉल से पहले इंजीनियरों के सवाल।

शुरू करने के लिए कौन-सा server चाहिए?

टेस्ट करने के लिए 2 vCPU और 4 GB RAM चाहिए। ERP वाले लाइव स्टोर के लिए 4 vCPU और 8 GB। ज़रूरतों वाले पेज पर पूरी साइज़िंग गाइड है।

PostgreSQL या MySQL?

दोनों में से कोई भी। AI खोज के लिए pgvector का इस्तेमाल होता है, इसलिए PostgreSQL 18 सुझाया जाता है; MySQL 8+ पर भी वही module और माइग्रेशन चलते हैं।

क्या Octane, Swoole या FrankenPHP चाहिए?

नहीं। हमारे बताए आंकड़े आम PHP-FPM और OPcache के साथ लिए गए हैं, इसलिए सामान्य होस्टिंग पर भी वही प्रदर्शन मिलता है। कुछ खास चलाने की ज़रूरत नहीं।

क्या इतिहास MongoDB में ले जाया जा सकता है?

हाँ। एक कनेक्शन सेट करते ही गतिविधि लॉग, चैट इतिहास, CRM ईमेल और दुकान के फ़्लोर की घटनाएँ MongoDB या दूसरे SQL डेटाबेस में चले जाते हैं, जबकि लाइव रिकॉर्ड वहीं रहते हैं।

अपडेट कैसे होते हैं?

अपडेट एडमिन पैनल से इंस्टॉल होते हैं। पहले डेटाबेस और फ़ाइलों का सुरक्षा स्नैपशॉट लिया जाता है। नए रिलीज़ का health-check लाइव वाले के साथ होता है, और कुछ भी गड़बड़ हो तो अपने आप rollback कर दिया जाता है।

क्या हमारा डेटा हमारे server से बाहर जाता है?

कोई सेवा तभी जुड़ती है जब आप खुद उसे जोड़ें—जैसे पेमेंट गेटवे, कूरियर, ईमेल प्रोवाइडर या AI मॉडल। हर सेवा को सिर्फ इतनी जानकारी मिलती है जितनी उसके काम के लिए ज़रूरी है। आपके रिकॉर्ड की कोई कॉपी हमारे पास नहीं होती।

क्या हम एक से ज़्यादा server पर चला सकते हैं?

हाँ। ऐप servers अपने पास कोई लोकल स्टेट नहीं रखते, इसलिए Redis और साझा फ़ाइल स्टोरेज के साथ कई servers को लोड बैलेंसर के पीछे चलाया जा सकता है। डेटाबेस को अपने अलग server या किसी मैनेज्ड सर्विस पर ले जाया जा सकता है।

क्या हमारे डेवलपर्स इसे आगे बढ़ा सकते हैं?

हाँ। Modules एक ही लेयर वाले पैटर्न में बने होते हैं और इवेंट्स के ज़रिए आपस में बात करते हैं। REST API की पूरी डॉक्युमेंटेशन OpenAPI में मिलती है, और स्टोरफ़्रंट की जगह आप अपनी फ़्रंटएंड लगा सकते हैं।

अपने server पर इसे चलाकर देखें।

अपना plan बनाएं, Docker के साथ deploy करें और हर रिकॉर्ड अपने control में रखें।