Paano Mag-install ng Cloudron sa VPS

Mag-install ng Cloudron sa isang VPS: maikling bersyon

Para mag-install ng Cloudron sa isang VPS, kailangan mo ng bagong Ubuntu server, hindi bababa sa 2 GB RAM, at domain na mae-edit mo ang mga DNS record. Ang mismong installation ay tatlong command at isang reboot. Halos lahat ng nagiging problema ay nangyayari bago ang hakbang na iyon (maling base image, maling virtualization type) o pagkatapos nito (DNS, mail, backups).

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

Nag-i-install, nag-a-update, nagba-back up, at nag-i-issue ang Cloudron ng mga TLS (transport layer security) certificate para sa self-hosted app. Tumatakbo ang bawat app sa Docker, nasa harap ng lahat ng ito ang nginx, at may sariling subdomain ng iyong domain ang bawat app. Dahil dito, DNS ang unang kailangang i-configure.

Bakit mahigpit ang Cloudron sa base OS

Sinusuri ng setup script ang server bago ito mag-install ng anuman. Kapag bumagsak ang isang check, kailangan mong mag-order ng bagong server. Basahin ang mga requirement na ito bago pumili ng image.

• Ubuntu lamang, at tatlong release lamang. Lalabas ang script na may Cloudron requires Ubuntu 20.04, 22.04, 24.04 para sa anumang iba pa. Hindi supported ang Debian, Rocky, at Alpine. Kailangan ng Ubuntu 24.04 ang Cloudron 8 o mas bago, at awtomatikong sinusuri iyon ng script.
• 64-bit Intel o AMD lamang: Error: Cloudron only supports amd64/x86_64. Hindi ito maaaring patakbuhin sa ARM VPS.
• Full hardware virtualisation lamang. Sa container-based VPS, hihinto ang script na may Error: Cloudron does not support lxc, only runs on bare metal or with full hardware virtualization dahil nade-detect nito ang container gamit ang systemd-detect-virt --container. Ayos ang KVM. Hindi supported ang OpenVZ at LXC.
• Dapat ext4 o xfs ang root filesystem. Sa iba pang filesystem, makukuha mo ang Error: Cloudron requires '/' to be ext4 or xfs. Ganito nabibigo ang mga btrfs at zfs image.
• Hindi bababa sa 941 MB na RAM at 20 GB sa /. Sinusukat ito gamit ang free -m at ang laki ng root filesystem.
• Tunay na fresh ang server. Kung naka-install na ang nginx, docker, o node, tatanggi ang script at maglalabas ng Error: Some packages like nginx/docker/nodejs are already installed..

Ang huling check ang madalas pagtalunan, kaya narito ang dahilan. Nag-i-install ang Cloudron ng mga pinned version ng Docker, nginx, Node.js, at MySQL. Sinusulat din nito ang nginx configuration para sa bawat app na hina-host nito, at ito mismo ang namamahala sa iptables firewall rules. Maling version ang Docker na na-install mo kahapon, at mapapalitan ang mga dati mong nginx site file. Cloudron ang may kontrol sa buong machine, kaya gumamit ng dedicated VPS para rito.

May isa pang check na madaling hindi mapansin. Sa mas lumang CPU na walang AVX (advanced vector extensions), ipinapakita ng script ang CPU has no AVX support. MongoDB will be disabled. Dahil dito, nagiging hindi ma-install ang bawat app na nangangailangan ng MongoDB. Suriin ang CPU bago mag-commit gamit ang grep -m1 -o avx /proc/cpuinfo. Ipinapakita nito ang avx sa isang capable host at walang output sa lumang host.

Gaano karaming RAM ang kailangan ng Cloudron?

Tumangging tumakbo ang script kapag mas mababa sa 941 MB ang RAM, gamit ang Error: Cloudron requires atleast 1GB physical memory, at hinihingi ng documentation ang 2 GB na RAM at 20 GB na disk. Pareho itong minimum para sa platform lamang, hindi para sa platform kasama ang mga app mo. Bago ka mag-install ng kahit isang app, tumatakbo na ang Docker, nginx, sarili nitong box service, mga database container na ipinapagamit nito sa mga app (MySQL, PostgreSQL, MongoDB), Redis, at mail stack. Patakbuhin ang docker ps sa bagong install at bilangin ang mga ito.

Bukod pa sa base na iyon ang memory limit ng bawat app. May mababang default limit ang bawat app package, at maaari mo itong taasan gamit ang slider sa Resources view ng app. Kapag lumampas ang isang app sa limit nito, nagre-restart ito at nagpapadala sa iyo ng OOM (out of memory) notification. Kaya kung patuloy na nagre-restart ang isang app sa isang server, karaniwang limit problem ito at hindi bug.

