VPS पर Cloudron कैसे इंस्टॉल करें: स्टेप-बाय-स्टेप गाइड

VPS पर Cloudron इंस्टॉल करना: संक्षिप्त संस्करण

VPS पर Cloudron इंस्टॉल करने के लिए आपको एक फ्रेश Ubuntu सर्वर, कम से कम 2 GB RAM, और एक ऐसा डोमेन चाहिए जिसके DNS रिकॉर्ड आप एडिट कर सकें। इंस्टॉलेशन प्रक्रिया में केवल तीन commands और एक reboot शामिल है। लगभग सभी समस्याएं इस चरण से पहले (गलत base image, गलत virtualisation type) या इसके बाद (DNS, mail, backups) आती हैं।

wget https://cloudron.io/cloudron-setup
chmod +x cloudron-setup
sudo ./cloudron-setup

Cloudron self-hosted apps के लिए TLS (transport layer security) certificates इंस्टॉल, अपडेट, बैकअप और जारी करता है। प्रत्येक app Docker में चलता है, nginx उन सभी के सामने स्थित होता है, और हर app को आपके डोमेन का अपना सबडोमेन मिलता है। यही कारण है कि यहाँ DNS का काम सबसे पहले किया जाता है।

Cloudron base OS को लेकर इतना सख्त क्यों है

Setup script किसी भी चीज़ को install करने से पहले सर्वर की जाँच करता है, और यदि कोई जाँच विफल होती है, तो आपको नया सर्वर लेना होगा। कोई भी image चुनने से पहले इन्हें पढ़ लें।

• केवल Ubuntu, और वह भी केवल तीन releases। कुछ और होने पर script Cloudron requires Ubuntu 20.04, 22.04, 24.04 के साथ exit हो जाती है। Debian, Rocky और Alpine समर्थित नहीं हैं। Ubuntu 24.04 के लिए Cloudron 8 या उससे नया वर्ज़न चाहिए, और script आपके लिए इसकी जाँच कर लेती है।
• केवल 64-bit Intel या AMD: Error: Cloudron only supports amd64/x86_64। ARM VPS पर यह नहीं चल सकता।
• केवल पूर्ण hardware virtualisation। Container-आधारित VPS पर script Error: Cloudron does not support lxc, only runs on bare metal or with full hardware virtualization के साथ रुक जाती है, क्योंकि यह systemd-detect-virt --container के साथ container का पता लगा लेती है। KVM ठीक है। OpenVZ और LXC समर्थित नहीं हैं।
• Root filesystem का ext4 या xfs होना अनिवार्य है। किसी और चीज़ पर आपको Error: Cloudron requires '/' to be ext4 or xfs मिलता है, इसी कारण btrfs और zfs images विफल हो जाती हैं।
• कम से कम 941 MB RAM और / पर 20 GB जगह, जिसे free -m और root filesystem के आकार से मापा जाता है।
• पूरी तरह से नया सर्वर। यदि nginx, docker या node पहले से install हैं, तो script Error: Some packages like nginx/docker/nodejs are already installed. के साथ मना कर देती है।

यह आखिरी जाँच वह है जिस पर लोग बहस करते हैं, इसलिए इसके पीछे का कारण यहाँ दिया गया है। Cloudron Docker, nginx, Node.js और MySQL के विशिष्ट (pinned) versions install करता है, हर host की गई app के लिए nginx configuration लिखता है, और iptables firewall rules को खुद manage करता है। आपके द्वारा कल install किया गया Docker गलत version का हो सकता है, और आपकी मौजूदा nginx site files replace हो जाएँगी। Cloudron पूरी मशीन का नियंत्रण लेता है, इसलिए इसे एक समर्पित VPS दें।

एक और जाँच है जिसे नज़रअंदाज़ करना आसान है। बिना AVX (advanced vector extensions) वाले पुराने CPU पर script CPU has no AVX support. MongoDB will be disabled print करती है, और MongoDB की आवश्यकता वाली हर app uninstallable हो जाती है। commit करने से पहले grep -m1 -o avx /proc/cpuinfo के साथ CPU की जाँच करें, जो सक्षम host पर avx print करता है और पुराने host पर कुछ भी नहीं।

Cloudron को कितनी RAM की आवश्यकता होती है?

