VPS پر Cloudron انسٹال کرنے کا طریقہ

VPS پر Cloudron انسٹال کریں: مختصر طریقہ

Cloudron انسٹال کرنے کے لیے آپ کو ایک نیا Ubuntu server، کم از کم 2 GB RAM، اور ایسا domain درکار ہے جس کے DNS records میں آپ ترمیم کر سکیں۔ انسٹالیشن کے لیے صرف تین 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 کو انسٹال، update اور backup کرتا ہے، اور ان کے لیے TLS (transport layer security) certificates جاری کرتا ہے۔ ہر app Docker میں چلتی ہے، nginx سب apps کے سامنے موجود ہوتا ہے، اور ہر app کو آپ کے domain کا اپنا subdomain ملتا ہے۔ اسی آخری تفصیل کی وجہ سے یہاں DNS کا کام پہلے کرنا ضروری ہے۔

Cloudron base OS کے بارے میں سخت شرائط کیوں رکھتا ہے

Setup script کسی بھی چیز کی تنصیب سے پہلے server کو check کرتا ہے۔ کسی check کے ناکام ہونے کا مطلب نیا server order کرنا ہے۔ Image منتخب کرنے سے پہلے یہ شرائط پڑھ لیں۔

• صرف Ubuntu، اور صرف تین releases۔ کوئی بھی دوسری چیز Cloudron requires Ubuntu 20.04, 22.04, 24.04 کے ساتھ exit ہو جاتی ہے۔ Debian، Rocky اور Alpine supported نہیں ہیں۔ Ubuntu 24.04 کے لیے Cloudron 8 یا اس کے بعد کا version درکار ہے، اور script یہ آپ کے لیے check کرتا ہے۔
• صرف 64-bit Intel یا AMD: Error: Cloudron only supports amd64/x86_64۔ ARM VPS اسے نہیں چلا سکتا۔
• صرف مکمل hardware virtualisation۔ Container-based VPS پر script Error: Cloudron does not support lxc, only runs on bare metal or with full hardware virtualization کے ساتھ رک جاتی ہے، کیونکہ یہ container کو systemd-detect-virt --container کے ذریعے detect کرتی ہے۔ KVM ٹھیک ہے۔ OpenVZ اور LXC supported نہیں ہیں۔
• Root filesystem کو ext4 یا xfs ہونا چاہیے۔ کسی بھی دوسری صورت میں Error: Cloudron requires '/' to be ext4 or xfs ملتا ہے۔ اسی طرح btrfs اور zfs images fail ہوتی ہیں۔
• کم از کم 941 MB RAM اور / پر 20 GB درکار ہے۔ یہ مقدار free -m اور root filesystem کے size سے ناپی جاتی ہے۔
• Server واقعی نیا ہونا چاہیے۔ اگر nginx، docker یا node پہلے سے installed ہو تو script Error: Some packages like nginx/docker/nodejs are already installed. کے ساتھ انکار کر دیتی ہے۔

آخری check پر لوگ اکثر بحث کرتے ہیں، اس لیے اس کی وجہ سمجھ لیں۔ Cloudron، Docker، nginx، Node.js اور MySQL کے مخصوص versions install کرتا ہے، اپنی hosted ہر app کے لیے nginx configuration لکھتا ہے، اور iptables firewall rules خود manage کرتا ہے۔ کل install کیا ہوا Docker غلط version ہو سکتا ہے، اور آپ کی موجودہ nginx site files replace ہو جاتی ہیں۔ Cloudron پوری machine کو control کرتا ہے، اس لیے اسے dedicated VPS دیں۔

ایک اور check باآسانی نظرانداز ہو جاتا ہے۔ ایسے پرانے CPU پر جس میں AVX (advanced vector extensions) موجود نہ ہو، script CPU has no AVX support. MongoDB will be disabled دکھاتی ہے، اور MongoDB کی ضرورت رکھنے والی ہر app uninstallable ہو جاتی ہے۔ فیصلہ کرنے سے پہلے CPU کو grep -m1 -o avx /proc/cpuinfo کے ذریعے check کریں۔ قابل host پر یہ avx دکھاتا ہے، جبکہ پرانے host پر کچھ بھی نہیں دکھاتا۔

