मैंने इस समीक्षा के लिए दो WordPress अनुप्रयोगों को Cloudways Site Manager में नामांकित किया, एक किसी application की अपनी sidebar के भीतर छिपी onboarding screen के माध्यम से, और एक account स्तर पर मौजूद bulk flow के माध्यम से।
वहाँ से, मैंने चार plugins पर एक वास्तविक Safe Update चलाया, दोनों sites को कवर करने वाला एक shared auto-update schedule बनाया, activity logging चालू की, और account-level dashboard में इतना समय बिताया कि समझ सकूँ कि वही जानकारी का हिस्सा एक से अधिक जगहों पर कहाँ दिखता है, और यह जितना लगता है उससे ज़्यादा क्यों मायने रखता है।
Site Manager ने एक पुराने Cloudways add-on called SafeUpdates को बदल दिया। SafeUpdates क्या नहीं कर सकता था, यह समझना वर्तमान product के लगभग हर design निर्णय को समझाता है।
SafeUpdates सब कुछ SSH के माध्यम से चलाता था, जिससे किसी भी ऐसे व्यक्ति के लिए, जो कुछ से अधिक sites manage कर रहा हो, समस्याओं का एक विशिष्ट सेट पैदा होता था:
बीस या उससे अधिक WordPress installs manage करने वाली agencies ने Cloudways से, प्रभावी रूप से, कहा कि tool तब तक काम करता है जब तक वह scale नहीं करता, और scale करना ही Cloudways पर होने का पूरा कारण था।
Site Manager इसी feedback का सीधा जवाब है। यह context बाकी review को पढ़ने के लिए मायने रखता है, क्योंकि यह समझाता है कि product के कुछ हिस्से Public Preview में होने के बावजूद असामान्य रूप से mature क्यों लगते हैं, और onboarding step जैसे कुछ हिस्से, जो आप पहले दिन hit करेंगे, अभी भी seams क्यों दिखाते हैं।
उस background के साथ, अगला सवाल scope का है: यह tool वास्तव में किस तक पहुँच सकता है. onboarding, updates, और scheduling में जाने से पहले, यह स्पष्ट होना ज़रूरी है कि Site Manager क्या कवर करता है और क्या नहीं, क्योंकि ईमानदार जवाब एक साधारण yes या no से अधिक nuanced है।
account-level Site Manager में enroll होने के लिए उपलब्ध हर application, चाहे per-app screen के माध्यम से हो या Integrations के तहत bulk wizard से, मेरे Cloudways account के अंदर पहले से मौजूद server से आया था।
कहीं और hosted install के credentials paste करने के लिए कोई field नहीं था, और न ही किसी दूसरे host पर चल रही site के लिए कोई connector।
इस review में कवर किया गया पूरा feature set, Safe Update का staging clone, visual regression testing, activity logs, bulk scheduling, सब कुछ इसी native, Cloudways-hosted layer के अंदर रहता है।
Cloudways एक free WordPress plugin भी प्रकाशित करता है, जिसका नाम भी Cloudways Site Manager है, जिसे WP Remote के साथ co-developed किया गया है।
Native dashboard के विपरीत, यह plugin सीधे WordPress site पर install होता है, चाहे वह कहीं भी hosted हो, जिसका अर्थ है कि यह उसी centralized view का एक version external, non-Cloudways site में ला सकता है।
हालाँकि यह उसी product का एक अलग रूप है, और दोनों के बीच का अंतर मायने रखता है:
| Capability | Native Site Manager (Cloudways-hosted apps) | Site Manager Plugin (any host) |
|---|---|---|
| Centralized dashboard | Yes | Yes |
| Core, plugin, theme updates | Yes | Yes |
| Safe Update (staging clone + visual regression) | Yes | No |
| Server-level caching (Varnish, Redis, Cloudflare) | Yes | No |
| Activity logs | Yes (Pro) | Not equivalent |
| Cost | Free (Basic) / paid (Pro) | Free |
Plugin सक्रिय रहने पर WordPress के अपने automatic updates भी disable कर देता है, Cloudways की ओर से remote management के दौरान conflicts से बचने के लिए यह जानबूझकर किया गया निर्णय है।
Cloudways इस बारे में साफ़ है कि plugin route एक stepping stone है, destination नहीं: अगर आप full stack, automated backups, one-click staging, Cloudflare integration, managed caching चाहते हैं, तो कथित best practice external site को लंबे समय तक remotely manage करने के बजाय उसे Cloudways पर migrate करना है।
पूरी तरह Cloudways-hosted portfolio वाली agency के लिए, इनमें से कुछ भी मायने नहीं रखता। लेकिन उन लोगों के लिए जो अभी भी कुछ sites कहीं और चला रहे हैं, और जिन agencies से मैंने वर्षों में बात की है उनमें से अधिकांश के पास कम-से-कम कुछ होती हैं, plugin basic monitoring और updates के लिए एक वास्तविक option है, बस native dashboard जो करता है उसका विकल्प नहीं।
scope का प्रश्न सुलझने के बाद, व्यावहारिक हिस्सा यहाँ से शुरू होता है: वास्तव में किसी WordPress application को enroll करना। Cloudways native Site Manager में जाने के दो तरीके देता है, और वे काम के लिए समान रूप से उपयुक्त नहीं हैं।
पहली बार मैं वहाँ ठीक इसी तरह पहुँचा। Cloudways home dashboard से, मैंने अपने server पर क्लिक किया, फिर उस server पर मौजूद WordPress application पर, जिससे आप उस app के Access Details page पर पहुँच जाते हैं।
वहाँ का left sidebar Access Details, Staging Management, Monitoring, Application Security, Domain Management, और फिर Site Manager दिखाता है, जिस पर “New” tag लगा है। उस पर क्लिक करने से मैं सीधे “Simplify App Management with Site Manager,” नामक screen पर पहुँचा, जो पूरी तरह उसी एक application के लिए scoped थी, और जिसमें Basic और Pro नाम के दो plan cards side by side रखे थे।
मैंने Get Pro पर क्लिक किया। यहीं चीज़ें बिगड़ गईं।
screen बदलकर “Subscribing to the Site Manager Plan…” हो गया, जिसमें एक संदेश था कि Cloudways plugin install कर रहा था और मेरे site data को sync कर रहा था, और यह application के size के आधार पर कुछ मिनट ले सकता है।
यह लगभग दो मिनट तक चला और फिर विफल हो गया, और एक red error notification लौटा: “Please delete existing plugin and install again.” मेरा पहले से कोई installation नहीं था जिसे delete किया जा सके, इसलिए संदेश ने खुद यह नहीं बताया कि वास्तव में क्या गलत हुआ था।
मैंने बिना कुछ बदले, उसी plan screen पर Get Pro पर दूसरी बार क्लिक किया। वह प्रयास काम कर गया। यह लगभग तीन मिनट चला और एक green success notification के साथ समाप्त हुआ, जिसने पुष्टि की कि मैंने Site Manager plan subscribe कर लिया है, और मुझे app के Site Manager Overview page, plugin count, theme count, performance score, और Manage Updates table के साथ तैयार स्थिति में पहुँचा दिया।
यह वह path है जिसका उपयोग तब करना चाहिए जब आपके पास एक से अधिक site हों, और यहाँ ठीक वही तरीका है जिससे मैंने इसे खोजा और इस्तेमाल किया।
Cloudways home dashboard से, left-hand navigation में icons की एक row है: Home, Flexible, Autonomous, Integrations, और Agency Partners. मैंने Integrations पर क्लिक किया। इससे cards का एक panel खुला, जिसमें Site Manager (“New” के साथ), Application Migration, DNS Made Easy, CookieYes, और Equalize Digital Accessibility Checker शामिल थे।
Site Manager card पर क्लिक करने से मैं पूरी तरह अलग screen पर पहुँचा, जो Path 1 से अलग थी, और जो breadcrumb Integrations → Add-Ons → Site Manager के तहत रहती है, और जिसमें अपनी tab row है: Overview, Manage Updates, Auto Updates, History.
यह Overview page असली command center है। यह account-wide stats दिखाता है, Total Apps on Site Manager, Apps on Free Plan, Apps on Pro Plan, Apps with Auto Updates, और नीचे एक Manage Applications table, जिसमें पहले से enrolled हर app सूचीबद्ध है।
और apps जोड़ने के लिए, मैंने उस table के top right में Add Apps to Site Manager पर क्लिक किया। इससे एक two-step wizard खुला:
सूची के ऊपर एक note ने बताया कि यह staging apps, stopped servers पर मौजूद apps, और पुराने SafeUpdates add-on चला रहे किसी भी app को exclude करता है। मैंने जिस app की मुझे ज़रूरत थी उसे चेक किया और Select Plan पर क्लिक किया।
एक बार wizard screen पर पहुँचने के बाद पूरी flow में एक मिनट से भी कम समय लगा, और यह step one में चुनी गई हर app पर एक साथ लागू हो गया, हर site के लिए plan choice दोहराने की ज़रूरत नहीं पड़ी।
अब दोनों paths से apps enroll करने के बाद, यहाँ वह finding है जिसने इस product की day-to-day upkeep के बारे में मेरी सोच बदल दी। मैंने उसी server पर, जहाँ Site Manager पहले से एक दूसरे app को actively manage कर रहा था, एक दूसरा WordPress application जोड़ दिया।
मुझे उम्मीद थी कि नया app अपने आप दिख जाएगा, क्योंकि वह उस app के ठीक बगल में था जिसे Site Manager पहले से जानता था। ऐसा नहीं हुआ। account-level dashboard का “Total Apps on Site Manager” count वहीं का वहीं रहा, जब तक मैंने नए app को manually onboarding से नहीं गुज़ारा।
यह एक design choice है, लेकिन यह एक ऐसा design choice है जिसकी operational cost है:
Site Manager एक वास्तव में उपयोगी free tier और एक Pro tier में बँटा है, जो उन features को unlock करता है जिनके इर्द-गिर्द कोई agency workflow बनाएगी।
| Feature | Basic (Free) | Pro |
|---|---|---|
| Site Overview | Yes | Yes |
| Manage Users, Themes, Plugins | Yes | Yes |
| Quick Updates | Yes | Yes |
| WordPress Single Sign-On | Yes | Yes |
| Centralized Dashboard | Yes | Yes |
| Safe Updates (staging clone + regression test) | No | Yes |
| Scheduled Auto Updates | No | Yes |
| Site Performance Monitoring | No | Yes |
| Activity Logs | No | Yes |
| Update History | No | Yes |
Basic कोई stripped-down trial नहीं है। इसमें एक वास्तविक site overview, wp-admin को छुए बिना users, themes, और plugins manage करने की क्षमता, one-click WordPress single sign-on, Quick Updates, और उल्लेखनीय रूप से, centralized dashboard itself शामिल है।
Cloudways ने core “see all your sites in one place” अनुभव को paywall के पीछे नहीं रखा। जो gated है वह सब कुछ है जो उस dashboard को बिना babysitting action लेने लायक भरोसेमंद बनाता है।
Public Preview के दौरान Pro अभी सूचीबद्ध कीमत, जो कि $3 प्रति app प्रति month है, और पाँच applications पार करने पर $2 प्रति app तक गिर जाती है, के बावजूद free में उपयोग के लिए उपलब्ध है।
वह discount threshold arithmetic करने लायक है, इससे पहले कि आप मान लें कि Pro सस्ता scale करता है:
| Sites managed | Pro cost (sticker price) |
|---|---|
| 3 sites | $9/month |
| 5 sites | $10/month ($2/app) |
| 10 sites | $20/month |
| 25 sites | $50/month |
| 50 sites | $100/month |
इनमें से कोई भी संख्या इस बात की तुलना में अनुचित नहीं है कि एक broken, unbacked update client trust की कितनी कीमत चुका सकता है, लेकिन per-app pricing का अर्थ है कि bill आपके portfolio के साथ सीधी रेखा में बढ़ता है, कुछ competing tools की higher tiers पर मिलने वाली step-function discounts की तरह नहीं।
Enrollment और pricing को अलग रखने के बाद, इस review का बाकी हिस्सा इस बात को कवर करता है कि दिन-प्रतिदिन का उपयोग वास्तव में कैसा दिखता है, एक ऐसी architecture से शुरू करते हुए जिसे समझना ज़रूरी है।
Site Manager के design का यह हिस्सा समझने में मुझे सबसे अधिक समय लगा, और interface के भीतर इसे कहीं भी समझाया नहीं गया है।
ये उसी कमरे में जाने वाले तीन दरवाज़े हैं। per-app view उस व्यक्ति के लिए है जो पहले से उस विशिष्ट site के भीतर काम कर रहा है और जिसे अचानक कोई pending update दिख जाता है। account-level row action उस व्यक्ति के लिए है जो पूरे portfolio को स्कैन कर रहा है और अभी एक site पर कार्रवाई करने का निर्णय लेता है।
Scheduling tab मानव को loop से पूरी तरह हटाने के लिए है।
अभी वर्णित तीन दरवाज़ों में से, यह section पहले दो को कवर करता है, per-app view और account-level row action, क्योंकि दोनों वही update mechanism खोलते हैं।
हर plan tier Quick Update प्रदान करता है। इसे लागू करने में कुछ सेकंड लगते हैं: update सीधे production पर install होता है, बिना compatibility check के और पहले कोई backup लिए बिना।
Cloudways की अपनी interface copy tradeoff के बारे में ईमानदार है, चेतावनी देती है कि यह “may carry risks if updates aren’t compatible.”
मैंने इस test में Quick Update नहीं चलाया, इसलिए मैं firsthand यह नहीं बता सकता कि एक failed one screen पर वास्तव में कैसा दिखता है। यह इस review में एक वास्तविक gap है, और मैं Quick Update के failure behavior के बारे में, मेरी या किसी और की, जिसने इसे trigger नहीं किया हो, किसी भी claim को उचित skepticism के साथ देखूँगा।
Safe Update वह जगह है जहाँ Pro अपनी कीमत वसूलता है, और इसे पूरी तरह समझना worthwhile है क्योंकि प्रक्रिया “backup, then update” से कहीं अधिक involved है।
इसे मैंने बिल्कुल इस तरह trigger किया। Integrations → Site Manager के तहत account-level Overview table से, मैंने pending updates वाले app की row ढूँढी और उस row के अंत में तीन-dot Actions menu पर क्लिक किया। इससे चार options खुले: WP-Admin, App Overview, Manage Updates, और Manage Plan. मैंने Manage Updates पर क्लिक किया।
इससे एक modal खुला जिसमें pending update वाले हर plugin की सूची थी, मेरे मामले में चार, Breeze, Elementor, Object Cache Pro, और WP ULike, प्रत्येक current version और जिस version पर यह update होगा, के साथ checked item के रूप में दिखाया गया था।
सूची के नीचे दो radio options थे: Quick Update और Safe Update, प्रत्येक के साथ tradeoff का एक one-line description। मैंने Safe Update चुना और Proceed पर क्लिक किया।
एक single progress spinner के बजाय, अगला खुला हुआ modal real time में अपडेट होने वाली staged checklist दिखाता है।
Staging environment:
Production:
मैंने run को 6:21 pm पर शुरू किया और यह 6:27 pm पर समाप्त हुआ। छह मिनट, चार plugins के लिए, staging-then-production के complete cycle के साथ। modal खुद अपेक्षा सेट करता है कि यह “usually takes less than a minute,” जबकि मेरा run इससे बहुत अधिक समय तक चला।
stated estimate और actual समय के बीच यह अंतर, यदि आप maintenance window के दौरान plugins के batch पर Safe Update चला रहे हों, तो surprise होने के बजाय योजना बनाने के लायक है; seconds नहीं, minutes का budget रखें, खासकर जैसे-जैसे plugin counts बढ़ते हैं।
एक success notification ने परिणाम की पुष्टि की, और जैसे ही यह पूरा हुआ, account-level History tab ने इसे “On-Demand Successful: Plugins (4)” के रूप में लॉग किया, और पूरी detail तक एक link दिया।
उस loop का बंद होना, एक action को होते देखना और फिर तुरंत उसका एक permanent record point कर पाना, बिल्कुल वही तरह का client-facing proof है जिसकी agency को ज़रूरत होती है, और SafeUpdates ने कभी यह नहीं दिया था।
ये दोनों scheduling flow के भीतर हैं, on-demand update screen में नहीं, जिससे इन्हें आसानी से miss किया जा सकता है:
ये दोनों defaults मिलकर तय करते हैं कि unattended overnight update run आपको एक flagged plugin queue में रखकर जगाएगा, या एक ऐसे पूरे site के साथ जो mid-update में फँसा हो क्योंकि एक incompatible theme ने पूरे process को रोक दिया। किसी भी schedule को unattended चलाने पर भरोसा करने से पहले दोनों को जाँचना worth it है।
उसमें पहले दो दरवाज़े शामिल थे। यह section तीसरे दरवाज़े को कवर करता है: मानव को loop से बाहर कर देना। Auto Updates tab, जो उसी account-level Site Manager page से पहुँचा जाता है, वही जगह है जहाँ “manage many sites like they’re one” वाली pitch या तो सफल होती है या टूट जाती है। मेरे मामले में, यह सफल हुई।
इसे सेट करने का तरीका मैंने बिल्कुल इस तरह अपनाया। Integrations → Site Manager से, मैंने top row में Auto Updates tab पर क्लिक किया।
जब कुछ भी scheduled नहीं था, page ने एक empty state दिखाया, “No Auto Updates Schedule,” और एक ही button: Set Auto Update Schedule.
उस पर क्लिक करने से एक wizard खुला, “Set Auto Update Schedule,” जिसने एक ही pass में निम्नलिखित चरणों से मार्गदर्शन किया:
इसके बाद दूसरी screen खुली, “Create Auto Update Schedule,” जिसमें निम्न शामिल थे:
नीचे दिए गए Set AutoUpdate Schedule पर क्लिक करने से यह save हो गया, और step two में चुनी गई हर app पर लागू हो गया, हर site के लिए configuration दोहराने की ज़रूरत नहीं पड़ी।
तीन दरवाज़े और उनके पीछे की update mechanics कैसे काम करती हैं, यह हिस्सा how को कवर करता है। यह अंतिम feature proof को कवर करता है: क्या हुआ उसका एक permanent record, जो update process से अलग है।
इसे मैंने बिल्कुल इस तरह चालू किया।
उस app के अपने Site Manager Overview page से, वही page जिस पर आप Path 1 के माध्यम से subscribe करने के बाद पहुँचते हैं, performance ring के पास एक card “Activity Logs are Disabled” label के साथ बैठा है, एक छोटे description और एक single button: Enable Activity Logs.
मैंने उस पर क्लिक किया, और card तुरंत अपडेट हो गया, कोई confirmation modal नहीं, कोई अतिरिक्त कदम नहीं। उसके तुरंत बाद account-level Manage Applications table जाँचने पर, Integrations → Site Manager के तहत, उस app के लिए Activity Logs column पहले ही Disabled से Enabled में बदल चुका था, page को refresh करने की ज़रूरत नहीं पड़ी।
यह feature Pro के पीछे है, और यह उस सवाल का जवाब देने के लिए मौजूद है जो हर agency को अंततः किसी client से सुनना पड़ता है: किसने क्या बदला, और कब?
इसके बिना, वह जवाब आमतौर पर किसी WordPress logging plugin में रहता है जो site के अपने database में लिख रहा होता है, जो समय के साथ bloated हो जाता है और tampering से कोई सुरक्षा नहीं देता। उस record को WordPress installation के बाहर, hosting layer के भीतर live रखना, किसी भी client-facing चीज़ के लिए भरोसे का एक अर्थपूर्ण रूप से अलग स्तर है।
पूरे feature set, उसकी लागत, और उसके rough edges सब सामने रखने के बाद, आखिरी सवाल बस यही है कि क्या यह आपके विशिष्ट portfolio के लिए उपयुक्त है।
सबसे साफ़ fit है एक agency या freelance developer जो कई, आदर्श रूप से बहुत सारी, WordPress sites चला रहा हो जो पहले से पूरी तरह Cloudways के भीतर live हों, जहाँ एक broken update client trust के लिए वास्तविक लागत लेकर आता है, केवल निजी असुविधा नहीं।
Safe Update workflow और bulk scheduling खास तौर पर उस समस्या को हल करने के लिए मौजूद हैं जो तब सामने आती है जब हर site को अलग-अलग जाँचना अभी भी उचित हो उस सीमा से आप आगे निकल चुके हों।
यह mixed portfolio वाले किसी भी व्यक्ति के लिए आंशिक fit है। free Site Manager plugin बाहरी sites को basic monitoring और updates के लिए ला सकता है, लेकिन native dashboard को भुगतान करने लायक बनाने वाली features, staging-based Safe Update, visual regression, activity logs, तब तक पहुँच से बाहर रहती हैं जब तक वे sites वास्तव में Cloudways पर स्थानांतरित न हो जाएँ।
यह single-site owner के लिए बिल्कुल अनावश्यक है। free tier तकनीकी रूप से काम करेगा, लेकिन पूरा product portfolio-scale समस्या को हल करने के लिए मौजूद है, जो एक single site कभी पैदा नहीं करती।
हाँ, site manager अपनाने लायक है, एक शर्त पर: आपकी sites पहले से Cloudways पर live हों। उस सीमा के भीतर, Site Manager वह देता है जो यह वादा करता है, एक वास्तविक cross-app dashboard, एक Safe Update path जो production को छूने से पहले backup लेता है, और bulk scheduling जो updates को per-login chore के बजाय fleet-wide action की तरह मानता है।
उस सीमा के बाहर, यह एक हल्का tool है जिसके साथ स्पष्ट migration nudge जुड़ा हुआ है। सबसे उपयुक्त fit एक agency है जो client sites को Cloudways पर consolidate कर रही है और जिसे यह साबित करने के लिए एक जगह चाहिए कि क्या बदला और कब।
| प्लान का नाम | CPU | RAM | बैंडविड्थ | Warranty | कीमत | |
|---|---|---|---|---|---|---|
| 25GB | 1 core | 1 GB | 1 TB | ₹ 0 | ₹ 1,060 | विवरण देखें |
| 50GB | 1 core | 2 GB | 2 TB | ₹ 0 | ₹ 2,300 | विवरण देखें |
| 80GB | 2 cores | 4 GB | 4 TB | ₹ 0 | ₹ 4,410 | विवरण देखें |
| Description | Expert Review |
|---|---|
| गति, सुरक्षा, और परेशानी-रहित अपड... | Read Wordpress Hosting Review |
| लचीला, उच्च-प्रदर्शन क्लाउड होस�... | Read Cloud Hosting Review |
| व्यवसायिक संचार आवश्यकताओं के ल... | Read Email Hosting Review |
| तेज़ गति और बेहतर ई-कॉमर्स प्रदर�... | Read Magento Hosting Review |
| Read WooCommerce hosting Review | |
| Read VPS Hosting Review |
हाँ। Cloudways Site Manager एक मूल ऐड-ऑन है जो आपके Cloudways खाते में पहले से होस्ट किए गए WordPress अनुप्रयोगों के लिए अपडेट, प्रदर्शन निगरानी, और गतिविधि लॉग्स को केंद्रीकृत करता है। एक अलग, मुफ्त साथी प्लगइन कहीं भी होस्ट की गई WordPress साइटों के लिए हल्की निगरानी और अपडेट क्षमता प्रदान करता है।
इस समीक्षा में परीक्षण किए गए मूल डैशबोर्ड के माध्यम से नहीं, क्योंकि वह केवल Cloudways पर पहले से होस्ट किए गए एप्लिकेशनों तक सीमित है। Cloudways Site Manager नामक एक मुफ्त प्लगइन, जिसे WP Remote के साथ सह-विकसित किया गया है, बाहरी साइटों को कोर, प्लगइन और थीम मॉनिटरिंग तथा अपडेट के लिए ला सकता है, हालांकि इसमें Safe Update की स्टेजिंग क्लोन, विज़ुअल रिग्रेशन टेस्टिंग, या सर्वर-स्तरीय कैशिंग शामिल नहीं है।
Basic tier निःशुल्क है और इसमें site overview, user and plugin management, तथा Quick Updates शामिल हैं। Pro में Safe Updates, scheduling, performance monitoring, और activity logs शामिल हैं, जिसकी कीमत $3 प्रति app प्रति माह है, और पाँच या अधिक apps होने पर यह $2 हो जाती है, तथा Public Preview के दौरान वर्तमान में इसका उपयोग निःशुल्क है।
Quick Update कुछ ही सेकंड में बिना किसी बैकअप या संगतता जाँच के बदलाव सीधे प्रोडक्शन पर लागू करता है। Safe Update एक स्टेजिंग क्लोन बनाता है, संगतता की जाँच करता है, प्रत्येक पैकेज को अपडेट करता है, एक विज़ुअल रिग्रेशन टेस्ट चलाता है, और केवल तभी प्रोडक्शन पर पुश करता है जब वह टेस्ट पास हो जाता है।
हाँ। नए अनुप्रयोग कभी भी स्वतः नामांकित नहीं होते, भले ही उन्हें ऐसे सर्वर में जोड़ा जाए जिस पर पहले से अन्य Site Manager ऐप्स चल रहे हों। प्रत्येक साइट को अपना अलग onboarding चरण चाहिए, चाहे व्यक्तिगत रूप से हो या Integrations के अंतर्गत bulk wizard के माध्यम से।
कुछ आसान सवालों के जवाब दें और अपनी ज़रूरत के लिए सही समाधान पाएँ!
सही होस्टिंग खोजें