स्क्रिप्ट 941 MB से कम RAM होने पर चलने से मना कर देती है, जिसका कारण Error: Cloudron requires atleast 1GB physical memory है, और डॉक्यूमेंटेशन में 2 GB RAM तथा 20 GB डिस्क की आवश्यकता बताई गई है। ये दोनों संख्याएँ प्लेटफॉर्म के लिए न्यूनतम सीमा हैं, न कि प्लेटफॉर्म और आपके ऐप्स के कुल योग के लिए। एक भी ऐप इंस्टॉल करने से पहले, Cloudron पहले से ही Docker, nginx, अपनी स्वयं की box सर्विस, ऐप्स को दी जाने वाली डेटाबेस कंटेनर (MySQL, PostgreSQL, MongoDB), Redis और मेल स्टैक चला रहा होता है। एक फ्रेश इंस्टॉलेशन पर docker ps चलाएँ और उन्हें गिनें।

ऐप मेमोरी लिमिट इस आधार के ऊपर होती है। प्रत्येक ऐप पैकेज एक कम डिफ़ॉल्ट लिमिट के साथ आता है और आप ऐप के Resources व्यू में स्लाइडर का उपयोग करके इसे बढ़ा सकते हैं। जब कोई ऐप अपनी लिमिट पार करता है, तो वह रीस्टार्ट हो जाता है और आपको एक OOM (आउट ऑफ मेमोरी) नोटिफिकेशन भेजता है। इसलिए, यदि कोई बॉक्स बार-बार एक ही ऐप को रीस्टार्ट कर रहा है, तो यह आमतौर पर बग के बजाय लिमिट की समस्या होती है।

यहाँ वह साइजिंग है जिसका मैं सुझाव दूँगा। ये ऐसे सर्वर के लिए सिफारिशें हैं जिसे आपको अगले महीने फिर से बनाने की आवश्यकता नहीं पड़ेगी। ये मापे गए बेंचमार्क परिणाम नहीं हैं।

[
  {
    "label": "2 apps (free tier)",
    "vcpu": 2,
    "ram_gb": 4,
    "disk_gb": 60
  },
  {
    "label": "5 apps",
    "vcpu": 4,
    "ram_gb": 8,
    "disk_gb": 120
  },
  {
    "label": "10 apps",
    "vcpu": 6,
    "ram_gb": 16,
    "disk_gb": 240
  }
]

दो ऐप्स 4 GB RAM और 60 GB डिस्क पर आराम से चलते हैं। लगभग दस ऐप्स के लिए 16 GB RAM और 240 GB डिस्क की आवश्यकता होती है, क्योंकि प्लेटफॉर्म का आधार कभी छोटा नहीं होता और प्रत्येक ऐप एक Docker इमेज, एक डेटाबेस और अपना डेटा जोड़ता है। डिस्क लोगों की अपेक्षा से अधिक तेजी से भरती है: जब तक आप बैकअप को बॉक्स से बाहर नहीं ले जाते, तब तक इमेज, ऐप डेटा और लोकल बैकअप एक ही वॉल्यूम साझा करते हैं।

Cloudron हर ऐप को असीमित स्वैप (swap) देता है, इसलिए आपके द्वारा सेट की गई मेमोरी लिमिट केवल RAM पर लागू होती है। बिना स्वैप फाइल वाली VPS इमेज पर, swapon --show कुछ भी प्रिंट नहीं करता है, और मेमोरी का दबाव धीमे ऐप के बजाय सीधे OOM रीस्टार्ट में बदल जाता है। 2 GB स्वैप जोड़ना एक सस्ता बीमा है, हालाँकि यह वास्तविक मेमोरी की जगह नहीं ले सकता। VPS प्लान के बीच का अंतर उन घंटों की तुलना में बहुत कम है जो आप लिमिट को ट्यून करने में बिताएंगे, इसलिए VPS की वास्तविक लागत क्या है देखें और उससे अगला बड़ा साइज खरीदें।

DNS: वह वाइल्डकार्ड रिकॉर्ड जो ऐप सबडोमेन को काम करने योग्य बनाता है