Cloudron کو کتنی RAM درکار ہے؟

اسکرپٹ 941 MB سے کم RAM پر چلنے سے انکار کرتا ہے، جس کی تصدیق Error: Cloudron requires atleast 1GB physical memory سے ہوتی ہے، جبکہ دستاویزات 2 GB RAM اور 20 GB disk کا تقاضا کرتی ہیں۔ دونوں اعداد platform کی کم از کم ضرورت ہیں، platform اور آپ کی ایپس کی مجموعی ضرورت نہیں۔ ایک بھی ایپ انسٹال کرنے سے پہلے Cloudron پہلے ہی Docker، nginx، اپنی box service، ایپس کو فراہم کیے جانے والے database containers (MySQL، PostgreSQL، MongoDB)، Redis اور mail stack چلا رہا ہوتا ہے۔ نئی installation پر docker ps چلائیں اور ان کی تعداد گنیں۔

ایپس کی memory limits اس بنیادی استعمال کے علاوہ ہوتی ہیں۔ ہر app package کم default limit کے ساتھ آتا ہے، جسے آپ ایپ کے Resources view میں slider سے بڑھا سکتے ہیں۔ جب کوئی ایپ اپنی limit سے تجاوز کرتی ہے تو وہ restart ہو جاتی ہے اور آپ کو OOM (out of memory) notification بھیجتی ہے۔ اس لیے جو box بار بار ایک ہی ایپ کو restart کرتا ہے، اس میں عموماً limit کا مسئلہ ہوتا ہے، bug کا نہیں۔

یہ وہ sizing ہے جس کا میں مشورہ دوں گا۔ یہ ایسے server کے لیے recommendations ہیں جسے آپ اگلے ماہ دوبارہ build نہیں کرنا چاہیں گے۔ یہ ناپے گئے benchmark results نہیں ہیں۔

