Ubuntu VPS-ல் Cloudron நிறுவுவது எப்படி?

VPS-ல் Cloudron-ஐ நிறுவுதல்: சுருக்கமான வழிமுறை

VPS-ல் Cloudron-ஐ நிறுவ, புதிய Ubuntu server, குறைந்தபட்சம் 2 GB RAM, மற்றும் நீங்கள் DNS பதிவுகளை மாற்றக்கூடிய ஒரு domain தேவை. நிறுவல் செயல்முறை மூன்று கட்டளைகள் மற்றும் ஒரு reboot-ஐ உள்ளடக்கியது. பெரும்பாலும் சிக்கல்கள் இந்த நிலைக்கு முன்போ (தவறான base image, தவறான virtualisation வகை) அல்லது பின்போ (DNS, மின்னஞ்சல், backups) ஏற்படுகின்றன.

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

Cloudron, self-hosted applications-க்கான நிறுவல், மேம்படுத்தல், backup மற்றும் TLS (transport layer security) certificates வழங்குதல் ஆகியவற்றைச் செய்கிறது. ஒவ்வொரு application-மும் Docker-ல் இயங்குகிறது, அனைத்திற்கும் முன்னால் nginx செயல்படுகிறது, மேலும் ஒவ்வொரு application-மும் உங்கள் domain-ன் தனி subdomain-ஐப் பெறுகிறது. இந்த கடைசி அம்சம் காரணமாகவே, DNS தொடர்பான வேலைகளை முதலில் செய்ய வேண்டும்.

Cloudron ஏன் அடிப்படை OS-ஐப் பொறுத்தவரை கண்டிப்புடன் உள்ளது

எந்தவொரு மென்பொருளையும் நிறுவும் முன், setup script சர்வரைச் சரிபார்க்கும். ஏதேனும் ஒரு சரிபார்ப்பு தோல்வியடைந்தால், நீங்கள் புதிய சர்வரைத் தேர்ந்தெடுக்க வேண்டியிருக்கும். எனவே, ஒரு image-ஐத் தேர்ந்தெடுக்கும் முன் இவற்றை வாசிக்கவும்.

• Ubuntu மட்டுமே, அதுவும் மூன்று குறிப்பிட்ட releases மட்டுமே. வேறு எதையும் பயன்படுத்தினால் Cloudron requires Ubuntu 20.04, 22.04, 24.04 பிழையுடன் வெளியேறும். 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-ல், systemd-detect-virt --container மூலம் container-ஐக் கண்டறிந்து, Error: Cloudron does not support lxc, only runs on bare metal or with full hardware virtualization பிழையுடன் script நின்றுவிடும். 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 நிறுவப்பட்டிருந்தால், Error: Some packages like nginx/docker/nodejs are already installed. பிழையுடன் script நிறுவுவதை மறுத்துவிடும்.

கடைசி சரிபார்ப்புதான் பயனர்களிடையே விவாதத்தை ஏற்படுத்துகிறது, அதற்கான காரணம் இதோ. Cloudron, Docker, nginx, Node.js மற்றும் MySQL ஆகியவற்றின் குறிப்பிட்ட பதிப்புகளை நிறுவுகிறது, அது ஹோஸ்ட் செய்யும் ஒவ்வொரு செயலிக்கும் (app) nginx configuration-ஐ எழுதுகிறது, மேலும் iptables firewall விதிகளைத் தானே நிர்வகிக்கிறது. நீங்கள் நேற்று நிறுவிய Docker தவறான பதிப்பாக இருக்கலாம், மேலும் உங்கள் ஏற்கனவே உள்ள nginx site கோப்புகள் மாற்றப்படலாம். Cloudron முழு இயந்திரத்தையும் தன் கட்டுப்பாட்டில் வைத்திருக்கும், எனவே அதற்கு ஒரு பிரத்யேக VPS-ஐ வழங்கவும்.

கவனிக்கத் தவறக்கூடிய மற்றொரு சரிபார்ப்பு உள்ளது. AVX (advanced vector extensions) இல்லாத பழைய CPU-களில், script CPU has no AVX support. MongoDB will be disabled-ஐ அச்சிடும், மேலும் MongoDB தேவைப்படும் எந்தவொரு செயலியையும் நிறுவ முடியாது. நீங்கள் உறுதிப்படுத்தும் முன் grep -m1 -o avx /proc/cpuinfo மூலம் CPU-வைச் சரிபார்க்கவும்; இது திறன் கொண்ட host-ல் avx-ஐ அச்சிடும், பழைய host-ல் எதையும் காட்டாது.