Cloudron डैशबोर्ड को my.example.com पर रखता है और प्रत्येक ऐप को उसके अपने सबडोमेन पर, इसलिए DNS बाद का चरण होने के बजाय एक पूर्व-आवश्यकता है। पहली बार डैशबोर्ड खोलने से पहले इन रिकॉर्ड्स को सर्वर के पब्लिक IP एड्रेस पर पॉइंट करें:

• my.example.com को A रिकॉर्ड के रूप में। यह डैशबोर्ड है।
• *.example.com को A रिकॉर्ड के रूप में। यह वह रिकॉर्ड है जो ऐप सबडोमेन को काम करने योग्य बनाता है, ताकि जैसे ही आप उन ऐप्स को इंस्टॉल करें, wiki.example.com और git.example.com रिजॉल्व हो सकें।
• example.com को A रिकॉर्ड के रूप में, केवल तभी यदि आप बेयर डोमेन (bare domain) पर कोई ऐप चाहते हैं।

वाइल्डकार्ड रिकॉर्ड की प्राथमिकता स्पष्ट (explicit) रिकॉर्ड से कम होती है, इसलिए कहीं और पॉइंट करने वाला मौजूदा www.example.com काम करना जारी रखेगा।

सेटअप के दौरान आप चुनते हैं कि Cloudron उसके बाद DNS को कैसे हैंडल करेगा:

• API प्रदाता। Cloudron Cloudflare, DigitalOcean, Route53, Hetzner, Porkbun, Linode, deSEC, Gandi, Namecheap और लगभग बीस अन्य के लिए एक टोकन स्टोर करता है, और फिर मेल रिकॉर्ड्स सहित हर रिकॉर्ड को खुद लिखता है।
• वाइल्डकार्ड। आप * रिकॉर्ड को मैन्युअल रूप से जोड़ते हैं और Cloudron कुछ भी नहीं लिखता है।
• मैन्युअल। Cloudron आपको प्रत्येक रिकॉर्ड दिखाता है और हर एक ऐप इंस्टॉल करने से पहले आपके उसे जोड़ने का इंतज़ार करता है।

एक वाइल्डकार्ड DNS रिकॉर्ड वाइल्डकार्ड सर्टिफिकेट नहीं होता है। डिफ़ॉल्ट सर्टिफिकेट प्रदाता Let's Encrypt Prod - Wildcard है, जो DNS के माध्यम से स्वामित्व सिद्ध करता है, इसलिए यह केवल API प्रदाता के साथ काम करता है। वाइल्डकार्ड या मैन्युअल बैकएंड पर आप प्रति ऐप एक सर्टिफिकेट पर वापस आ जाते हैं जिसे HTTP के माध्यम से वैलिडेट किया जाता है, जिसका अर्थ है कि इनबाउंड पोर्ट 80 को हमेशा खुला रहना होगा। यदि आपका रजिस्ट्रार या DNS होस्ट API सूची में है, तो उसका उपयोग करें: मेल रिकॉर्ड्स और सर्टिफिकेट दोनों का प्रबंधन आपकी जिम्मेदारी नहीं रह जाएगी।

आगे बढ़ने से पहले सत्यापित करें। dig +short my.example.com और dig +short anything.example.com दोनों को आपके सर्वर का IP एड्रेस प्रिंट करना चाहिए। यदि वाइल्डकार्ड क्वेरी कुछ भी प्रिंट नहीं करती है, तो डैशबोर्ड तो ठीक से काम करेगा लेकिन ऐप्स बाद में विफल हो जाएंगे।

यदि डोमेन Cloudflare के पीछे है, तो रिकॉर्ड्स को DNS only पर सेट करें। प्रॉक्सी केवल HTTP और HTTPS को फॉरवर्ड करता है, इसलिए मेल पोर्ट्स काम करना बंद कर देते हैं, और प्रत्येक ऐप को विज़िटर के एड्रेस के बजाय Cloudflare का एड्रेस दिखाई देता है।

Setup script चलाएं

wget https://cloudron.io/cloudron-setup
chmod +x cloudron-setup
sudo ./cloudron-setup

इसे root के रूप में या sudo के माध्यम से चलाएं, क्योंकि अन्यथा यह सबसे पहले This script should be run as root. प्रिंट करता है। इंस्टॉलेशन में कई मिनट लगते हैं और यह काम करते समय शांत रहता है, क्योंकि apt आउटपुट और Docker pulls एक लॉग फ़ाइल में जाते हैं। इसे दूसरे SSH सेशन से मॉनिटर करें:

