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 बाबत इतका काटेकोर का आहे

सेटअप स्क्रिप्ट काहीही इन्स्टॉल करण्यापूर्वी सर्व्हरची तपासणी करते. जर एखादी तपासणी अयशस्वी झाली, तर तुम्हाला नवीन सर्व्हर घ्यावा लागेल. इमेज निवडण्यापूर्वी या अटी वाचा.

• फक्त Ubuntu आणि केवळ तीन रिलीज. इतर कोणत्याही OS वर स्क्रिप्ट Cloudron requires Ubuntu 20.04, 22.04, 24.04 देऊन थांबते. Debian, Rocky आणि Alpine समर्थित नाहीत. Ubuntu 24.04 साठी Cloudron 8 किंवा त्यापुढील आवृत्ती आवश्यक आहे आणि स्क्रिप्ट आपोआप याची खात्री करते.
• फक्त 64-bit Intel किंवा AMD: Error: Cloudron only supports amd64/x86_64. ARM VPS वर हे चालू शकत नाही.
• फक्त पूर्ण हार्डवेअर व्हर्च्युअलायझेशन. कंटेनर-आधारित VPS वर स्क्रिप्ट Error: Cloudron does not support lxc, only runs on bare metal or with full hardware virtualization देऊन थांबते, कारण ती systemd-detect-virt --container द्वारे कंटेनर ओळखते. KVM चालते, पण OpenVZ आणि LXC चालत नाहीत.
• रूट फाइलसिस्टम ext4 किंवा xfs असणे आवश्यक आहे. इतर कोणत्याही फाइलसिस्टमवर तुम्हाला Error: Cloudron requires '/' to be ext4 or xfs मिळेल, ज्यामुळे btrfs आणि zfs इमेजेस अयशस्वी होतात.
• किमान 941 MB RAM आणि / वर 20 GB जागा आवश्यक आहे, जी free -m आणि रूट फाइलसिस्टमच्या आकारावरून मोजली जाते.
• पूर्णपणे नवीन सर्व्हर. जर nginx, docker किंवा node आधीच इन्स्टॉल असेल, तर स्क्रिप्ट Error: Some packages like nginx/docker/nodejs are already installed. देऊन नकार देते.

ही शेवटची तपासणी अनेकदा वादाचा विषय ठरते, म्हणून त्याचे कारण खालीलप्रमाणे आहे. Cloudron हे Docker, nginx, Node.js आणि MySQL च्या ठराविक आवृत्त्या इन्स्टॉल करते, प्रत्येक होस्ट केलेल्या ॲपसाठी nginx कॉन्फिगरेशन लिहिते आणि iptables फायरवॉलचे नियम स्वतः व्यवस्थापित करते. तुम्ही काल इन्स्टॉल केलेले Docker चुकीच्या आवृत्तीचे असू शकते आणि तुमच्या विद्यमान nginx साइट फाइल्स बदलल्या जाऊ शकतात. Cloudron संपूर्ण मशीनवर नियंत्रण ठेवते, त्यामुळे त्यासाठी एक समर्पित VPS द्या.

आणखी एक तपासणी जी दुर्लक्षित होऊ शकते. AVX (advanced vector extensions) नसलेल्या जुन्या CPU वर स्क्रिप्ट CPU has no AVX support. MongoDB will be disabled प्रिंट करते आणि MongoDB आवश्यक असलेले प्रत्येक ॲप अनइन्स्टॉल करण्यायोग्य बनते. सर्व्हर घेण्यापूर्वी grep -m1 -o avx /proc/cpuinfo वापरून CPU तपासा, जे सक्षम होस्टवर avx प्रिंट करते आणि जुन्या होस्टवर काहीही प्रिंट करत नाही.

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: वाइल्डकार्ड रेकॉर्ड ज्यामुळे ॲप सबडोमेन कार्य करतात