Cloudron-க்கு எவ்வளவு RAM தேவை?

941 MB-க்குக் குறைவாக இருந்தால், Error: Cloudron requires atleast 1GB physical memory பிழையுடன் script இயங்க மறுத்துவிடும். ஆவணங்கள் 2 GB RAM மற்றும் 20 GB disk-ஐக் கோருகின்றன. இந்த அளவுகள் platform-க்கான அடிப்படைத் தேவைகளே தவிர, உங்கள் applications-க்கானவை அல்ல. நீங்கள் ஒரு application-ஐ நிறுவும் முன்பே, Cloudron ஏற்கனவே Docker, nginx, அதன் சொந்த box service, applications-க்கு வழங்கும் database containers (MySQL, PostgreSQL, MongoDB), Redis மற்றும் mail stack ஆகியவற்றை இயக்கிவிடும். புதிய நிறுவலின்போது docker ps கட்டளையை இயக்கி அவற்றின் எண்ணிக்கையைப் பாருங்கள்.

App memory வரம்புகள் இந்த அடிப்படைத் தேவைகளுக்கு மேலதிகமாக அமையும். ஒவ்வொரு app package-ம் ஒரு குறைந்தபட்ச default வரம்பைக் கொண்டிருக்கும்; அதை app-ன் Resources பகுதியில் உள்ள slider மூலம் நீங்கள் அதிகரிக்கலாம். ஒரு app அதன் வரம்பைத் தாண்டும்போது, அது restart ஆகி உங்களுக்கு OOM (out of memory) அறிவிப்பை அனுப்பும். எனவே, ஒரு app தொடர்ந்து restart ஆகிறது என்றால், அது பெரும்பாலும் bug அல்ல, memory வரம்புப் பிரச்சினையாகவே இருக்கும்.

அடுத்த மாதம் மீண்டும் கட்டமைக்கத் தேவையில்லாத ஒரு server-க்கு நான் பரிந்துரைக்கும் அளவுகள் கீழே கொடுக்கப்பட்டுள்ளன. இவை அளவிடப்பட்ட benchmark முடிவுகள் அல்ல.

[
  {
    "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
  }
]

இரண்டு applications-க்கு 4 GB RAM மற்றும் 60 GB disk போதுமானது. சுமார் பத்து applications-க்கு 16 GB RAM மற்றும் 240 GB disk தேவைப்படும். ஏனெனில், platform-ன் அடிப்படைத் தேவை குறையாது, மேலும் ஒவ்வொரு app-ம் ஒரு Docker image, ஒரு database மற்றும் அதன் சொந்தத் தரவுகளைச் சேர்க்கும். மக்கள் எதிர்பார்ப்பதை விட disk வேகமாக நிரம்பும்: நீங்கள் backups-ஐ server-லிருந்து வெளியே மாற்றும் வரை, images, app data மற்றும் local backups அனைத்தும் ஒரே volume-ஐப் பகிர்ந்து கொள்ளும்.

Cloudron ஒவ்வொரு app-க்கும் வரம்பற்ற swap-ஐ வழங்குகிறது, எனவே நீங்கள் அமைக்கும் memory வரம்பு RAM-க்கு மட்டுமே பொருந்தும். Swap file இல்லாத VPS image-ல், swapon --show எதையும் காட்டாது. அத்தகைய சூழலில், memory அழுத்தம் ஏற்படும்போது app மெதுவாகச் செயல்படுவதற்குப் பதிலாக, நேரடியாக OOM restart-க்கு உள்ளாகும். 2 GB swap சேர்ப்பது ஒரு மலிவான பாதுகாப்பு, ஆனால் அது உண்மையான memory-க்கு மாற்றாகாது. VPS திட்டங்களுக்கு இடையிலான விலை வித்தியாசம், நீங்கள் வரம்புகளைச் சீரமைக்கச் செலவிடும் நேரத்தை விடக் குறைவு. எனவே, ஒரு VPS-ன் உண்மையான செலவு என்ன என்பதைப் பார்த்துவிட்டு, அடுத்த கட்ட அளவுள்ள server-ஐத் தேர்வு செய்யுங்கள்.

