AI से बनी ऐप को export करके खुद होस्ट कैसे करें

AI से बनी ऐप को self-host करने के लिए कोड बाहर निकालें (डाउनलोड या आपकी अपनी GitHub repository में sync), उसके secrets को environment variables के रूप में दोबारा बनाएं, database को ले जाएं या दोबारा बनाएं, और ऐप के अनुरूप host पर deploy करें: सादे front end के लिए static host, और back end वाली किसी भी चीज़ के लिए ऐसा platform जो servers या containers चलाता हो। कोड आमतौर पर सबसे आसान हिस्सा है। असली काम डेटा, secrets और वे services हैं जो builder आपके लिए चुपचाप चला रहा था।

कोड बाहर क्यों निकालें

अपना कोड साथ ले जाने के अच्छे कारण हैं, और कुछ कम अच्छे भी।

अच्छे कारण:

• मालिकाना हक और सुरक्षा। आपकी अपनी repository में कोड की एक प्रति उस स्थिति में आपकी रक्षा करती है जब builder कीमत, features या शर्तें बदल दे।
• डेवलपर्स को सौंपना। इंजीनियरिंग टीम कोड को Git में, अपने सामान्य tools और review प्रक्रिया में चाहेगी।
• खास ज़रूरतें। डेटा कहां रहे, कोई खास cloud provider, कंपनी की security नीतियां, या ऐसा infrastructure जो builder नहीं देता।
• पैमाना या लागत जब उस आकार पर अपना infrastructure चलाना सच में फ़ायदेमंद हो।

कम अच्छे कारण: कुछ उपयोगकर्ताओं वाली छोटी ऐप को हर महीने की थोड़ी सी रकम बचाने के लिए ले जाना। Self-hosting काम आप पर डाल देता है: updates, backups, monitoring, security patches। यह सही व्यापार हो सकता है; बस इसे सोच-समझकर करें।

एक समझदार बीच का रास्ता: जहां हैं वहीं बनाते और होस्ट करते रहें, लेकिन शुरू से ही अपनी GitHub repository में sync करते रहें। बीमा भी मिल जाता है और संचालन का बोझ नहीं बढ़ता। अगर Git आपके लिए नया है, तो GitHub क्या है पढ़ें।

Export में क्या है और क्या नहीं

Export पर भरोसा करने से पहले उसे खोलकर जांचें। आमतौर पर:

Secrets जानबूझकर बाहर रखे जाते हैं: जो archive आप ईमेल या commit कर सकते हैं, उसमें असली keys कभी नहीं होनी चाहिए। Dependencies इसलिए बाहर रहती हैं क्योंकि उन्हें lock file से दोबारा बनाया जाता है।

चरण 1: कोड बाहर निकालें

दो आम तरीके हैं:

• Project का archive डाउनलोड करें। तेज़ है, और एक बार की गति या backup के लिए ठीक है।
• GitHub पर sync करें। लगातार काम के लिए बेहतर: पूरा इतिहास, कहीं भी clone करना आसान, और ज़्यादातर hosts हर push पर सीधे GitHub repository से deploy करते हैं।

दोनों में, कंप्यूटर (या cloud dev environment) पर clone या unpack करें और README ढूंढें। अगर न हो, तो छोड़ने से पहले builder के AI से एक बनवाएं:

इस project को इस platform के बाहर चलाने के लिए README लिखो: stack, ज़रूरी runtime versions, install और build commands, start command और port, हर environment variable जो code पढ़ता है (नाम और उद्देश्य, values नहीं), और database migrations कैसे चलाए जाते हैं।

यह एक prompt बहुत समय बचाता है, क्योंकि यह सेटअप के उन हिस्सों को लिखने पर मजबूर करता है जो अब तक सिर्फ़ निहित थे।

चरण 2: पहले लोकल पर चलाएं

किसी भी जगह deploy करने से पहले साबित करें कि ऐप अपने आप चलती है:

1. README में बताया गया runtime install करें — Node.js, Python, Java, .NET — सही मेल खाते version में।
2. Dependencies install करें (npm install, pnpm install, pip install -r requirements.txt, या समकक्ष)।
3. Environment variables के साथ एक लोकल .env file बनाएं, जहां संभव हो test keys के साथ। इसे Git से बाहर रखें। Environment variables और secrets क्या हैं में यह विचार समझाया गया है।
4. Database से जोड़ें — लोकल Postgres, या किसी managed provider का मुफ़्त development database।
5. Migrations चलाएं, फिर ऐप शुरू करें और मुख्य flows पर क्लिक करके देखें।

जो यहां टूटेगा, वह host पर भी टूटेगा, और अपनी मशीन पर उसे debug करना बहुत आसान है। आम आश्चर्य: builder के preview का एक hard-coded URL, builder द्वारा अपने आप दिया गया कोई गायब environment variable, या कोई service (file storage, image resizing) जो सिर्फ़ platform पर मौजूद थी।

चरण 3: डेटा ले जाएं

अगर ऐप में असली users हैं, तो डेटा कोड से ज़्यादा मायने रखता है।