Ito ang sizing na irerekomenda kong i-order. Mga rekomendasyon ito para sa server na hindi mo na kailangang i-rebuild sa susunod na buwan. Hindi ito mga resulta ng measured 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
  }
]

Komportable ang dalawang app sa 4 GB na RAM at 60 GB na disk. Ang humigit-kumulang sampung app ay nangangailangan ng 16 GB at 240 GB, dahil hindi lumiit ang platform base at nagdaragdag ang bawat app ng Docker image, database, at sarili nitong data. Mas mabilis mapuno ang disk kaysa sa inaasahan ng marami: pinaghahatian ng images, app data, at local backups ang iisang volume hanggang ilipat mo sa labas ng server ang backups.

Nagbibigay ang Cloudron sa bawat app ng unlimited swap, kaya RAM lamang ang saklaw ng memory limit na itinatakda mo. Sa isang VPS image na walang swap file, walang inilalabas ang swapon --show, at ang memory pressure ay direktang nagiging OOM restarts sa halip na mabagal na app. Murang dagdag na insurance ang pagdaragdag ng 2 GB na swap, pero hindi nito mapapalitan ang totoong memory. Maliit ang agwat ng mga VPS plan kumpara sa mga oras na gugugulin mo sa pag-tune ng limits, kaya tingnan kung magkano talaga ang isang VPS at piliin ang susunod na mas malaking size.

DNS: ang wildcard record na nagpapagana sa app subdomains

Inilalagay ng Cloudron ang dashboard sa my.example.com at ang bawat app sa sarili nitong subdomain, kaya prerequisite ang DNS at hindi ito dapat ipagpaliban. Ituro ang mga record na ito sa public IP address ng server bago mo buksan ang dashboard sa unang pagkakataon:

• my.example.com bilang A record. Ito ang dashboard.
• *.example.com bilang A record. Ito ang nagpapagana sa app subdomains, kaya awtomatikong magre-resolve ang wiki.example.com at git.example.com kapag na-install mo ang mga app na iyon.
• example.com bilang A record, kung gusto mong magpatakbo ng app sa bare domain.

Mas mababa ang precedence ng wildcard record kaysa sa explicit record, kaya patuloy na gagana ang kasalukuyang www.example.com kung iba ang tinutukoy nitong lokasyon.

Sa setup, pipiliin mo kung paano hahawakan ng Cloudron ang DNS pagkatapos nito:

• Isang API provider. Nag-iimbak ang Cloudron ng token para sa Cloudflare, DigitalOcean, Route53, Hetzner, Porkbun, Linode, deSEC, Gandi, Namecheap at humigit-kumulang dalawampu pang provider, pagkatapos ay ito mismo ang nagsusulat ng bawat record, kasama ang mail records.
• Wildcard. Ikaw ang manu-manong nagdaragdag ng * record at walang isinusulat ang Cloudron.
• Manual. Ipinapakita ng Cloudron ang bawat record at naghihintay itong idagdag mo ang mga ito bago ang bawat pag-install ng app.

Hindi kapareho ng wildcard certificate ang wildcard DNS record. Ang default certificate provider ay Let's Encrypt Prod - Wildcard. Pinatutunayan nito ang ownership sa pamamagitan ng DNS, kaya gumagana lamang ito kapag API provider ang pinili. Sa Wildcard o Manual backend, gagamit ka ng tig-isang certificate para sa bawat app na nabe-validate sa HTTP. Ibig sabihin, kailangang manatiling bukas ang inbound port 80. Kung nasa API list ang registrar o DNS host mo, gamitin ito. Hindi mo na kailangang ikaw ang mamahala sa mail records at certificates.

Mag-verify bago magpatuloy. Dapat parehong i-print ng dig +short my.example.com at dig +short anything.example.com ang IP address ng server mo. Kung walang inilalabas ang wildcard query, magfa-fail ang mga app sa bandang huli kahit maayos na gumagana ang dashboard.

Kung nasa likod ng Cloudflare ang domain, itakda ang mga record bilang DNS only. HTTP at HTTPS lamang ang ipinapasa ng proxy. Dahil dito, masisira ang mail ports at Cloudflare address ang makikita ng bawat app sa halip na address ng bisita.

Patakbuhin ang setup script

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

Patakbuhin ito bilang root o gamit ang sudo, dahil kung hindi, ang unang ipi-print nito ay This script should be run as root.. Tumatagal nang ilang minuto ang pag-install at tahimik itong tumatakbo habang ginagawa ang trabaho nito, dahil napupunta sa isang log file ang apt output at Docker pulls. I-monitor ito mula sa pangalawang SSH session:

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