tail -f /var/log/cloudron-setup.log

अंत में यह After reboot, visit one of the following URLs and accept the self-signed certificate to finish setup. और उसके बाद आपके सर्वर का पता प्रिंट करता है, फिर The server has to be rebooted to apply all the settings. Reboot now ? [Y/n] पूछता है। yes उत्तर दें। यदि आपको रीस्टार्ट शेड्यूल करने की आवश्यकता है तो --skip-reboot फ्लैग उपलब्ध है, लेकिन Cloudron तब तक उपयोग करने योग्य नहीं है जब तक कि बॉक्स वापस चालू न हो जाए।

प्रथम बूट: डोमेन, DNS बैकएंड और एडमिन अकाउंट

https://<server-ip> खोलें और ब्राउज़र चेतावनी को स्वीकार करें। सर्टिफिकेट self-signed है क्योंकि Cloudron अभी तक आपके डोमेन को नहीं जानता है, इसलिए इसके पास सर्टिफिकेट अथॉरिटी से अनुरोध करने के लिए कुछ नहीं है। Chrome में Advanced पर क्लिक करें, फिर Proceed to <ip> (unsafe) पर क्लिक करें। Firefox में Advanced पर क्लिक करें, फिर Accept the Risk and Continue पर क्लिक करें।

पहली स्क्रीन आपसे आपका डोमेन मांगती है। example.com दर्ज करें और डैशबोर्ड my.example.com पर सेट हो जाएगा। आप इसके बजाय cloudron.example.com जैसे सबडोमेन का उपयोग कर सकते हैं, और तब डैशबोर्ड my.cloudron.example.com पर होगा। DNS बैकएंड चुनें, यदि आपके पास API टोकन है तो उसे पेस्ट करें, और एक ऐसे ईमेल पते के साथ एडमिन अकाउंट बनाएं जिसे आप वास्तव में पढ़ते हैं: Let's Encrypt रजिस्ट्रेशन और हर प्लेटफॉर्म अलर्ट इसी का उपयोग करता है।

जब आप सेव करते हैं, तो Cloudron सर्टिफिकेट का अनुरोध करता है और डैशबोर्ड को https://my.example.com पर ले जाता है। IP एड्रेस वाला URL उस बिंदु पर काम करना बंद कर देता है, इसलिए नए URL को बुकमार्क कर लें।

Certificates: क्या renew होता है और यह कब रुकता है

Certificate का renewal स्वचालित होता है और यह ACME Renewal Information (ARI) का पालन करता है। यह वह schedule है जिसे certificate authority प्रकाशित करती है, जो व्यवहार में expiry से लगभग एक महीने पहले renew हो जाता है। यदि renewal विफल हो जाता है, तो admin account पर एक email भेजा जाता है और expired certificate वापस built-in self-signed certificate पर चला जाता है। browser में दिखने वाली warning का यही अर्थ है कि जो site कल तक काम कर रही थी, वह अब सुरक्षित नहीं है।

इसके अधिकांश मामलों के पीछे दो कारण होते हैं। HTTP validation के लिए inbound port 80 की आवश्यकता होती है, इसलिए "सब कुछ वैसे भी HTTPS है" सोचकर port 80 को बंद कर देने से Wildcard या Manual DNS backend पर चल रहे हर app का renewal टूट जाता है। DNS validation के लिए एक ऐसे API token की आवश्यकता होती है जिसके पास write access हो, इसलिए उस token को rotate करने या उसकी अनुमतियों को सीमित करने से renewal चुपचाप विफल हो जाता है, जिसका पता केवल warning email आने पर ही चलता है।

Domains view में तुरंत प्रयास करने के लिए एक Renew All button होता है, और परीक्षण के लिए Let's Encrypt Staging provider उपलब्ध है। Staging certificates को जानबूझकर browsers द्वारा untrusted रखा जाता है, और यही इसका उद्देश्य है: आप production rate limit को खर्च किए बिना जितनी बार चाहें उतनी बार retry कर सकते हैं।

क्या आपको इन-बिल्ट मेल सर्वर का उपयोग करना चाहिए?