• Database export करें। Postgres के लिए pg_dump एक file बनाता है, जिसे pg_restore या psql से नए database में वापस लाया जा सकता है। अगर आपकी सीधी पहुंच नहीं है, तो builder के AI से इसे चलवाएं और बनी हुई file के बारे में समझवाएं।
• Uploaded files ले जाएं। अगर users ने images या documents upload किए हैं, तो वे database से अलग object storage में रहते हैं। उन्हें अपनी नई storage (जैसे S3-compatible bucket) में कॉपी करें, और अगर stored URLs में पुराना host है तो उन्हें अपडेट करें।
• Cut-over की योजना बनाएं। Live ऐप के लिए सरल तरीका एक छोटी maintenance window है: writes रोकें, आखिरी export लें, नए host पर restore करें, DNS बदलें, फिर खोलें। हर चरण पहले लिख लें।
• असली move से पहले एक scratch database में restore टेस्ट करें।

अगर Postgres आपके लिए नया है, तो Postgres क्या है बुनियादी बातें समझाता है।

चरण 4: होस्ट चुनें

Host को ऐप के आकार से मिलाएं। नीचे के नाम सितंबर 2026 तक हर श्रेणी के जाने-माने providers के उदाहरण हैं, कोई रैंकिंग नहीं; वर्तमान सुविधाएं और कीमतें उनकी साइटों पर जांचें।

आपको इनकी भी ज़रूरत होगी:

• Managed database। कई app hosts Postgres देते हैं, और Neon या Supabase जैसी समर्पित सेवाएं इसे अलग से देती हैं। Managed लेना फ़ायदेमंद है: backups और updates किसी और की ज़िम्मेदारी होते हैं।
• Object storage, अगर ऐप में uploads हैं।
• Email भेजना, payments और AI providers — इन्हें आमतौर पर नए host पर वही API keys सेट करनी होती हैं।

Trade-offs के बारे में ईमानदारी से: platform hosts (ऊपर की पहली चार पंक्तियां) सेट करने और संभालने में तेज़ हैं, लेकिन आपका नियंत्रण कम है और ट्रैफ़िक बढ़ने पर लागत भी बढ़ सकती है। Virtual server स्थिर लोड पर अक्सर सस्ता और पूरी तरह आपके नियंत्रण में होता है, लेकिन patching, TLS, backups, monitoring और recovery की ज़िम्मेदारी आपकी होती है। अगर टीम में कोई यह काम नहीं लेना चाहता, तो platform चुनें। Hosting की बुनियादी बातों के लिए, web hosting क्या है देखें।

चरण 5: Deploy करें और स्विच करें

1. Repository को host से जोड़ें, या container image push करें।
2. Host के dashboard में environment variables सेट करें — README की हर variable, असली values के साथ।
3. Build और start commands और port सेट करें। कई hosts port को PORT environment variable में देते हैं; ऐप को उसी पर सुनना चाहिए और सभी interfaces पर (0.0.0.0), सिर्फ़ localhost पर नहीं।
4. नए database पर migrations चलाएं।
5. DNS छूने से पहले host के अस्थायी URL पर टेस्ट करें।
6. बाहरी services अपडेट करें जो पुराने URL की ओर इशारा करती हैं: payment webhooks, login के लिए OAuth redirect URLs, email links, allowed origins।
7. Domain को नए host पर ले जाएं, DNS records बदलकर। custom domain कैसे जोड़ें में records समझाए गए हैं।
8. पुराना deployment थोड़ी देर चालू रखें जब तक आश्वस्त न हों, फिर उसे बंद करें।

चरण 6 अक्सर भुला दिया जाता है: मूव के बाद चुपचाप फेल होने वाले logins और payments का कारण आमतौर पर एक callback URL होता है जो अब भी पुराने host की ओर इशारा करता है।

चरण 6: संचालन अपने हाथ में लें

जब आप खुद होस्ट करते हैं, तो जो काम builder करता था, वह आपका हो जाता है। कम से कम: अपने आप होने वाले database backups जिनका restore टेस्ट किया गया हो, error tracking, uptime alerts, dependency updates, और यह नोट कि हर account तक किसकी पहुंच है। AI प्रोटोटाइप को production तक कैसे ले जाएं में इस सूची को विस्तार से समझाया गया है।

Export चेकलिस्ट

• Code ऐसी repository में जो आपकी है, README के साथ जिसमें run, build और env vars हों
• Clean clone से ऐप लोकल पर चलती है
• Database export हुआ और restore टेस्ट हुआ; uploaded files कॉपी हुईं
• ऐप के आकार के अनुसार host चुना गया, साथ में managed database और storage
• नए host पर सभी environment variables असली values के साथ सेट हैं
• Webhooks, OAuth redirects और email links अपडेट हुए
• DNS स्विच हुआ, पुराना deployment थोड़ी देर रखा गया, फिर हटाया गया
• Backups, monitoring और access list तैयार हैं

Mythex से export करना

Mythex पर आप अपने बनाए कोड के मालिक हैं। Pro plan पर आप Project settings → Export से project को archive के रूप में डाउनलोड कर सकते हैं, या GitHub कनेक्ट करके अपनी repository पर push और pull कर सकते हैं; Free plans पर कोड सिर्फ़ पढ़ने के लिए दिखता है, export या sync नहीं होता। Exports में secrets और node_modules नहीं होते, इसलिए नए host पर अपने secrets दोबारा बनाएं। डॉक्स में ये चरण export और कहीं और चलाना और GitHub, export और import में हैं। आप Mythex पर होस्ट करते रह सकते हैं और GitHub sync को सिर्फ़ अपनी प्रति और handoff के रास्ते के रूप में रख सकते हैं; अगर आप मूव करते हैं, तो नया host चालू होने के बाद Mythex ऐप को unpublish करें।

सवाल