Sa pagtatapos, ipi-print nito ang After reboot, visit one of the following URLs and accept the self-signed certificate to finish setup. na sinusundan ng address ng iyong server, at pagkatapos ay itatanong ang The server has to be rebooted to apply all the settings. Reboot now ? [Y/n]. Sagutin ito ng yes. May --skip-reboot flag kung kailangan mong i-schedule ang restart, pero hindi magagamit ang Cloudron hangga't hindi muling bumabalik online ang server.

Unang boot: domain, DNS backend at admin account

Buksan ang https://<server-ip> at tanggapin ang browser warning. Self-signed ang certificate dahil hindi pa alam ng Cloudron ang domain mo, kaya wala pa itong mahingan ng certificate authority. Sa Chrome, i-click ang Advanced, pagkatapos ang Proceed to <ip> (unsafe). Sa Firefox, i-click ang Advanced, pagkatapos ang Accept the Risk and Continue.

Hinihingi ng unang screen ang domain mo. Ilagay ang example.com at mapupunta ang dashboard sa my.example.com. Maaari ka ring gumamit ng subdomain gaya ng cloudron.example.com, at mapupunta ang dashboard sa my.cloudron.example.com. Piliin ang DNS backend, i-paste ang API token kung mayroon ka, at gawin ang admin account gamit ang email address na regular mong binabasa: ito ang gagamitin sa pagpaparehistro sa Let's Encrypt at sa lahat ng alert mula sa platform.

Kapag nag-save ka, hihingi ang Cloudron ng mga certificate at ililipat ang dashboard sa https://my.example.com. Hindi na gagana ang URL na gumagamit ng IP address, kaya i-bookmark ang bago.

Mga certificate: ano ang nagre-renew at kailan ito humihinto

Awtomatiko ang pag-renew ng certificate at sumusunod ito sa ACME Renewal Information (ARI), ang schedule na inilalathala ng certificate authority. Sa aktuwal, karaniwan itong nagre-renew mga isang buwan bago ang expiration. Kapag nabigo ang pag-renew, magpapadala ng email sa admin account. Kapag nag-expire ang certificate, gagamitin ang built-in self-signed certificate. Ito ang dahilan kung bakit may browser warning sa site na gumagana pa noong nakaraang araw.

Dalawang dahilan ang responsable sa karamihan ng mga problema. Kailangan ng HTTP validation ang inbound port 80. Kaya kapag isinara ang 80 dahil “HTTPS naman ang lahat,” masisira ang renewal para sa bawat app na gumagamit ng Wildcard o Manual DNS backend. Kailangan naman ng DNS validation ng API token na mayroon pa ring write access. Kaya kapag ni-rotate o nilimitahan ang token, tahimik na masisira ang renewal hanggang matanggap ang warning email.

May Renew All button ang Domains view para piliting simulan agad ang pagtatangka. Mayroon din itong Let's Encrypt Staging provider para sa testing. Sadyang hindi pinagkakatiwalaan ng mga browser ang mga Staging certificate. Iyon ang layunin nito: maaari kang mag-retry nang kahit ilang beses nang hindi nauubos ang production rate limit.

Dapat mo bang gamitin ang built-in mail server?

May kumpletong mail stack ang Cloudron na may IMAP mailboxes, submission, sieve filters, at DKIM (domainkeys identified mail) signing. I-enable ito para sa bawat domain sa ilalim ng Email sa dashboard. Ang mahirap ay ang matagumpay na pag-deliver ng mail, at hindi Cloudron ang pinagmumulan ng mga limitasyong ito.

• Bina-block ng karamihan sa mga VPS provider ang outbound port 25 bilang kontrol sa spam. May ilang nag-a-unblock nito kapag nagsumite ka ng support ticket. Mag-test mula sa server gamit ang nc -zv aspmx.l.google.com 25 (i-install ang netcat-openbsd kung wala ang command). Iniuulat ng open ports ang succeeded, at ang blocked port ay mananatiling nagha-hang hanggang mag-time out.
• Ang PTR record (reverse DNS) ay sine-set ng VPS provider, hindi ng DNS host, at kailangan itong tumugma sa mail hostname. Ang mail mula sa address na may generic na PTR ay napupunta sa spam folder.
• Awtomatikong ginagawa ang SPF, DKIM, at DMARC records kapag API DNS backend ang gamit. Sa Wildcard o Manual backend, ikaw ang manu-manong nagdadagdag ng mga ito. Kapag nawawala ang DKIM record, hindi mabe-verify ang bawat mensaheng sine-sign mo.