Cloudron में IMAP मेलबॉक्स, सबमिशन, sieve फिल्टर्स और DKIM (domainkeys identified mail) साइनिंग के साथ एक पूर्ण मेल स्टैक मिलता है। आप इसे डैशबोर्ड में Email के अंतर्गत प्रत्येक डोमेन के लिए सक्षम कर सकते हैं। मेल डिलीवर करना सबसे कठिन हिस्सा है, और इसमें आने वाली कठिनाइयों का Cloudron से कोई संबंध नहीं है।

• स्पैम नियंत्रण के लिए अधिकांश VPS प्रदाता आउटबाउंड पोर्ट 25 को ब्लॉक रखते हैं। कुछ प्रदाता सपोर्ट टिकट के बाद इसे अनब्लॉक कर देते हैं। सर्वर से nc -zv aspmx.l.google.com 25 के साथ परीक्षण करें (यदि कमांड मौजूद नहीं है तो netcat-openbsd इंस्टॉल करें)। खुले पोर्ट succeeded रिपोर्ट करते हैं, और एक ब्लॉक पोर्ट टाइम आउट होने तक हैंग रहता है।
• PTR रिकॉर्ड (रिवर्स DNS) आपके VPS प्रदाता द्वारा सेट किया जाता है, न कि आपके DNS होस्ट द्वारा, और इसे मेल होस्टनेम से मेल खाना चाहिए। सामान्य PTR वाले पते से भेजे गए मेल स्पैम फोल्डर में चले जाते हैं।
• SPF, DKIM और DMARC रिकॉर्ड आपके लिए API DNS बैकएंड पर लिखे जाते हैं। Wildcard या Manual बैकएंड पर आपको इन्हें मैन्युअल रूप से जोड़ना होगा, और एक गायब DKIM रिकॉर्ड का मतलब है कि आपके द्वारा साइन किया गया प्रत्येक संदेश सत्यापित नहीं किया जा सकेगा।

अधिकांश लोगों के लिए जो सेटअप काम करता है, वह Cloudron पर मेल प्राप्त करना और Email व्यू में कॉन्फ़िगर किए गए SendGrid, Postmark, Mailgun या Amazon SES जैसे रिले के माध्यम से भेजना है। रिले को आपके डोमेन पर किसी भी पते से भेजने की अनुमति देनी चाहिए, अन्यथा विभिन्न प्रेषकों से आने वाली ऐप सूचनाएं अस्वीकार कर दी जाएंगी। यदि मेल ही सर्वर खरीदने का मुख्य कारण है, तो Mailcow जैसे समर्पित मेल सर्वर को उसकी अपनी IP प्रतिष्ठा के साथ अलग बॉक्स पर चलाएं।

यदि आप बिल्कुल भी Cloudron Email का उपयोग नहीं करते हैं, तो अपने प्रदाता के फायरवॉल में पोर्ट 25, 465, 587, 993 और 4190 को ब्लॉक कर दें। इसे सर्वर पर नहीं, बल्कि वहां करें, क्योंकि Cloudron स्वयं iptables नियम लिखता है और उन पर अपना नियंत्रण बनाए रखना चाहता है। यह एक साधारण VPS के विपरीत है, जहां आप स्वयं ufw नियमों का प्रबंधन करते हैं।

जरूरत पड़ने से पहले बैकअप टारगेट को कॉन्फ़िगर करें

बैकअप डिफ़ॉल्ट रूप से स्थानीय फाइलसिस्टम पर /var/backups में स्टोर होते हैं, जो अन्य सभी डेटा के समान डिस्क पर होता है। दस्तावेज़ इस बारे में स्पष्ट हैं: "प्लेटफ़ॉर्म सर्वर के समान भौतिक डिस्क पर बैकअप रखना खतरनाक है।" एक डिस्क फेल होने पर ऐप्स और बैकअप दोनों नष्ट हो जाते हैं।

Backups खोलें, फिर Backup Sites पर जाएं, और पहले दिन ही इसे किसी अन्य स्थान पर सेट करें। S3-compatible ऑब्जेक्ट स्टोरेज इसके लिए सामान्य विकल्प है (Backblaze B2, Wasabi, Cloudflare R2, DigitalOcean Spaces, या दूसरे सर्वर पर एक MinIO bucket), और इसके अलावा SSHFS, NFS, CIFS और साधारण फाइलसिस्टम टारगेट भी समर्थित हैं।