DNS: app subdomain-களைச் செயல்பட வைக்கும் wildcard record

Cloudron, dashboard-ஐ my.example.com-லும், ஒவ்வொரு application-ஐயும் அதன் சொந்த subdomain-லும் இயக்குகிறது. எனவே, DNS என்பது பிந்தைய கட்டத்தில் செய்ய வேண்டிய ஒன்றல்ல, அது ஒரு அடிப்படைத் தேவை. dashboard-ஐ முதல்முறை திறப்பதற்கு முன்பே, பின்வரும் records-ஐ server-ன் public IP address-க்குச் சுட்டிக்காட்டவும்:

• my.example.com - ஒரு A record. இதுவே dashboard.
• *.example.com - ஒரு A record. இதுவே app subdomain-கள் செயல்படக் காரணமாகிறது. இதனால், நீங்கள் apps-ஐ நிறுவியவுடன் wiki.example.com மற்றும் git.example.com ஆகியவை உடனே resolve ஆகும்.
• example.com - ஒரு A record. bare domain-ல் ஒரு app தேவைப்பட்டால் மட்டும் இதைச் சேர்க்கவும்.

ஒரு wildcard record-ன் முன்னுரிமை, ஒரு குறிப்பிட்ட (explicit) record-ஐ விடக் குறைவு. எனவே, ஏற்கனவே உள்ள www.example.com வேறொரு இடத்தைச் சுட்டிக்காட்டினால், அது தொடர்ந்து செயல்படும்.

Setup-ன் போது, அதன் பிறகு Cloudron எவ்வாறு DNS-ஐக் கையாள வேண்டும் என்பதை நீங்கள் தேர்வு செய்யலாம்:

• API provider: Cloudflare, DigitalOcean, Route53, Hetzner, Porkbun, Linode, deSEC, Gandi, Namecheap மற்றும் சுமார் இருபது பிற சேவைகளுக்கான token-ஐ Cloudron சேமித்துக்கொள்ளும். பின், mail records உட்பட அனைத்து records-ஐயும் அதுவே எழுதும்.
• Wildcard: நீங்கள் * record-ஐ நீங்களாகவே சேர்க்க வேண்டும்; Cloudron எதையும் எழுதாது.
• Manual: ஒவ்வொரு app-ஐ நிறுவும் முன்பும், தேவையான records-ஐ Cloudron உங்களுக்குக் காட்டும். நீங்கள் அவற்றைச் சேர்க்கும் வரை அது காத்திருக்கும்.

ஒரு wildcard DNS record என்பது wildcard certificate அல்ல. இயல்பான certificate provider என்பது Let's Encrypt Prod - Wildcard ஆகும். இது DNS மூலம் உரிமையை உறுதிப்படுத்துவதால், API provider-உடன் மட்டுமே செயல்படும். Wildcard அல்லது Manual backends-ல், நீங்கள் ஒவ்வொரு app-க்கும் HTTP மூலம் சரிபார்க்கப்படும் ஒரு certificate-ஐப் பயன்படுத்த வேண்டியிருக்கும். இதற்கு inbound port 80 எப்போதும் திறந்திருக்க வேண்டும். உங்கள் registrar அல்லது DNS host, API பட்டியலில் இருந்தால் அதையே பயன்படுத்தவும்: அப்போது mail records மற்றும் certificates-ஐ நிர்வகிக்கும் பொறுப்பு உங்களுக்கு இருக்காது.

தொடர்வதற்கு முன் சரிபார்க்கவும். dig +short my.example.com மற்றும் dig +short anything.example.com ஆகிய இரண்டும் உங்கள் server-ன் IP address-ஐக் காட்ட வேண்டும். wildcard query எதையும் காட்டவில்லை என்றால், dashboard சரியாகச் செயல்பட்டாலும், apps பின்னர் தோல்வியடையும்.

உங்கள் domain, Cloudflare-க்கு பின்னால் இருந்தால், records-ஐ DNS only என அமைக்கவும். proxy என்பது HTTP மற்றும் HTTPS-ஐ மட்டுமே forward செய்யும்; இதனால் mail ports செயல்படாது, மேலும் ஒவ்வொரு app-ம் பார்வையாளரின் IP-க்கு பதிலாக Cloudflare-ன் address-ஐயே பார்க்கும்.

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 ஆகியவை log file-க்கு அனுப்பப்படுவதால், இந்தச் செயல்முறை பின்னணியில் அமைதியாக நடக்கும். மற்றொரு SSH session மூலம் இதைக் கண்காணிக்கவும்:

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