Cloudron डॅशबोर्डला my.example.com वर आणि प्रत्येक ॲपला त्याच्या स्वतःच्या सबडोमेनवर ठेवते, त्यामुळे DNS ही नंतरची पायरी नसून एक पूर्वअट आहे. डॅशबोर्ड पहिल्यांदा उघडण्यापूर्वी हे रेकॉर्ड सर्व्हरच्या सार्वजनिक IP ॲड्रेसवर पॉइंट करा:

• my.example.com एक A रेकॉर्ड म्हणून. हा डॅशबोर्ड आहे.
• *.example.com एक A रेकॉर्ड म्हणून. हे रेकॉर्ड ॲप सबडोमेन कार्यक्षम करते, जेणेकरून तुम्ही ॲप्स इन्स्टॉल करताच wiki.example.com आणि git.example.com रिझॉल्व्ह होतील.
• example.com एक A रेकॉर्ड म्हणून, फक्त जर तुम्हाला बेअर डोमेनवर ॲप हवे असेल तरच.

वाइल्डकार्ड रेकॉर्डला स्पष्ट (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 फॉरवर्ड करते, त्यामुळे मेल पोर्ट्स बंद पडतात आणि प्रत्येक ॲपला अभ्यागताच्या IP ऐवजी Cloudflare चा ॲड्रेस दिसतो.

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

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 साप्ताहिक अशा स्वरूपात लिहिता येते. ऑब्जेक्ट स्टोरेजवर जास्त काळ बॅकअप ठेवल्यास दरमहा बिल आकारले जाते, त्यामुळे तुम्ही जेवढ्या खर्चाची जबाबदारी घेऊ शकता, तेवढीच संख्या निवडा.

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

फ्री टियरच्या मर्यादा काय आहेत

ऑगस्ट 2026 पर्यंत, फ्री प्लॅनमध्ये जास्तीत जास्त दोन अॅप्स इन्स्टॉल करता येतात. इतर सर्व सुविधा यामध्ये समाविष्ट आहेत: अॅप अपडेट्स, प्रति-अॅप बॅकअप, फायरवॉल, मेल सर्व्हर आणि सिंगल साइन-ऑन. तिसरे अॅप इन्स्टॉल करण्यासाठी तुम्हाला लायसन्सची आवश्यकता असते. पेड प्लॅन्समध्ये अॅप्सची मर्यादा नसते आणि उच्च प्लॅनमध्ये युजर ग्रुप्स, रोल्स, डिरेक्टरी सर्व्हर आणि एकापेक्षा जास्त बॅकअप साइट्सची सुविधा मिळते. किमती बदलू शकतात, त्यामुळे ट्युटोरियलमधील आकड्यांवर अवलंबून न राहता Cloudron च्या किमतींचे पेज तपासा.

एक लायसन्स एका Cloudron इन्स्टॉलसाठी वैध असते, त्यामुळे दोन लहान सर्व्हरचा खर्च एका मोठ्या सर्व्हरच्या खर्चाच्या दुप्पट होतो. या किमतीच्या रचनेमुळे बहुतेक लोक एका मोठ्या VPS चा वापर करणे पसंत करतात, जे सेवा वेगवेगळ्या मशीनवर विभागण्याच्या सामान्य सल्ल्याच्या विरुद्ध आहे. हे लक्षात घेऊन सर्व्हरचा आकार निवडा, कारण नंतर सेवा विभागल्यास तुम्हाला दुप्पट पैसे मोजावे लागतील.

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

सुरुवातीला अंगभूत (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

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

सेटअप स्क्रिप्ट 941 MB पेक्षा कमी मेमरी असल्यास चालत नाही आणि डॉक्युमेंटेशनमध्ये 2 GB ची शिफारस केली आहे, परंतु हे केवळ कोणत्याही ॲप्सशिवाय प्लॅटफॉर्मसाठीचे किमान प्रमाण आहे. Cloudron पहिल्या बूटपासूनच Docker, nginx, स्वतःची box सर्व्हिस, डेटाबेस कंटेनर्स आणि मेल स्टॅक चालवते. दोन ॲप्ससाठी 4 GB आणि सुमारे दहा ॲप्ससाठी 16 GB मेमरीचे नियोजन करा. तसेच, एक swap file जोडा, कारण Cloudron ॲप्सना अमर्यादित swap देते आणि जर सर्व्हरवर swap नसेल, तर मेमरीवरील ताणामुळे ॲप्स वारंवार रीस्टार्ट होऊ शकतात.

मी Debian वर किंवा आधीच Docker चालणाऱ्या सर्व्हरवर Cloudron इंस्टॉल करू शकतो का?

दोन्ही शक्य नाही. स्क्रिप्ट ऑपरेटिंग सिस्टमची आवृत्ती तपासते आणि Cloudron requires Ubuntu 20.04, 22.04, 24.04 असल्यास थांबते, त्यामुळे Debian, Rocky आणि Alpine वर हे चालत नाही. तसेच, जर nginx, docker किंवा node आधीच उपस्थित असतील, तर स्क्रिप्ट थांबते, कारण Cloudron त्यांच्या विशिष्ट आवृत्त्या इंस्टॉल करते आणि स्वतःचे nginx कॉन्फिगरेशन व iptables नियम लिहिते. नेहमी KVM VPS वरील ताज्या Ubuntu इमेजपासून सुरुवात करा.

डॅशबोर्ड काम करत असताना माझे ॲप सबडोमेन का फेल होतात?

wildcard DNS रेकॉर्ड गहाळ आहे. सेटअपसाठी my.example.com चे A रेकॉर्ड आवश्यक असते किंवा ते तयार केले जाते, त्यामुळे डॅशबोर्ड रिझॉल्व्ह होतो, परंतु wiki.example.com साठी NXDOMAIN एरर येते आणि ब्राउझर साइट सापडत नाही असे दर्शवतो. सर्व्हरच्या IP कडे निर्देशित करणारे *.example.com साठी एक A रेकॉर्ड जोडा आणि ॲप इंस्टॉल करण्यापूर्वी dig +short wiki.example.com ने खात्री करा.

मला Cloudron मेल सर्व्हर वापरणे अनिवार्य आहे का?

नाही. तुम्ही येणारे ईमेल (incoming email) बंद ठेवू शकता आणि Postmark, Mailgun किंवा Amazon SES सारख्या बाह्य रिलेद्वारे ईमेल पाठवू शकता. जर तुमचा प्रोव्हायडर आउटबाउंड पोर्ट 25 ब्लॉक करत असेल किंवा तुमच्या IP पत्त्याची मेल रेप्युटेशन नसेल, तर हा अधिक सुरक्षित पर्याय आहे. जर तुम्ही Cloudron Email पूर्णपणे वगळले, तर सर्व्हरऐवजी प्रोव्हायडरच्या फायरवॉलमध्ये पोर्ट 25, 465, 587, 993 आणि 4190 बंद करा.

फ्री प्लॅनवर दोन ॲप्सची मर्यादा गाठल्यावर काय होते?

डॅशबोर्ड तिसरे ॲप इंस्टॉल करण्यास प्रतिबंध करतो आणि लायसन्स की विचारतो. तुम्ही आधीच चालवत असलेली ॲप्स तशीच राहतात: ती अपडेट होत राहतात, त्यांचे बॅकअप घेतले जातात आणि त्यांची प्रमाणपत्रेही कार्यरत राहतात. लायसन्स जोडल्यास कोणतीही गोष्ट पुन्हा इंस्टॉल न करता मर्यादा वाढवली जाते, त्यामुळे खऱ्या डोमेनवर प्लॅटफॉर्मची चाचणी घेण्यासाठी फ्री प्लॅन हा एक योग्य मार्ग आहे.