तीन सेटिंग्स यह तय करती हैं कि बैकअप उपयोगी है या नहीं:

• Format. tgz प्रत्येक ऐप के लिए एक कंप्रेस्ड आर्काइव बनाता है और हर बार पूरी फाइल फिर से अपलोड करता है। rsync केवल बदली हुई फाइलों को अपलोड करता है, जो बड़े Nextcloud के लिए काफी सस्ता पड़ता है, लेकिन इसके बदले स्टोरेज API पर अधिक रिक्वेस्ट करनी पड़ती हैं।
• Encryption. वैकल्पिक AES-256 जो फाइल कंटेंट और फाइलनाम दोनों को कवर करता है। Cloudron पासवर्ड की कॉपी नहीं रखता है, इसलिए इसे खोने का मतलब है कि बैकअप को कोई भी डिक्रिप्ट नहीं कर पाएगा, आप भी नहीं। सेव करने से पहले इसे एक सेल्फ-होस्टेड पासवर्ड मैनेजर में स्टोर करें।
• Retention. इसे 7 दैनिक और 4 साप्ताहिक जैसी संख्या के रूप में लिखा जाता है। ऑब्जेक्ट स्टोरेज पर लंबी रिटेंशन के लिए हर महीने बिल आता है, इसलिए ऐसी संख्या चुनें जिसका भुगतान आप करने के लिए तैयार हों।

इसके बाद रिस्टोर का परीक्षण करें। एक छोटा ऐप इंस्टॉल करें, उसे डैशबोर्ड से रिस्टोर करें, और देखें कि वह अपने डेटा के साथ वापस आता है या नहीं। जिस बैकअप को कभी रिस्टोर करके नहीं देखा गया, वह केवल एक अनुमान है।

फ्री टियर की सीमाएं क्या हैं

अगस्त 2026 तक, फ्री प्लान में अधिकतम दो installed apps की सीमा है। बाकी सभी सुविधाएं इसके साथ मिलती हैं: app updates, प्रति-app backups, firewall, mail server और single sign-on। तीसरी app के लिए आपको licence की आवश्यकता होती है। पेड प्लान में app की सीमा हटा दी जाती है, और उच्च प्लान में user groups और roles, एक directory server तथा कई backup sites की सुविधा मिलती है। कीमतें बदलती रहती हैं, इसलिए किसी ट्यूटोरियल में दी गई संख्या के बजाय Cloudron pricing page देखें।

एक licence एक Cloudron install को कवर करता है, इसलिए दो छोटे सर्वर की लागत एक बड़े सर्वर की तुलना में दोगुनी होती है। यह मूल्य निर्धारण अधिकांश लोगों को एक ही बड़े VPS का उपयोग करने के लिए प्रेरित करता है, जो सेवाओं को अलग-अलग मशीनों पर फैलाने की सामान्य सलाह के विपरीत है। इस बात को ध्यान में रखते हुए सर्वर का आकार चुनें, क्योंकि बाद में सेवाओं को अलग करने का मतलब है दो बार भुगतान करना।

जब कुछ खराब हो जाए

सबसे पहले इन-बिल्ट चेक का उपयोग करें। यह DNS, certificates, disk, memory और प्रत्येक service की बारी-बारी से जाँच करता है और आपको बताता है कि कौन सा परीक्षण विफल रहा:

sudo cloudron-support --troubleshoot

इसके बाद, सामान्य systemd (system and service manager) टूल्स का उपयोग करें। systemctl status box स्वयं Cloudron service की स्थिति बताता है, journalctl -u box -n 100 इसके हालिया logs देता है, और journalctl -u docker इसके नीचे चल रहे container runtime को कवर करता है। इंस्टॉलेशन के दौरान जो कुछ भी गलत हुआ, वह /var/log/cloudron-setup.log में रहता है।

यदि dashboard लोड नहीं हो रहा है, तो यह आमतौर पर Cloudron के बजाय DNS या provider firewall की समस्या होती है। अपने लैपटॉप से dig +short my.example.com चलाएं और पुष्टि करें कि provider के network firewall में port 80 और 443 खुले हैं, जो सर्वर के अपने नियमों से अलग एक नियंत्रण है। यदि आप फिर से शुरुआत कर रहे हैं, तो script Error: Cloudron is already installed. To reinstall, start afresh के साथ दूसरी बार चलने से मना कर देगी, और एक नया सर्वर बनाना ही इसका सही समाधान है।