முடிவில், இது After reboot, visit one of the following URLs and accept the self-signed certificate to finish setup. என்பதையும் உங்கள் server-ன் முகவரியையும் காட்டும். பிறகு The server has to be rebooted to apply all the settings. Reboot now ? [Y/n] என்று கேட்கும். அதற்கு yes என்று பதிலளிக்கவும். நீங்கள் restart-ஐத் திட்டமிட விரும்பினால் --skip-reboot flag-ஐப் பயன்படுத்தலாம். ஆனால், server மீண்டும் இயங்கும் வரை Cloudron-ஐப் பயன்படுத்த முடியாது.

முதல் தொடக்கம்: டொமைன், DNS பேக்கெண்ட் மற்றும் நிர்வாகி கணக்கு

https://<server-ip>-ஐத் திறந்து, உலாவியில் வரும் எச்சரிக்கையை ஏற்கவும். Cloudron-க்கு உங்கள் டொமைன் இன்னும் தெரியாது என்பதால், இது self-signed சான்றிதழாக இருக்கும்; எனவே சான்றிதழ் வழங்கும் அதிகார அமைப்பிடம் (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 token இருந்தால் அதை ஒட்டவும், மேலும் நீங்கள் அடிக்கடி சரிபார்க்கும் மின்னஞ்சல் முகவரியைக் கொண்டு நிர்வாகி கணக்கை உருவாக்கவும்: Let's Encrypt பதிவு மற்றும் தளத்தின் அனைத்து அறிவிப்புகளும் இந்த மின்னஞ்சலுக்கே அனுப்பப்படும்.

நீங்கள் சேமித்ததும், Cloudron சான்றிதழ்களைக் கோரி டேஷ்போர்டை https://my.example.com-க்கு மாற்றும். அந்தப் புள்ளியில் IP முகவரி URL வேலை செய்யாது, எனவே புதிய URL-ஐ புக்மார்க் செய்து கொள்ளவும்.

சான்றிதழ்கள்: எவை புதுப்பிக்கப்படுகின்றன, எப்போது அவை நின்றுவிடும்

சான்றிதழ் புதுப்பித்தல் தானியங்கி முறையில் நடைபெறுகிறது. இது ACME Renewal Information (ARI) மற்றும் சான்றிதழ் வழங்கும் அமைப்பு (Certificate Authority) வெளியிடும் கால அட்டவணையைப் பின்பற்றுகிறது. நடைமுறையில், காலாவதியாவதற்கு ஒரு மாதத்திற்கு முன்பே இது புதுப்பிக்கப்படும். புதுப்பித்தல் தோல்வியுற்றால், நிர்வாகியின் மின்னஞ்சல் கணக்கிற்கு அறிவிப்பு அனுப்பப்படும். சான்றிதழ் காலாவதியாகிவிட்டால், கணினியில் உள்ள self-signed சான்றிதழுக்கு அது மாறிவிடும். நேற்று சரியாகச் செயல்பட்ட தளத்தில் இன்று உலாவியில் (browser) எச்சரிக்கை தோன்றுவதற்கு இந்த மாற்றமே காரணம்.

பெரும்பாலான சிக்கல்களுக்கு இரண்டு காரணங்கள் உள்ளன. HTTP validation-க்கு உள்வரும் port 80 தேவைப்படுகிறது. எனவே, "எல்லாமே HTTPS-ல் தான் உள்ளது" என்று கருதி port 80-ஐ மூடுவது, Wildcard அல்லது Manual DNS backend-ல் உள்ள அனைத்து செயலிகளின் புதுப்பித்தலையும் பாதிக்கும். DNS validation-க்கு எழுதும் அனுமதி (write access) கொண்ட API token தேவை. எனவே, அந்த token-ஐ மாற்றும்போதோ அல்லது அதன் அனுமதியைக் குறைக்கும்போதோ, எச்சரிக்கை மின்னஞ்சல் வரும் வரை புதுப்பித்தல் தோல்வியடைவது தெரியாமல் போகலாம்.