[
  {
    "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 disk پر آرام سے چلتی ہیں۔ تقریباً دس ایپس کے لیے 16 GB RAM اور 240 GB disk درکار ہوتی ہے، کیونکہ platform کا بنیادی استعمال کم نہیں ہوتا اور ہر ایپ ایک Docker image، ایک database اور اپنا data شامل کرتی ہے۔ Disk لوگوں کی توقع سے زیادہ تیزی سے بھر جاتی ہے: images، app data اور local backups ایک ہی volume میں رہتے ہیں، جب تک آپ backups کو server سے باہر منتقل نہ کریں۔

Cloudron ہر ایپ کو unlimited swap فراہم کرتا ہے، اس لیے آپ کی مقرر کردہ memory limit صرف RAM پر لاگو ہوتی ہے۔ ایسی VPS image پر جس میں swap file نہ ہو، swapon --show کچھ بھی output نہیں کرتا، اور memory pressure کسی ایپ کے سست ہونے کے بجائے براہ راست OOM restarts کا سبب بنتا ہے۔ 2 GB swap شامل کرنا کم لاگت کا حفاظتی انتظام ہے، لیکن یہ حقیقی memory کا متبادل نہیں۔ VPS plans کے درمیان قیمت کا فرق ان گھنٹوں کے مقابلے میں کم ہے جو آپ limits کو tune کرنے میں صرف کریں گے، اس لیے دیکھیں کہ VPS کی اصل لاگت کتنی ہوتی ہے اور اگلا بڑا size خریدیں۔

DNS: ایپ subdomains کو فعال کرنے والا wildcard record

Cloudron dashboard کو my.example.com پر رکھتا ہے اور ہر ایپ کے لیے الگ subdomain استعمال کرتا ہے، اس لیے DNS بعد کا مرحلہ نہیں بلکہ بنیادی ضرورت ہے۔ پہلی بار dashboard کھولنے سے پہلے ان records کو server کے public IP address کی طرف point کریں:

• my.example.com کو A record کے طور پر set کریں۔ یہ dashboard ہے۔
• *.example.com کو A record کے طور پر set کریں۔ یہی record app subdomains کو فعال کرتا ہے، اس لیے wiki.example.com اور git.example.com ان ایپس کو install کرتے ہی resolve ہو جائیں گے۔
• example.com کو A record کے طور پر صرف اس صورت میں set کریں جب آپ bare domain پر کوئی ایپ چلانا چاہتے ہوں۔

Wildcard record کی precedence explicit record سے کم ہوتی ہے، اس لیے کسی دوسرے مقام کی طرف موجودہ www.example.com record اسی طرح کام کرتا رہے گا۔

Setup کے دوران آپ منتخب کرتے ہیں کہ اس کے بعد Cloudron DNS کو کیسے manage کرے گا:

• API provider۔ Cloudron Cloudflare، DigitalOcean، Route53، Hetzner، Porkbun، Linode، deSEC، Gandi، Namecheap اور تقریباً بیس دیگر providers کے لیے token محفوظ کرتا ہے، پھر mail records سمیت ہر record خود لکھتا ہے۔
• Wildcard۔ آپ * record دستی طور پر شامل کرتے ہیں اور Cloudron کوئی record نہیں لکھتا۔
• Manual۔ Cloudron ہر record دکھاتا ہے اور ہر ایپ install کرنے سے پہلے آپ کے اسے شامل کرنے کا انتظار کرتا ہے۔

Wildcard DNS record، wildcard certificate نہیں ہوتا۔ Default certificate provider Let's Encrypt Prod - Wildcard ہے، جو DNS کے ذریعے ownership ثابت کرتا ہے، اس لیے یہ صرف API provider کے ساتھ کام کرتا ہے۔ Wildcard یا Manual backend پر آپ ہر ایپ کے لیے HTTP کے ذریعے validate ہونے والے الگ certificate پر منتقل ہو جاتے ہیں۔ اس صورت میں inbound port 80 مستقل طور پر کھلا رہنا چاہیے۔ اگر آپ کا registrar یا DNS host API list میں موجود ہے تو اسے استعمال کریں: mail records اور certificates دونوں manage کرنا آپ کی ذمہ داری نہیں رہیں گے۔

آگے بڑھنے سے پہلے تصدیق کریں۔ dig +short my.example.com اور dig +short anything.example.com دونوں کو server کا IP address دکھانا چاہیے۔ اگر wildcard query کچھ نہ دکھائے تو بعد میں apps ناکام ہوں گی، جبکہ dashboard درست کام کرتا رہے گا۔

اگر domain Cloudflare کے پیچھے ہے تو records کو DNS only پر set کریں۔ Proxy صرف HTTP اور HTTPS forward کرتا ہے، اس لیے mail ports ناکام ہو جائیں گے، اور ہر ایپ کو visitor کے address کے بجائے Cloudflare کا address نظر آئے گا۔

سیٹ اپ اسکرپٹ چلائیں

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

اسے root کے طور پر یا sudo کے ذریعے چلائیں، کیونکہ بصورتِ دیگر اس کی پہلی output This script should be run as root. ہوتی ہے۔ انسٹالیشن میں کئی منٹ لگتے ہیں اور اس دوران کوئی output نہیں آتی، کیونکہ apt کی output اور Docker pulls ایک log file میں لکھی جاتی ہیں۔ اسے دوسرے SSH session سے monitor کریں:

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 کا address دکھاتا ہے، پھر The server has to be rebooted to apply all the settings. Reboot now ? [Y/n] پوچھتا ہے۔ yes میں جواب دیں۔ اگر restart schedule کرنا ہو تو --skip-reboot flag موجود ہے، لیکن server کے دوبارہ شروع ہونے تک Cloudron قابلِ استعمال نہیں ہوگا۔

پہلا boot: domain، DNS backend اور admin account

https://<server-ip> کھولیں اور browser warning قبول کریں۔ Certificate self-signed ہے کیونکہ Cloudron ابھی آپ کے domain سے واقف نہیں، اس لیے اس کے پاس certificate authority سے certificate طلب کرنے کے لیے معلومات موجود نہیں ہیں۔ Chrome میں Advanced پر کلک کریں، پھر Proceed to <ip> (unsafe) پر۔ Firefox میں Advanced پر کلک کریں، پھر Accept the Risk and Continue پر۔

پہلی screen آپ سے domain مانگتی ہے۔ example.com درج کریں، اور dashboard my.example.com پر دستیاب ہو جائے گا۔ اس کے بجائے آپ cloudron.example.com جیسا subdomain بھی استعمال کر سکتے ہیں، پھر dashboard my.cloudron.example.com پر ہوگا۔ DNS backend منتخب کریں، اگر API token موجود ہے تو اسے paste کریں، اور ایسا admin account بنائیں جس کا email address آپ باقاعدگی سے پڑھتے ہوں: Let's Encrypt registration اور platform کے تمام alerts اسی address پر بھیجے جاتے ہیں۔

محفوظ کرنے کے بعد Cloudron certificates طلب کرتا ہے اور dashboard کو https://my.example.com پر منتقل کر دیتا ہے۔ اس مرحلے کے بعد IP address والا URL کام نہیں کرے گا، اس لیے نئے URL کو bookmark کر لیں۔

Certificates: کون سا certificate کب renew ہوتا ہے اور کب رک جاتا ہے

Certificate renewal خودکار ہے اور ACME Renewal Information (ARI) کی پیروی کرتی ہے۔ یہ وہ schedule ہے جسے certificate authority شائع کرتی ہے۔ عملی طور پر certificate کی expiry سے تقریباً ایک ماہ پہلے renewal ہوتی ہے۔ Renewal ناکام ہونے پر admin account کو email بھیجی جاتی ہے، اور expired certificate کی جگہ built-in self-signed certificate استعمال ہوتا ہے۔ کسی ایسی site پر browser warning کا اصل مطلب یہی fallback ہے جو گزشتہ روز درست کام کر رہی تھی۔

زیادہ تر مسائل کی دو وجوہات ہوتی ہیں۔ HTTP validation کے لیے inbound port 80 درکار ہے۔ اس لیے یہ سوچ کر port 80 بند کرنا کہ "سب کچھ HTTPS ہے" Wildcard یا Manual DNS backend پر موجود ہر app کی renewal روک دیتا ہے۔ DNS validation کے لیے ایسا API token درکار ہے جس کے پاس اب بھی write access ہو۔ اس token کو rotate کرنے یا اس کی permissions محدود کرنے سے renewal خاموشی سے ناکام ہو جاتی ہے، یہاں تک کہ warning email موصول نہ ہو جائے۔

Domains view میں Renew All button موجود ہے، جس سے کوشش فوراً شروع کی جا سکتی ہے۔ Testing کے لیے Let's Encrypt Staging provider بھی دستیاب ہے۔ Staging certificates کو browsers جان بوجھ کر trusted نہیں سمجھتے، اور یہی مقصد ہے۔ آپ production rate limit استعمال کیے بغیر جتنی بار چاہیں دوبارہ کوشش کر سکتے ہیں۔

کیا آپ کو built-in mail server استعمال کرنا چاہیے؟

Cloudron مکمل mail stack فراہم کرتا ہے، جس میں IMAP mailboxes، submission، sieve filters اور DKIM (domainkeys identified mail) signing شامل ہیں۔ Dashboard میں Email کے تحت اسے ہر domain کے لیے enable کریں۔ Mail کی delivery یقینی بنانا مشکل حصہ ہے، اور اس مشکل کا کوئی بھی سبب Cloudron نہیں ہے۔

• زیادہ تر VPS providers spam کو روکنے کے لیے outbound port 25 block کرتے ہیں۔ کچھ providers support ticket کے بعد اسے unblock کر دیتے ہیں۔ Server سے nc -zv aspmx.l.google.com 25 کے ذریعے test کریں۔ اگر command موجود نہ ہو تو netcat-openbsd install کریں۔ Open ports succeeded رپورٹ کرتا ہے، جبکہ blocked port timeout ہونے تک معلق رہتا ہے۔
• PTR record (reverse DNS) آپ کا DNS host نہیں بلکہ VPS provider set کرتا ہے، اور اسے mail hostname سے match کرنا ہوتا ہے۔ Generic PTR والے address سے آنے والی mail spam folders میں پہنچ جاتی ہے۔
• API DNS backend پر SPF، DKIM اور DMARC records آپ کے لیے لکھے جاتے ہیں۔ Wildcard یا Manual backend پر یہ records آپ کو خود شامل کرنے ہوتے ہیں۔ Missing DKIM record کا مطلب ہے کہ آپ کی signed ہر message کی تصدیق نہیں ہو سکتی۔

زیادہ تر لوگوں کے لیے مؤثر setup یہ ہے کہ mail Cloudron پر receive کی جائے اور Email view میں configured SendGrid، Postmark، Mailgun یا Amazon SES جیسے relay کے ذریعے send کی جائے۔ Relay کو آپ کے domain کے کسی بھی address کے نام سے mail send کرنے کی اجازت دینی ہوگی، ورنہ مختلف senders کی app notifications reject ہو جائیں گی۔ اگر server خریدنے کی بنیادی وجہ mail ہے تو اپنے الگ box اور الگ IP reputation کے ساتھ Mailcow جیسے dedicated mail server چلائیں۔

اگر آپ Cloudron Email بالکل استعمال نہیں کرتے تو اپنے provider کے firewall میں ports 25، 465، 587، 993 اور 4190 block کریں۔ یہ کام server پر نہیں بلکہ provider کے firewall میں کریں، کیونکہ Cloudron خود iptables rules لکھتا ہے اور ان rules کا انتظام اپنے پاس رکھنے کی توقع کرتا ہے۔ یہ plain VPS کے برعکس ہے، جہاں آپ خود ufw rules manage کرتے ہیں۔

ضرورت پڑنے سے پہلے backup target configure کریں

Backups بطور default local filesystem پر /var/backups میں محفوظ ہوتے ہیں، یعنی باقی تمام چیزوں والی اسی disk پر۔ Documentation میں اس بارے میں واضح تنبیہ ہے: "Platform server والی اسی physical disk پر backups رکھنا خطرناک ہے۔" ایک disk fail ہونے سے apps اور backups دونوں بیک وقت ضائع ہو جاتے ہیں۔

Backups کھولیں، پھر Backup Sites منتخب کریں، اور پہلے ہی دن اسے کسی دوسرے مقام کی طرف point کریں۔ S3-compatible object storage عام انتخاب ہے، جیسے Backblaze B2، Wasabi، Cloudflare R2، DigitalOcean Spaces، یا دوسرے server پر موجود MinIO bucket۔ SSHFS، NFS، CIFS اور plain filesystem targets بھی supported ہیں۔

تین settings طے کرتی ہیں کہ یہ backup واقعی کتنا مفید ہے:

• Format۔ tgz ہر app کے لیے ایک compressed archive لکھتا ہے اور ہر run میں پوری archive دوبارہ upload کرتا ہے۔ rsync صرف changed files upload کرتا ہے۔ بڑے Nextcloud کے لیے یہ کہیں کم خرچ ہوتا ہے، لیکن storage API کو کہیں زیادہ requests بھیجتا ہے۔
• Encryption۔ اختیاری AES-256، جو file contents اور filenames دونوں کو encrypt کرتا ہے۔ Cloudron password کی copy محفوظ نہیں رکھتا۔ اس لیے password ضائع ہونے پر backups کو کوئی بھی decrypt نہیں کر سکتا، آپ بھی نہیں۔ Save پر click کرنے سے پہلے اسے self-hosted password manager میں محفوظ کریں۔
• Retention۔ اسے 7 daily اور 4 weekly جیسی counts کی صورت میں لکھا جاتا ہے۔ Object storage پر طویل retention ہر ماہ bill بڑھاتی ہے، اس لیے وہی number منتخب کریں جس کی ادائیگی جاری رکھنے پر آپ رضامند ہوں۔

اس کے بعد restore کی جانچ کریں۔ کوئی چھوٹی app install کریں، dashboard سے اسے restore کریں، اور دیکھیں کہ وہ اپنے data کے ساتھ دوبارہ چلتی ہے۔ جس backup کو کبھی restore نہ کیا گیا ہو، وہ صرف ایک اندازہ ہے۔

مفت tier کی حدود

August 2026 تک مفت plan زیادہ سے زیادہ دو installed apps تک محدود ہے۔ باقی تمام سہولتیں اس میں شامل ہیں: app updates، ہر app کے backups، firewall، mail server اور single sign-on۔ تیسری app وہ حد ہے جہاں licence درکار ہوتی ہے۔ paid plans apps کی حد ختم کرتے ہیں، جبکہ زیادہ مہنگا plan user groups اور roles، directory server اور متعدد backup sites بھی شامل کرتا ہے۔ Prices تبدیل ہو سکتی ہیں، اس لیے tutorial میں دی گئی کسی number کے بجائے Cloudron pricing page دیکھیں۔

ایک licence ایک Cloudron install کے لیے ہوتی ہے، اس لیے دو چھوٹے servers کی لاگت ایک بڑے server سے دوگنی ہوتی ہے۔ یہ pricing زیادہ تر لوگوں کو ایک بڑے VPS پر جانے پر مجبور کرتی ہے، جو services کو متعدد machines پر تقسیم کرنے کے عمومی مشورے کے برعکس ہے۔ اسی بنیاد پر box کا size طے کریں، کیونکہ بعد میں تقسیم کرنے کا مطلب دو licences کی ادائیگی ہو سکتا ہے۔

جب کچھ خراب ہو جائے

بلٹ اِن چیک سے آغاز کریں۔ یہ DNS، certificates، disk، memory اور ہر service کو باری باری چیک کرتا ہے اور بتاتا ہے کہ کون سا test ناکام ہوا:

sudo cloudron-support --troubleshoot

اس کے بعد عام systemd (system اور service manager) کے tools استعمال کریں۔ systemctl status box خود Cloudron service کی حالت بتاتا ہے، journalctl -u box -n 100 اس کے حالیہ logs دکھاتا ہے، اور journalctl -u docker زیریں container runtime کا جائزہ لیتا ہے۔ installation کے دوران پیش آنے والی تمام خرابیاں /var/log/cloudron-setup.log میں محفوظ رہتی ہیں۔

جو dashboard load نہ ہو، اس کی وجہ عموماً Cloudron کے بجائے DNS یا provider firewall ہوتی ہے۔ اپنے laptop سے dig +short my.example.com چلائیں اور تصدیق کریں کہ provider کے network firewall میں ports 80 اور 443 کھلے ہیں۔ یہ server کے اپنے rules سے الگ control ہے۔ اگر آپ دوبارہ ابتدا کر رہے ہیں تو script Error: Cloudron is already installed. To reinstall, start afresh کے ساتھ دوسری بار چلنے سے انکار کرتی ہے، اس لیے rebuilt server ہی درست حل ہے۔

جب Cloudron مناسب انتخاب نہ ہو

Cloudron اس وقت موزوں ہے جب آپ کو infrastructure کے بجائے applications چلانی ہوں۔ جب آپ اپنے containers کو اپنی مرضی سے چلانا چاہتے ہوں تو یہ کم موزوں ہے، کیونکہ یہ nginx، Docker اور firewall کا انتظام خود سنبھالتا ہے اور وہاں آپ کی کی گئی تبدیلیاں overwrite کر سکتا ہے۔ اگر آپ کا منصوبہ compose files کے ایک folder پر مبنی ہے تو اپنے Docker Compose stacks کے سامنے Traefik استعمال کرنے سے platform کی اضافی تہہ کے بغیر وہی خودکار TLS اور subdomain routing حاصل ہوتی ہے۔ اگر آپ نے ابھی انتخاب نہیں کیا تو Cloudron، CasaOS اور Coolify کا تقابلی جائزہ ان تینوں کو ساتھ رکھ کر سمجھاتا ہے، جبکہ self-host کرنے والی چیزوں کی وسیع فہرست install guide کے مقابلے میں آغاز کے لیے بہتر جگہ ہے۔

FAQ

VPS پر Cloudron کو کتنی RAM درکار ہوتی ہے؟

Setup script 941 MB سے کم RAM پر چلنے سے انکار کرتی ہے، اور documentation 2 GB کا تقاضا کرتی ہے، لیکن یہ اس platform کے لیے کم از کم مقدار ہے جس پر کوئی app موجود نہ ہو۔ Cloudron پہلے boot سے Docker، nginx، اپنی box service، database containers اور mail stack چلاتا ہے۔ دو apps کے لیے 4 GB اور تقریباً دس apps کے لیے 16 GB مختص کریں، اور swap file شامل کریں، کیونکہ Cloudron apps کو unlimited swap دیتا ہے اور swap کے بغیر server پر memory pressure کے نتیجے میں services restart ہو سکتی ہیں۔

کیا میں Debian یا ایسے server پر Cloudron install کر سکتا ہوں جہاں Docker پہلے سے چل رہا ہو؟

دونوں صورتیں کام نہیں کریں گی۔ Script release check کرتی ہے اور Cloudron requires Ubuntu 20.04, 22.04, 24.04 کے ساتھ رک جاتی ہے، اس لیے Debian، Rocky اور Alpine قابل استعمال نہیں ہیں۔ Script اس وقت بھی رک جاتی ہے جب nginx، docker یا node پہلے سے موجود ہو، کیونکہ Cloudron ان سب کے pinned versions install کرتا ہے اور nginx configuration اور iptables rules خود لکھتا ہے۔ KVM VPS پر fresh Ubuntu image سے آغاز کریں۔

Dashboard کام کرتا ہے، لیکن میرے app subdomains کیوں fail ہو رہے ہیں؟

Wildcard DNS record موجود نہیں ہے۔ Setup my.example.com کے لیے A record بناتی ہے یا اس کی موجودگی ضروری قرار دیتی ہے، اس لیے dashboard resolve ہو جاتا ہے، جبکہ wiki.example.com NXDOMAIN واپس کرتا ہے اور browser بتاتا ہے کہ site نہیں مل سکتی۔ *.example.com کے لیے server IP کی طرف اشارہ کرنے والا 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 مکمل طور پر skip کریں تو provider firewall میں ports 25، 465، 587، 993 اور 4190 بند کریں، server پر نہیں۔

Free plan میں دو apps کی حد تک پہنچنے کے بعد کیا ہوتا ہے؟

Dashboard تیسری app کی installation block کر دیتا ہے اور licence key طلب کرتا ہے۔ پہلے سے چلنے والی apps متاثر نہیں ہوتیں: ان کی updates جاری رہتی ہیں، ان کا backup بنتا رہتا ہے، اور ان کے certificates برقرار رہتے ہیں۔ Licence شامل کرنے سے کسی چیز کو reinstall کیے بغیر یہ حد ختم ہو جاتی ہے، اس لیے free plan حقیقی domain پر پہلے platform آزمانے کا مناسب طریقہ ہے۔