जब Cloudron सही विकल्प न हो

Cloudron तब उपयुक्त है जब आप infrastructure के बजाय applications चाहते हैं। यदि आप अपने containers को अपने तरीके से चलाना चाहते हैं, तो यह सही विकल्प नहीं है, क्योंकि यह nginx, Docker और firewall को नियंत्रित करता है और आपके द्वारा किए गए बदलावों को overwrite कर देगा। यदि आपकी योजना compose files के एक फोल्डर का उपयोग करने की है, तो Traefik in front of your own Docker Compose stacks आपको बिना किसी अतिरिक्त platform के वही automatic TLS और subdomain routing प्रदान करता है। यदि आपने अभी तक चुनाव नहीं किया है, तो Cloudron, CasaOS and Coolify compared इन तीनों की तुलना करता है, और the wider list of what to self-host किसी install guide से शुरुआत करने के बजाय एक बेहतर विकल्प है।

FAQ

Cloudron को VPS पर कितनी RAM की आवश्यकता होती है?

Setup script 941 MB से कम RAM होने पर चलने से मना कर देता है और documentation में 2 GB की मांग की गई है, लेकिन यह बिना किसी app वाली platform की न्यूनतम आवश्यकता है। Cloudron पहले boot से ही Docker, nginx, अपनी स्वयं की box service, database containers और mail stack चलाता है। दो apps के लिए 4 GB और लगभग दस apps के लिए 16 GB का बजट रखें, और एक swap file जरूर जोड़ें, क्योंकि Cloudron apps को असीमित swap देता है और बिना swap वाली machine पर memory pressure आने पर apps restart होने लगते हैं।

क्या मैं Cloudron को Debian पर, या ऐसे सर्वर पर install कर सकता हूँ जहाँ पहले से Docker चल रहा हो?

दोनों ही स्थितियों में यह काम नहीं करेगा। Script release की जाँच करती है और Cloudron requires Ubuntu 20.04, 22.04, 24.04 के साथ रुक जाती है, इसलिए Debian, Rocky और Alpine समर्थित नहीं हैं। यदि nginx, docker या node पहले से मौजूद हों, तो भी script रुक जाती है, क्योंकि यह उन सभी के pinned versions install करती है और nginx configuration तथा iptables rules को स्वयं लिखती है। हमेशा KVM VPS पर एक ताज़ा Ubuntu image से शुरुआत करें।

मेरे app subdomains क्यों काम नहीं करते जबकि dashboard काम कर रहा है?

Wildcard DNS record गायब है। Setup my.example.com के लिए एक A record बनाता है या उसकी मांग करता है, इसलिए dashboard resolve हो जाता है, जबकि wiki.example.com NXDOMAIN देता है और browser रिपोर्ट करता है कि site नहीं मिल रही है। सर्वर IP की ओर इशारा करते हुए *.example.com के लिए एक A record जोड़ें, फिर app install करने से पहले dig +short wiki.example.com के साथ पुष्टि करें।

क्या मुझे Cloudron mail server का उपयोग करना अनिवार्य है?

नहीं। आप incoming email को बंद रख सकते हैं और Postmark, Mailgun या Amazon SES जैसे external relay के माध्यम से email भेज सकते हैं। यदि आपका provider outbound port 25 को block करता है या IP address की mail reputation नहीं है, तो यह एक सुरक्षित विकल्प है। यदि आप Cloudron Email को पूरी तरह से छोड़ देते हैं, तो सर्वर के बजाय provider firewall पर ports 25, 465, 587, 993 और 4190 को बंद कर दें।

free plan पर दो-app की सीमा तक पहुँचने पर क्या होता है?

Dashboard तीसरे install को रोक देता है और licence key मांगता है। जो apps आप पहले से चला रहे हैं, वे प्रभावित नहीं होते: वे update होते रहते हैं, उनका backup लिया जाता रहता है और उनके certificates भी बने रहते हैं। Licence जोड़ने से बिना कुछ reinstall किए सीमा हट जाती है, इसलिए free plan एक वास्तविक domain पर platform का परीक्षण करने का एक उचित तरीका है।