Domains திரையில் உள்ள Renew All பொத்தானைப் பயன்படுத்தி, உடனடியாகப் புதுப்பித்தலை முயற்சி செய்யலாம். சோதனைகளுக்கு Let's Encrypt Staging provider-ஐப் பயன்படுத்தவும். Staging சான்றிதழ்களை உலாவிகள் நம்பகமானதாக ஏற்காது; இதுவே அதன் நோக்கம். இதன் மூலம், production rate limit-ஐப் பாதிக்காமல் நீங்கள் எத்தனை முறை வேண்டுமானாலும் மீண்டும் முயற்சி செய்யலாம்.

உள்ளமைக்கப்பட்ட (built-in) mail server-ஐ நீங்கள் பயன்படுத்த வேண்டுமா?

Cloudron, IMAP mailboxes, submission, sieve filters மற்றும் DKIM (domainkeys identified mail) signing ஆகியவற்றுடன் கூடிய முழுமையான mail stack-ஐ வழங்குகிறது. Dashboard-ல் உள்ள Email பிரிவின் கீழ் ஒவ்வொரு domain-க்கும் இதை நீங்கள் செயல்படுத்தலாம். மின்னஞ்சல்களைச் சென்றடையச் செய்வதுதான் கடினமான பகுதி; இதில் Cloudron-ன் குறைபாடு ஏதுமில்லை.

• ஸ்பேம் கட்டுப்பாட்டுக்காக பெரும்பாலான VPS வழங்குநர்கள் outbound port 25-ஐத் தடுக்கிறார்கள். சில நிறுவனங்கள் support ticket கோரிக்கைக்குப் பிறகு இதைத் திறந்துவிடும். உங்கள் server-லிருந்து nc -zv aspmx.l.google.com 25 கட்டளையைப் பயன்படுத்திச் சோதிக்கவும் (கட்டளை இல்லையெனில் netcat-openbsd-ஐ நிறுவவும்). திறந்திருக்கும் ports-ஐ succeeded அறிக்கை செய்யும்; தடுக்கப்பட்ட port, நேரம் முடியும் வரை காத்திருந்து பின் செயலிழக்கும்.
• PTR record (reverse DNS) உங்கள் DNS host-ஆல் அல்ல, உங்கள் VPS வழங்குநரால் அமைக்கப்படுகிறது. இது mail hostname-உடன் ஒத்துப்போக வேண்டும். பொதுவான PTR கொண்ட முகவரியிலிருந்து வரும் மின்னஞ்சல்கள் ஸ்பேம் கோப்புறைகளுக்குச் சென்றுவிடும்.
• API DNS backend-ஐப் பயன்படுத்தினால் SPF, DKIM மற்றும் DMARC பதிவுகள் உங்களுக்காகத் தானாகவே எழுதப்படும். Wildcard அல்லது Manual backend-களில் இவற்றை நீங்களே கைமுறையாகச் சேர்க்க வேண்டும். DKIM பதிவு விடுபட்டால், நீங்கள் கையொப்பமிடும் ஒவ்வொரு செய்தியும் சரிபார்க்க முடியாததாகிவிடும்.

பெரும்பாலான பயனர்களுக்குச் சிறப்பாகச் செயல்படும் முறை: மின்னஞ்சல்களை Cloudron மூலம் பெறுவது மற்றும் SendGrid, Postmark, Mailgun அல்லது Amazon SES போன்ற relay மூலம் அனுப்புவது. இதை Email திரையில் உள்ளமைக்கலாம். Relay சேவையானது உங்கள் domain-ல் உள்ள எந்த முகவரியிலிருந்தும் மின்னஞ்சல் அனுப்ப அனுமதிக்க வேண்டும்; இல்லையெனில் வெவ்வேறு அனுப்புநர்களிடமிருந்து வரும் app notifications நிராகரிக்கப்படும். மின்னஞ்சல் சேவைக்காகவே நீங்கள் server-ஐ வாங்குகிறீர்கள் என்றால், Mailcow போன்ற பிரத்யேக mail server-ஐ அதன் சொந்த IP reputation கொண்ட தனி server-ல் இயக்குவது சிறந்தது.

