Ubuntu VPS वर Cloudron कसे इन्स्टॉल करावे?

VPS वर Cloudron इन्स्टॉल करणे: थोडक्यात माहिती

VPS वर Cloudron इन्स्टॉल करण्यासाठी तुम्हाला एक नवीन Ubuntu सर्व्हर, किमान 2 GB RAM आणि ज्याचे DNS रेकॉर्ड तुम्ही बदलू शकता असे एक डोमेन आवश्यक आहे. इन्स्टॉलेशनची प्रक्रिया तीन कमांड्स आणि एका रीबूटमध्ये पूर्ण होते. या प्रक्रियेत येणाऱ्या बहुतेक त्रुटी या पायरीच्या आधी (चुकीची बेस इमेज, चुकीचा व्हर्च्युअलायझेशन प्रकार) किंवा नंतर (DNS, मेल, बॅकअप) उद्भवतात.

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

Cloudron स्वतः होस्ट केलेल्या ॲप्ससाठी इन्स्टॉलेशन, अपडेट्स, बॅकअप आणि TLS (transport layer security) प्रमाणपत्रे जारी करण्याचे काम करते. प्रत्येक ॲप Docker मध्ये चालते, nginx सर्व ॲप्सच्या समोर (front) असते आणि प्रत्येक ॲपला तुमच्या डोमेनचे स्वतःचे सबडोमेन मिळते. या शेवटच्या गोष्टीमुळेच DNS चे काम येथे सर्वात आधी करावे लागते.

Cloudron बेस OS बाबत कडक अटी का लागू करते

Setup script कोणतेही सॉफ्टवेअर install करण्यापूर्वी server तपासतो. एखादी तपासणी अयशस्वी झाल्यास नवीन server घ्यावा लागतो. Image निवडण्यापूर्वी या अटी वाचा.

• फक्त Ubuntu आणि त्यातील फक्त तीन releases समर्थित आहेत. इतर कोणतीही आवृत्ती आढळल्यास Cloudron requires Ubuntu 22.04, 24.04, 26.04 सह script बंद होतो. Ubuntu 20.04 नाकारले जाते आणि install documentation मध्ये आता नवीन Ubuntu 26.04 server मागितला आहे. 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 असणे आवश्यक आहे. इतर filesystem वापरल्यास Error: Cloudron requires '/' to be ext4 or xfs मिळते. btrfs आणि zfs image साठी तपासणी अशाच प्रकारे अयशस्वी होते.
• free -m वापरून मोजलेली किमान 941 MB RAM आवश्यक आहे. तसेच / वर root filesystem ची size किमान 18 GB असावी. Error message मध्ये 20GB आवश्यक असल्याचे सांगितले जाते, परंतु तपासणीमध्ये 19 GB root filesystem पुरेसे ठरते.
• Server खरोखर नवीन असावा. nginx, docker किंवा node यांपैकी काही आधीच install असल्यास script Error: Some packages like nginx/docker/nodejs are already installed. सह installation नाकारतो.

शेवटच्या तपासणीबाबत सर्वाधिक चर्चा होते. तिचे कारण पुढीलप्रमाणे आहे. Cloudron Docker, nginx, Node.js आणि MySQL यांच्या ठरावीक versions install करतो. तो host केलेल्या प्रत्येक app साठी nginx configuration लिहितो आणि iptables firewall rules स्वतः व्यवस्थापित करतो. तुम्ही काल install केलेला Docker चुकीच्या version चा असू शकतो. त्यामुळे script कोणताही बदल न करता बंद होतो आणि नवीन Ubuntu install पासून सुरुवात करण्यास सांगतो. Cloudron संपूर्ण machine व्यवस्थापित करतो. त्यामुळे त्यासाठी स्वतंत्र VPS वापरा.

आणखी एक तपासणी सहज दुर्लक्षित होते. AVX (advanced vector extensions) नसलेल्या जुन्या CPU वर script CPU has no AVX support. MongoDB will be disabled दाखवतो. त्यानंतर MongoDB आवश्यक असलेले प्रत्येक app install करता येत नाही. Server घेण्यापूर्वी grep -m1 -o avx /proc/cpuinfo वापरून CPU तपासा. सक्षम host वर ते avx दाखवते. जुन्या CPU वर काहीही output देत नाही.