Para sa karamihan, ang setup na gumagana ay tumanggap ng mail sa Cloudron at magpadala gamit ang relay gaya ng SendGrid, Postmark, Mailgun, o Amazon SES, na kino-configure sa Email view. Kailangan payagan ng relay ang pagpapadala bilang anumang address sa domain mo. Kung hindi, mare-reject ang app notifications mula sa magkakaibang sender. Kung mail ang pangunahing dahilan kung bakit bibili ka ng server, magpatakbo ng dedicated mail server gaya ng Mailcow sa sarili nitong box na may sarili nitong IP reputation.

Kung hindi mo gagamitin ang Cloudron Email, i-block ang ports 25, 465, 587, 993, at 4190 sa firewall ng provider mo. Doon ito gawin, hindi sa server, dahil ang Cloudron ang awtomatikong sumusulat ng iptables rules at inaasahang ito ang may kontrol sa mga iyon. Kabaligtaran ito ng plain VPS, kung saan ikaw ang nagma-manage ng ufw rules.

I-configure ang backup target bago mo ito kailanganin

Naka-default ang backups sa local filesystem sa /var/backups, sa parehong disk na ginagamit ng lahat ng iba pa. Malinaw ang dokumentasyon tungkol dito: "Mapanganib kapag nasa parehong physical disk ng platform server ang backups." Isang sirang disk lang at sabay mawawala ang apps at backups.

Buksan ang Backups, pagkatapos ay Backup Sites, at ituro ito sa ibang lokasyon sa unang araw pa lang. Karaniwang ginagamit ang S3-compatible object storage (Backblaze B2, Wasabi, Cloudflare R2, DigitalOcean Spaces, o isang MinIO bucket sa pangalawang server). Sinusuportahan din ang SSHFS, NFS, CIFS, at plain filesystem targets.

Tatlong setting ang nagtatakda kung kapaki-pakinabang ang backup na iyon:

• Format. Ang tgz ay nagsusulat ng isang compressed archive para sa bawat app at muling ina-upload ang buong archive sa bawat run. Ang rsync ay mga binagong file lamang ang ina-upload, kaya mas mura ito para sa malaking Nextcloud, kapalit ng mas maraming request sa storage API.
• Encryption. Opsyonal na AES-256 na sumasaklaw sa file contents at filenames. Walang kopya ng password ang Cloudron, kaya kapag nawala ito, walang makakapag-decrypt ng backups, pati ikaw. I-store ito sa isang self-hosted password manager bago mo i-click ang save.
• Retention. Isinusulat ito bilang mga bilang gaya ng 7 daily at 4 weekly. Bawat buwan kang sisingilin ng mahahabang retention period sa object storage, kaya pumili ng bilang na handa mong patuloy na bayaran.

Pagkatapos, subukan ang restore. Mag-install ng maliit na app, i-restore ito mula sa dashboard, at obserbahan kung bumalik ito kasama ang data nito. Ang backup na hindi pa kailanman na-restore ay hula lamang.

Mga limitasyon ng free tier

As of August 2026, hanggang dalawang naka-install na app ang pinapayagan ng free plan. Kasama na ang lahat ng iba pa: app updates, backup ng bawat app, firewall, mail server, at single sign-on. Sa ikatlong app mo na kakailanganin ng licence. Inaalis ng paid plans ang app limit, at nagdaragdag ang mas mataas na plan ng user groups at roles, directory server, at maraming backup site. Nagbabago ang mga presyo, kaya tingnan ang Cloudron pricing page sa halip na umasa sa numerong nasa isang tutorial.

Sinasaklaw ng isang licence ang isang Cloudron install, kaya doble ang gastos ng dalawang maliit na server kumpara sa isang mas malaking server. Dahil dito, karamihan ay gumagamit ng isang mas malaking VPS, na salungat sa karaniwang payo na ipamahagi ang mga serbisyo sa maraming machine. Isaalang-alang ito sa pag-size ng server, dahil ang paghahati sa mga machine sa hinaharap ay mangangahulugan ng dobleng gastos.

Kapag may hindi gumana

Magsimula sa built-in check. Sinusuri nito nang sunod-sunod ang DNS, certificates, disk, memory, at bawat service, at ipinapakita kung aling test ang nag-fail:

sudo cloudron-support --troubleshoot

Pagkatapos, gamitin ang karaniwang systemd (system and service manager) tools. Ipinapakita ng systemctl status box ang status ng Cloudron service mismo, ibinibigay ng journalctl -u box -n 100 ang mga kamakailang log nito, at sinasaklaw ng journalctl -u docker ang container runtime na nasa ilalim nito. Nananatili sa /var/log/cloudron-setup.log ang anumang naging problema habang nag-i-install.