நீங்கள் Cloudron Email-ஐப் பயன்படுத்தவில்லை என்றால், உங்கள் வழங்குநரின் firewall-ல் ports 25, 465, 587, 993 மற்றும் 4190 ஆகியவற்றைத் தடுக்கவும். இதை server-ல் செய்யாமல் firewall-ல் செய்யவும், ஏனெனில் Cloudron தானாகவே iptables விதிகளை எழுதும் மற்றும் அதைத் தானே நிர்வகிக்க விரும்பும். இது சாதாரண VPS-க்கு நேர்மாறானது, அங்கு நீங்கள் ufw விதிகளை நீங்களே நிர்வகிக்க வேண்டும்.

தேவைப்படுவதற்கு முன்பே backup இலக்கை உள்ளமைக்கவும்

Backups இயல்பாகவே /var/backups என்ற உள்ளூர் கோப்பு முறைமையில் (local filesystem), மற்ற எல்லா தரவுகளும் இருக்கும் அதே வட்டில் சேமிக்கப்படும். இதைப் பற்றி ஆவணங்கள் தெளிவாகக் கூறுகின்றன: "தளத்தின் server இருக்கும் அதே வட்டில் backup-களை வைத்திருப்பது ஆபத்தானது." ஒரு வட்டு பழுதடைந்தால், அது பயன்பாடுகளையும் (apps) அதன் backup-களையும் சேர்த்து அழித்துவிடும்.

Backups என்பதைத் திறந்து, பின் Backup Sites என்பதற்குச் சென்று, முதல் நாளிலேயே அதை வேறொரு இடத்திற்கு மாற்றவும். S3-இணக்கமான object storage (Backblaze B2, Wasabi, Cloudflare R2, DigitalOcean Spaces, அல்லது இரண்டாவது server-ல் உள்ள MinIO bucket) பொதுவாகப் பரிந்துரைக்கப்படுகிறது. மேலும், SSHFS, NFS, CIFS மற்றும் சாதாரண கோப்பு முறைமை இலக்குகளும் ஆதரிக்கப்படுகின்றன.

பின்வரும் மூன்று அமைப்புகள், அந்த backup பயனுள்ளதா என்பதைத் தீர்மானிக்கின்றன:

• Format. tgz ஒவ்வொரு பயன்பாட்டிற்கும் ஒரு compressed archive-ஐ உருவாக்கி, ஒவ்வொரு முறையும் முழுவதையும் மீண்டும் பதிவேற்றும். rsync மாற்றப்பட்ட கோப்புகளை மட்டுமே பதிவேற்றும். இது பெரிய Nextcloud பயன்பாடுகளுக்குச் செலவைக் குறைக்கும், ஆனால் storage API-க்கு அதிக கோரிக்கைகளை (requests) அனுப்பும்.
• Encryption. கோப்பின் உள்ளடக்கம் மற்றும் கோப்பின் பெயர்கள் ஆகிய இரண்டையும் மறைக்க AES-256 விருப்பத்தேர்வு உள்ளது. Cloudron கடவுச்சொல்லின் நகலை வைத்திருக்காது. எனவே, அதைத் தொலைத்துவிட்டால், உங்களால் உட்பட யாராலும் அந்த backup-களைத் திறக்க முடியாது. சேமிப்பதற்கு (save) முன்பே அதை சுயமாக நிர்வகிக்கப்படும் password manager-ல் சேமிக்கவும்.
• Retention. இது 7 daily மற்றும் 4 weekly போன்ற எண்ணிக்கையில் குறிப்பிடப்படுகிறது. object storage-ல் அதிக காலத்திற்குத் தரவுகளை வைத்திருப்பது ஒவ்வொரு மாதமும் கட்டணத்தை உயர்த்தும், எனவே நீங்கள் தொடர்ந்து செலுத்தக்கூடிய எண்ணிக்கையைத் தேர்வு செய்யவும்.

அதன்பிறகு, restore செய்வதைச் சோதித்துப் பார்க்கவும். ஒரு சிறிய பயன்பாட்டை நிறுவி, dashboard மூலம் அதை restore செய்து, அதன் தரவுகளுடன் அது மீண்டும் வருவதை உறுதிப்படுத்தவும். ஒருமுறை கூட restore செய்து பார்க்கப்படாத backup என்பது வெறும் ஊகம் மட்டுமே.

இலவசத் திட்டத்தின் வரம்புகள் என்ன