Cloudron साठी किती RAM आवश्यक आहे?

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

अॅपच्या मेमरी मर्यादा या मूळ गरजांच्या वर असतात. प्रत्येक अॅप पॅकेजमध्ये एक कमी डीफॉल्ट मर्यादा असते, जी तुम्ही अॅपच्या Resources व्ह्यूमधील स्लाइडरद्वारे वाढवू शकता. जेव्हा एखादे अॅप आपली मर्यादा ओलांडते, तेव्हा ते रीस्टार्ट होते आणि तुम्हाला OOM (out of memory) नोटिफिकेशन पाठवते. त्यामुळे, जर एखादे अॅप वारंवार रीस्टार्ट होत असेल, तर ती सहसा बग नसून मर्यादेची समस्या असते.

येथे मी सुचवलेले आकारमान दिले आहे. हे अशा सर्व्हरसाठी शिफारसी आहेत जो तुम्हाला पुढच्या महिन्यात पुन्हा तयार करावा लागणार नाही. हे मोजलेले बेंचमार्क निकाल नाहीत.

[
  {
    "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 इमेजमध्ये swap फाईल नसते, तिथे swapon --show काहीही दाखवत नाही आणि मेमरीचा ताण वाढल्यास अॅप हळू चालण्याऐवजी थेट OOM मुळे रीस्टार्ट होते. 2 GB swap जोडणे हा एक स्वस्त उपाय आहे, जरी तो प्रत्यक्ष मेमरीची जागा घेऊ शकत नाही. मर्यादेचे ट्युनिंग करण्यात घालवलेल्या तासांच्या तुलनेत विविध VPS प्लॅन्स मधील किमतीतील फरक खूप कमी आहे, म्हणून VPS चा प्रत्यक्ष खर्च तपासा आणि त्यापुढील क्षमतेचा प्लॅन निवडा.

DNS: app subdomains कार्यान्वित करणारा wildcard record

Cloudron dashboard my.example.com वर ठेवतो आणि प्रत्येक app स्वतःच्या subdomain वर चालवतो. त्यामुळे DNS ही नंतरची पायरी नसून पूर्वअट आहे. पहिल्यांदा dashboard उघडण्यापूर्वी हे records server च्या public IP address कडे निर्देशित करा:

• my.example.com हा A record म्हणून. हा dashboard आहे.
• *.example.com हा A record म्हणून. app subdomains कार्यान्वित करणारा हा record आहे. त्यामुळे ते apps install करताच wiki.example.com आणि git.example.com resolve होतील.
• example.com हा A record म्हणून, फक्त bare domain वर app हवा असल्यास.

Wildcard record ला explicit record पेक्षा कमी precedence असते. त्यामुळे वेगळ्या ठिकाणी निर्देश करणारा विद्यमान www.example.com कार्यरत राहतो.

यानंतर Cloudron ने DNS कसे हाताळायचे ते setup दरम्यान निवडा:

• API provider. Cloudron Cloudflare, DigitalOcean, Route53, Hetzner, Porkbun, Linode, deSEC, Gandi, Namecheap आणि आणखी सुमारे दहा providers साठी token साठवतो. त्यानंतर mail records सहित प्रत्येक record Cloudron स्वतः लिहितो.
• Wildcard. तुम्ही * record manually जोडता आणि Cloudron काहीही लिहित नाही.
• Manual. प्रत्येक app install करण्यापूर्वी Cloudron प्रत्येक record दाखवतो आणि तुम्ही तो जोडत असताना प्रतीक्षा करतो.

Wildcard DNS record हा wildcard certificate नसतो. Default certificate provider Let's Encrypt Prod - Wildcard आहे. तो DNS द्वारे domain ownership पडताळतो, त्यामुळे तो फक्त API provider सोबत कार्य करतो. Wildcard किंवा Manual backend वापरताना HTTP द्वारे validation केलेले प्रत्येक app साठी स्वतंत्र certificate वापरले जाते. त्यामुळे inbound port 80 कायम open ठेवावा लागतो. तुमचा registrar किंवा DNS host API list मध्ये असल्यास तो वापरा. Mail records आणि certificates या दोन्हींची जबाबदारी Cloudron कडे जाते.

पुढे जाण्यापूर्वी पडताळणी करा. dig +short my.example.com आणि dig +short anything.example.com या दोन्ही commands ने तुमच्या server चा IP address दाखवला पाहिजे. Wildcard query ने काहीही दाखवले नाही, तर dashboard व्यवस्थित कार्यरत असतानाही पुढे apps fail होतील.

Domain Cloudflare मागे असल्यास records DNS only वर सेट करा. Proxy फक्त HTTP आणि HTTPS forward करतो. त्यामुळे mail ports कार्यरत राहत नाहीत आणि प्रत्येक app ला visitor च्या address ऐवजी Cloudflare चा address दिसतो.

सेटअप स्क्रिप्ट चालवा

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

ही स्क्रिप्ट root वापरकर्त्याद्वारे किंवा sudo वापरून चालवा, कारण अन्यथा ती सुरुवातीलाच This script should be run as root. हा संदेश दाखवते. इन्स्टॉलेशन पूर्ण होण्यासाठी काही मिनिटे लागतात आणि ही प्रक्रिया शांतपणे पार पडते, कारण apt चे आउटपुट आणि Docker चे पुलिंग एका लॉग फाइलमध्ये जतन केले जातात. दुसऱ्या 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 ला अद्याप तुमच्या डोमेनची माहिती नाही, त्यामुळे ते प्रमाणपत्र प्राधिकरणाकडे (certificate authority) कशाचीही मागणी करू शकत नाही. 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 बुकमार्क करून ठेवा.

प्रमाणपत्रे: काय नूतनीकरण होते आणि ते कधी थांबते

प्रमाणपत्राचे नूतनीकरण स्वयंचलित असते आणि ते ACME Renewal Information (ARI) चे पालन करते. हे प्रमाणपत्र प्राधिकरणाने (Certificate Authority) प्रकाशित केलेले वेळापत्रक आहे, जे प्रत्यक्षात मुदत संपण्यापूर्वी सुमारे एक महिना आधी नूतनीकरण करते. नूतनीकरण अयशस्वी झाल्यास प्रशासकीय खात्याला ईमेलद्वारे कळवले जाते आणि मुदत संपलेले प्रमाणपत्र आपोआप अंगभूत self-signed प्रमाणपत्रावर परत जाते (fallback). कालपर्यंत व्यवस्थित चालणाऱ्या साइटवर ब्राउझरद्वारे मिळणारी चेतावणी याच fallback मुळे येते.

बहुतेक समस्यांची दोन मुख्य कारणे असतात. HTTP validation साठी inbound port 80 ची आवश्यकता असते, त्यामुळे "सर्व काही आधीच HTTPS आहे" असे समजून पोर्ट 80 बंद केल्यास, Wildcard किंवा Manual DNS backend वरील प्रत्येक ॲपचे नूतनीकरण खंडित होते. DNS validation साठी अशा API token ची गरज असते ज्याला write access आहे, त्यामुळे ते token बदलल्यास किंवा त्याचे अधिकार मर्यादित केल्यास, चेतावणी ईमेल येईपर्यंत नूतनीकरण शांतपणे बंद पडते.

Domains व्ह्यूमध्ये त्वरित प्रयत्न करण्यासाठी Renew All बटण उपलब्ध आहे, तसेच चाचणीसाठी Let's Encrypt Staging प्रोव्हायडर देखील आहे. Staging प्रमाणपत्रे ब्राउझरद्वारे हेतुपुरस्सर अविश्वासार्ह मानली जातात, आणि हाच त्याचा उद्देश आहे: तुम्ही production rate limit संपवण्याची भीती न बाळगता कितीही वेळा पुन्हा प्रयत्न करू शकता.

तुम्ही इन-बिल्ट मेल सर्व्हर वापरावा का?

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 असलेल्या पत्त्यावरून आलेले मेल स्पॅम फोल्डरमध्ये जातात.
• API DNS बॅकएंडवर तुमच्यासाठी SPF, DKIM आणि DMARC रेकॉर्ड्स आपोआप लिहिले जातात. Wildcard किंवा Manual बॅकएंडवर तुम्हाला ते स्वतः जोडावे लागतात आणि DKIM रेकॉर्ड नसल्यास तुम्ही साइन केलेला प्रत्येक संदेश पडताळणीयोग्य नसतो.

बहुतेक लोकांसाठी Cloudron वर मेल प्राप्त करणे आणि SendGrid, Postmark, Mailgun किंवा Amazon SES सारख्या रिलेद्वारे मेल पाठवणे ही रचना योग्य ठरते, जी Email व्ह्यूमध्ये कॉन्फिगर केली जाते. रिलेने तुमच्या डोमेनवरील कोणत्याही पत्त्यावरून मेल पाठवण्याची परवानगी देणे आवश्यक आहे, अन्यथा वेगवेगळ्या सेंडर्सकडून येणाऱ्या ॲप नोटिफिकेशन्स नाकारल्या जातात. जर मेल हे सर्व्हर खरेदी करण्यामागचे मुख्य कारण असेल, तर Mailcow सारखा डेडिकेटेड मेल सर्व्हर त्याच्या स्वतःच्या बॉक्सवर आणि स्वतःच्या IP रेप्युटेशनसह चालवा.

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

बॅकअपची गरज पडण्यापूर्वीच बॅकअपचे ठिकाण कॉन्फिगर करा

बॅकअप डीफॉल्टनुसार /var/backups या स्थानिक फाइलसिस्टमवर, म्हणजेच इतर सर्व डेटा असलेल्या त्याच डिस्कवर साठवले जातात. दस्तऐवजीकरण याबद्दल स्पष्टपणे सांगते: "प्लॅटफॉर्म सर्व्हर ज्या भौतिक डिस्कवर आहे, त्याच डिस्कवर बॅकअप ठेवणे धोकादायक आहे." एक डिस्क निकामी झाल्यास ॲप्स आणि बॅकअप दोन्ही एकाच वेळी नष्ट होतात.

Backups उघडा, त्यानंतर Backup Sites वर जा आणि पहिल्याच दिवशी बॅकअपसाठी दुसरे एखादे ठिकाण निश्चित करा. S3-सुसंगत ऑब्जेक्ट स्टोरेज (उदा. Backblaze B2, Wasabi, Cloudflare R2, DigitalOcean Spaces किंवा दुसऱ्या सर्व्हरवरील MinIO बकेट) हा सामान्य पर्याय आहे. याव्यतिरिक्त SSHFS, NFS, CIFS आणि साध्या फाइलसिस्टम टार्गेट्सनाही सपोर्ट दिला जातो.

बॅकअप उपयुक्त ठरेल की नाही हे खालील तीन सेटिंग्ज ठरवतात:

• Format. tgz प्रत्येक ॲपसाठी एक कॉम्प्रेस्ड आर्काइव्ह तयार करते आणि प्रत्येक वेळी पूर्ण डेटा पुन्हा अपलोड करते. rsync फक्त बदललेल्या फाइल्स अपलोड करते, जे मोठ्या Nextcloud साठी अधिक स्वस्त पडते, मात्र यामुळे स्टोरेज API वर अधिक विनंत्या (requests) कराव्या लागतात.
• Encryption. फाइलमधील मजकूर आणि फाइलची नावे या दोन्हीसाठी AES-256 एन्क्रिप्शनचा पर्याय उपलब्ध आहे. Cloudron पासवर्डची प्रत स्वतःकडे ठेवत नाही, त्यामुळे तो हरवल्यास तुम्ही स्वतःही बॅकअप डिक्रिप्ट करू शकणार नाही. सेव्ह बटण दाबण्यापूर्वी पासवर्ड सेल्फ-होस्टेड पासवर्ड मॅनेजरमध्ये जतन करा.
• Retention. हे 7 दैनिक आणि 4 साप्ताहिक अशा स्वरूपात लिहिता येते. ऑब्जेक्ट स्टोरेजवर जास्त काळ बॅकअप ठेवल्यास दरमहा बिल आकारले जाते, त्यामुळे तुम्ही जेवढ्या खर्चाची जबाबदारी घेऊ शकता, तेवढीच संख्या निवडा.

त्यानंतर रिस्टोरची चाचणी करा. एक छोटे ॲप इन्स्टॉल करा, डॅशबोर्डवरून ते रिस्टोर करा आणि त्याचा डेटा पुन्हा येतो का ते तपासा. ज्या बॅकअपची कधीही रिस्टोर चाचणी केली गेली नाही, तो केवळ एक अंदाज असतो.

मोफत स्तरावरील मर्यादा

October 2026 पर्यंत मोफत प्लॅनमध्ये जास्तीत जास्त दोन installed apps ठेवता येतात. याशिवाय app updates, प्रत्येक app चे backups, firewall, mail server आणि single sign-on या सुविधा समाविष्ट आहेत. तिसरा app जोडताना licence आवश्यक होते. Paid plans मधील app limit काढून टाकली जाते. उच्च स्तराच्या प्लॅनमध्ये user groups आणि roles, directory server आणि अनेक backup sites यांचा समावेश असतो. किंमती बदलू शकतात. त्यामुळे tutorial मधील एखाद्या संख्येवर अवलंबून न राहता Cloudron pricing page तपासा.

एक licence एका Cloudron install साठी असते. त्यामुळे दोन लहान servers ची किंमत एका मोठ्या server पेक्षा दुप्पट येते. या pricing मुळे बहुतेक वापरकर्ते एकाच मोठ्या VPS कडे वळतात. हे services अनेक machines वर विभागण्याच्या नेहमीच्या सल्ल्याच्या विरुद्ध जाते. ही बाब लक्षात घेऊन server चा आकार ठरवा, कारण नंतर services विभाजित केल्यास दुप्पट खर्च होतो.

जेव्हा काही बिघडते

सुरुवातीला अंगभूत (built-in) तपासणी करा. ही तपासणी DNS, प्रमाणपत्रे, डिस्क, मेमरी आणि प्रत्येक सेवेची क्रमाने पडताळणी करते आणि कोणती चाचणी अयशस्वी झाली हे सांगते:

sudo cloudron-support --troubleshoot

त्यानंतर, सामान्य systemd (system and service manager) साधनांचा वापर करा. systemctl status box हे Cloudron सेवेबद्दल माहिती देते, journalctl -u box -n 100 द्वारे अलीकडील लॉग्स मिळतात आणि journalctl -u docker हे त्याखालील कंटेनर रनटाइमची स्थिती दर्शवते. इन्स्टॉलेशन दरम्यान काही चूक झाली असल्यास, ती /var/log/cloudron-setup.log मध्ये नोंदवली जाते.

जर डॅशबोर्ड लोड होत नसेल, तर त्याचे कारण सहसा Cloudron नसून DNS किंवा प्रोव्हायडरचा फायरवॉल असते. तुमच्या लॅपटॉपवरून dig +short my.example.com चालवा आणि प्रोव्हायडरच्या नेटवर्क फायरवॉलमध्ये पोर्ट 80 आणि 443 उघडे असल्याची खात्री करा; हे सर्व्हरच्या स्वतःच्या नियमांपेक्षा वेगळे नियंत्रण असते. जर तुम्ही पुन्हा सुरुवात करत असाल, तर स्क्रिप्ट Error: Cloudron is already installed. To reinstall, start afresh सह दुसरी रन नाकारते, अशा वेळी सर्व्हर पुन्हा तयार करणे (rebuild) हाच सर्वोत्तम पर्याय आहे.

जेव्हा Cloudron तुमच्या गरजांसाठी योग्य नसते

जेव्हा तुम्हाला इन्फ्रास्ट्रक्चरऐवजी फक्त ॲप्लिकेशन्स चालवायची असतात, तेव्हा Cloudron योग्य ठरते. मात्र, जेव्हा तुम्हाला स्वतःचे कंटेनर्स तुमच्या पद्धतीने चालवायचे असतात, तेव्हा ते गैरसोयीचे ठरते; कारण Cloudron स्वतः nginx, Docker आणि firewall नियंत्रित करते आणि तुम्ही केलेले बदल ते ओव्हरराईट करते. जर तुमचा प्लॅन Docker compose फाइल्सचा फोल्डर वापरण्याचा असेल, तर Traefik in front of your own Docker Compose stacks तुम्हाला प्लॅटफॉर्मशिवाय समान स्वयंचलित TLS आणि सबडोमेन राउटिंगची सुविधा देते. जर तुम्ही अजून निर्णय घेतला नसेल, तर Cloudron, CasaOS and Coolify compared मध्ये या पर्यायांची तुलना दिली आहे आणि the wider list of what to self-host ही यादी इन्स्टॉलेशन गाईडपेक्षा सुरुवात करण्यासाठी अधिक चांगली जागा आहे.

FAQ

VPS वर Cloudron चालवण्यासाठी किती RAM आवश्यक आहे?

सेटअप स्क्रिप्ट 941 MB पेक्षा कमी RAM वर चालण्यास नकार देते आणि दस्तऐवजीकरणात 2 GB ची मागणी आहे. मात्र, अॅप्स नसलेल्या platform साठी ही किमान मर्यादा आहे. पहिल्याच boot पासून Cloudron Docker, nginx, स्वतःची box सेवा, database containers आणि mail stack चालवते. दोन अॅप्ससाठी 4 GB आणि सुमारे दहा अॅप्ससाठी 16 GB RAM राखून ठेवा. तसेच swap file जोडा, कारण Cloudron अॅप्सना अमर्यादित swap उपलब्ध करून देते. swap नसलेल्या मशीनमध्ये memory pressure मुळे सेवा पुन्हा सुरू होऊ शकतात.

Debian वर किंवा आधीपासून Docker चालू असलेल्या सर्व्हरवर Cloudron install करता येईल का?

यापैकी कोणताही पर्याय चालत नाही. स्क्रिप्ट release तपासते आणि Cloudron requires Ubuntu 22.04, 24.04, 26.04 संदेशासह थांबते. त्यामुळे Debian, Rocky आणि Alpine वापरता येत नाहीत. nginx, docker किंवा node यापैकी काही आधीपासून उपलब्ध असल्यास स्क्रिप्ट थांबते, कारण Cloudron या सर्वांचे निश्चित versions install करते आणि nginx configuration तसेच iptables rules स्वतः लिहिते. KVM VPS वरून नवीन Ubuntu image वापरून सुरुवात करा.

Dashboard चालत असताना माझ्या अॅपचे subdomains का चालत नाहीत?

Wildcard DNS record उपलब्ध नाही. Setup my.example.com साठी A record तयार करते किंवा तो आवश्यक असतो. त्यामुळे dashboard resolve होते, पण wiki.example.com साठी NXDOMAIN मिळते आणि browser साइट सापडत नसल्याचे दाखवतो. *.example.com साठी सर्व्हरच्या IP कडे निर्देश करणारा A record जोडा. त्यानंतर अॅप install करण्यापूर्वी dig +short wiki.example.com वापरून पडताळणी करा.

Cloudron mail server वापरणे आवश्यक आहे का?

नाही. तुम्ही incoming email बंद ठेवून Postmark, Mailgun किंवा Amazon SES सारख्या बाह्य relay द्वारे email पाठवू शकता. तुमचा provider outbound port 25 रोखत असल्यास किंवा IP address ची mail reputation नसल्यास हा अधिक सुरक्षित पर्याय आहे. Cloudron Email पूर्णपणे वगळल्यास provider firewall मध्ये ports 25, 465, 587, 993 आणि 4190 बंद करा; ते सर्व्हरवर बंद करू नका.

Free plan मधील दोन-अॅप मर्यादा गाठल्यावर काय होते?

Dashboard तिसरे install रोखते आणि licence key मागते. आधीपासून चालू असलेल्या अॅप्सवर कोणताही परिणाम होत नाही. त्यांचे updating सुरू राहते, त्यांचे backups घेतले जातात आणि त्यांची certificates कायम राहतात. Licence जोडल्यावर काहीही reinstall न करता ही मर्यादा उठते. त्यामुळे प्रत्यक्ष domain वर platform तपासण्यासाठी free plan हा योग्य पर्याय आहे.