Ang dashboard na hindi naglo-load ay karaniwang problema sa DNS o sa firewall ng provider, hindi sa Cloudron. Patakbuhin ang dig +short my.example.com mula sa iyong laptop at tiyaking bukas ang ports 80 at 443 sa network firewall ng provider. Hiwalay itong control sa sariling rules ng server. Kung magsisimula ka ulit, tatanggihan ng script ang pangalawang pagpapatakbo gamit ang Error: Cloudron is already installed. To reinstall, start afresh. Ang pinakamalinis na solusyon ay ang gumawa ng bagong server.

Kapag hindi angkop ang Cloudron

Ang Cloudron ay angkop kung mga application ang gusto mong patakbuhin, hindi infrastructure. Hindi ito gaanong angkop kung gusto mong patakbuhin ang sarili mong containers sa sarili mong paraan, dahil ito ang namamahala sa nginx, Docker, at firewall, at mao-overwrite nito ang mga inilagay mo roon. Kung ang plano mo ay isang folder ng compose files, ibinibigay ng Traefik sa harap ng sarili mong Docker Compose stacks ang parehong automatic TLS at subdomain routing nang walang platform na nakapatong dito. Kung hindi ka pa nakakapili, magkatabing inihahambing ng paghahambing ng Cloudron, CasaOS, at Coolify ang mga ito, at mas magandang panimulang lugar kaysa install guide ang mas malawak na listahan ng mga maaaring i-self-host.

FAQ

Gaano karaming RAM ang kailangan ng Cloudron sa isang VPS?

Tumangging tumakbo ang setup script kapag mas mababa sa 941 MB ang RAM, at 2 GB ang hinihingi ng documentation. Gayunman, minimum requirement lamang ito para sa platform na walang app. Mula sa unang boot, nagpapatakbo ang Cloudron ng Docker, nginx, sarili nitong box service, database containers, at mail stack. Maglaan ng 4 GB para sa dalawang app at 16 GB para sa humigit-kumulang sampung app. Magdagdag din ng swap file dahil binibigyan ng Cloudron ng unlimited swap ang mga app nito. Kapag walang swap ang server, maaaring mauwi ang memory pressure sa pag-restart ng mga app.

Maaari ko bang i-install ang Cloudron sa Debian o sa server na nagpapatakbo na ng Docker?

Hindi gagana ang alinman sa dalawang setup. Sinusuri ng script ang release at humihinto kapag may Cloudron requires Ubuntu 20.04, 22.04, 24.04, kaya hindi suportado ang Debian, Rocky, at Alpine. Humihinto rin ito kapag mayroon nang nginx, docker, o node dahil nag-i-install ang Cloudron ng pinned versions ng lahat ng ito at sarili nitong nagsusulat ng nginx configuration at iptables rules. Magsimula sa isang fresh Ubuntu image sa KVM VPS.

Bakit hindi gumagana ang mga app subdomain ko habang gumagana ang dashboard?

Nawawala ang wildcard DNS record. Gumagawa o nangangailangan ang setup ng A record para sa my.example.com, kaya nareresolve ang dashboard. Samantala, nagbabalik ang wiki.example.com ng NXDOMAIN at ipinapakita ng browser na hindi mahanap ang site. Magdagdag ng A record para sa *.example.com na nakaturo sa server IP. Pagkatapos, kumpirmahin ito gamit ang dig +short wiki.example.com bago i-install ang app.

Kailangan ko bang gamitin ang mail server ng Cloudron?

Hindi. Maaari mong i-disable ang incoming email at gumamit ng external relay gaya ng Postmark, Mailgun, o Amazon SES. Mas ligtas ito kapag bina-block ng provider mo ang outbound port 25 o walang mail reputation ang IP address. Kung hindi mo gagamitin ang Cloudron Email, isara ang ports 25, 465, 587, 993, at 4190 sa provider firewall, hindi sa server.

Ano ang mangyayari kapag naabot ko ang limitasyong dalawang app sa free plan?

Hinaharangan ng dashboard ang pag-install ng ikatlong app at humihingi ito ng licence key. Hindi naaapektuhan ang mga app na tumatakbo na: patuloy silang nag-u-update, bina-back up, at pinapanatili ang kanilang certificates. Kapag nagdagdag ka ng licence, maaalis ang limitasyon nang hindi kinakailangang mag-reinstall. Kaya makatuwirang paraan ang free plan para subukan muna ang platform sa isang totoong domain.