ஆகஸ்ட் 2026 நிலவரப்படி, இலவசத் திட்டத்தில் இரண்டு applications மட்டுமே நிறுவ முடியும். மற்ற அனைத்து வசதிகளும் இதில் அடங்கும்: application updates, ஒவ்வொரு application-க்கும் தனித்தனி backups, firewall, mail server மற்றும் single sign-on. மூன்றாவது application-ஐ நிறுவும்போது உங்களுக்கு உரிமம் (licence) தேவைப்படும். கட்டணத் திட்டங்கள் application வரம்பை நீக்குகின்றன; உயர்நிலைத் திட்டங்களில் user groups மற்றும் roles, directory server மற்றும் பல backup sites ஆகிய கூடுதல் வசதிகள் உள்ளன. விலைகள் மாறக்கூடும் என்பதால், ஒரு tutorial-ல் உள்ள எண்ணை நம்புவதை விட Cloudron pricing page-ஐச் சரிபார்க்கவும்.

ஒரு உரிமம் ஒரு Cloudron install-க்கு மட்டுமே பொருந்தும். எனவே, இரண்டு சிறிய servers-க்கு ஆகும் செலவு, ஒரு பெரிய server-க்கு ஆகும் செலவை விட இருமடங்காகும். இந்த விலை நிர்ணய முறை, பெரும்பாலான பயனர்களை ஒரே பெரிய VPS-ஐப் பயன்படுத்தத் தூண்டுகிறது. இது சேவைகளை வெவ்வேறு இயந்திரங்களில் பிரித்து வைக்க வேண்டும் என்ற பொதுவான ஆலோசனைக்கு முரணானது. பிற்காலத்தில் பிரிப்பது கூடுதல் செலவை ஏற்படுத்தும் என்பதால், இதை மனதில் வைத்து server-ன் அளவைத் தீர்மானிக்கவும்.

ஏதாவது பழுதடைந்தால்

உள்ளமைக்கப்பட்ட (built-in) சரிபார்ப்பு கருவியிலிருந்து தொடங்கவும். இது 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-ல் சிக்கல் இருக்கலாம். உங்கள் laptop-லிருந்து dig +short my.example.com கட்டளையை இயக்கி, provider-ன் network firewall-ல் 80 மற்றும் 443 ports திறக்கப்பட்டுள்ளதா என்பதை உறுதிப்படுத்தவும். இது server-ன் சொந்த விதிகளை விடத் தனிப்பட்ட கட்டுப்பாடாகும். நீங்கள் மீண்டும் தொடங்க விரும்பினால், அந்த script Error: Cloudron is already installed. To reinstall, start afresh பிழையைக் காட்டி மீண்டும் இயங்குவதைத் தடுக்கும்; எனவே, server-ஐ மீண்டும் உருவாக்குவதே (rebuild) சரியான தீர்வாகும்.

Cloudron பொருத்தமற்றதாக இருக்கும் சூழல்கள்

உங்களுக்கு உள்கட்டமைப்பு (infrastructure) தேவையில்லாமல், வெறும் applications மட்டும் தேவைப்படும்போது Cloudron பொருத்தமாக இருக்கும். ஆனால், உங்கள் சொந்த containers-ஐ உங்கள் விருப்பப்படி இயக்க விரும்பினால், Cloudron பொருத்தமற்றது. ஏனெனில், இது nginx, Docker மற்றும் firewall ஆகியவற்றைக் கட்டுப்படுத்துகிறது; நீங்கள் செய்யும் மாற்றங்களை இது மேலெழுதிவிடும் (overwrite). உங்கள் திட்டம் பல compose files-ஐக் கொண்ட ஒரு கோப்புறையாக இருந்தால், Traefik in front of your own Docker Compose stacks உங்களுக்கு அதே தானியங்கி TLS மற்றும் subdomain routing வசதியை, எந்தவொரு கூடுதல் தளமும் (platform) இன்றி வழங்கும். நீங்கள் இன்னும் எதைத் தேர்வு செய்வது என்று முடிவெடுக்கவில்லை என்றால், Cloudron, CasaOS and Coolify compared அவற்றை ஒப்பிட்டுப் பார்க்க உதவும். மேலும், ஒரு நிறுவல் வழிகாட்டியைத் தேடுவதை விட, the wider list of what to self-host என்பது தொடங்குவதற்குச் சிறந்த இடமாகும்.

FAQ

Cloudron-க்கு ஒரு VPS-ல் எவ்வளவு RAM தேவை?

941 MB-க்கு குறைவாக இருந்தால் setup script இயங்காது. ஆவணங்கள் 2 GB தேவை என்று குறிப்பிடுகின்றன, ஆனால் இது எந்த application-களும் இல்லாத அடிப்படைத் தேவை மட்டுமே. Cloudron, Docker, nginx, அதன் சொந்த box service, database containers மற்றும் mail stack ஆகியவற்றை முதல் boot-லேயே இயக்குகிறது. இரண்டு application-களுக்கு 4 GB-யும், சுமார் பத்து application-களுக்கு 16 GB-யும் ஒதுக்கீடு செய்யவும். ஒரு swap file-ஐச் சேர்க்கவும்; ஏனெனில் Cloudron application-களுக்கு வரம்பற்ற swap-ஐ வழங்குகிறது, swap இல்லாத நிலையில் memory அழுத்தம் ஏற்பட்டால் application-கள் restart ஆகக்கூடும்.

நான் Debian-ல் அல்லது ஏற்கனவே Docker இயங்கும் server-ல் Cloudron-ஐ நிறுவ முடியுமா?

இரண்டுமே இயங்காது. இந்த script OS release-ஐச் சரிபார்த்து Cloudron requires Ubuntu 20.04, 22.04, 24.04 பிழையுடன் நின்றுவிடும், எனவே Debian, Rocky மற்றும் Alpine ஆதரிக்கப்படாது. மேலும் nginx, docker அல்லது node ஏற்கனவே இருந்தால், அது நிறுவுவதை நிறுத்திவிடும். ஏனெனில், இவை அனைத்திற்கும் குறிப்பிட்ட version-களை அது நிறுவுகிறது மற்றும் nginx configuration மற்றும் iptables விதிகளை அதுவே உருவாக்குகிறது. KVM VPS-ல் புதிய Ubuntu image-ஐப் பயன்படுத்தித் தொடங்கவும்.

dashboard இயங்கும்போது, எனது app subdomain-கள் ஏன் தோல்வியடைகின்றன?

wildcard DNS record விடுபட்டுள்ளது. Setup my.example.com-க்கான A record-ஐ உருவாக்குகிறது அல்லது எதிர்பார்க்கிறது, எனவே dashboard இயங்குகிறது. ஆனால் wiki.example.com NXDOMAIN என்று காட்டுகிறது மற்றும் தளம் கிடைக்கவில்லை என்று browser தெரிவிக்கிறது. server IP-ஐச் சுட்டிக்காட்டும் வகையில் *.example.com-க்கு ஒரு A record-ஐச் சேர்க்கவும், பின்னர் application-ஐ நிறுவும் முன் dig +short wiki.example.com மூலம் உறுதிப்படுத்தவும்.

நான் Cloudron mail server-ஐப் பயன்படுத்த வேண்டுமா?

இல்லை. நீங்கள் உள்வரும் மின்னஞ்சலை (incoming email) முடக்கிவிட்டு, Postmark, Mailgun அல்லது Amazon SES போன்ற external relay மூலம் அனுப்பலாம். உங்கள் service provider outbound port 25-ஐத் தடுத்தாலோ அல்லது IP address-க்கு mail reputation இல்லையென்றாலோ இதுவே பாதுகாப்பான வழி. நீங்கள் Cloudron Email-ஐ முழுமையாகத் தவிர்த்தால், server-ல் உள்ள ports 25, 465, 587, 993 மற்றும் 4190-ஐ server firewall-ல் அல்லாமல், provider firewall-ல் மூடிவிடவும்.

இலவசத் திட்டத்தில் (free plan) இரண்டு application வரம்பை எட்டும்போது என்ன நடக்கும்?

Dashboard மூன்றாவது installation-ஐத் தடுத்து, licence key-ஐக் கேட்கும். நீங்கள் ஏற்கனவே இயக்கும் application-கள் பாதிக்கப்படாது: அவை தொடர்ந்து update ஆகும், backup எடுக்கப்படும் மற்றும் அவற்றின் certificates அப்படியே இருக்கும். ஒரு licence-ஐச் சேர்ப்பது எதையும் மீண்டும் நிறுவ வேண்டிய அவசியமின்றி இந்த வரம்பை நீக்கிவிடும். எனவே, ஒரு உண்மையான domain-ல் platform-ஐச் சோதிக்க இலவசத் திட்டம் ஒரு சிறந்த வழியாகும்.