Cara Pasang Cloudron pada VPS Ubuntu Langkah Demi Langkah

Memasang Cloudron pada VPS: versi ringkas

Untuk memasang Cloudron pada VPS, anda memerlukan pelayan Ubuntu yang bersih, sekurang-kurangnya 2 GB RAM, dan domain yang rekod DNS-nya boleh anda sunting. Proses pemasangan itu sendiri hanya melibatkan tiga arahan dan satu but semula. Hampir semua masalah yang berlaku berpunca sebelum langkah tersebut (imej asas yang salah, jenis virtualisasi yang salah) atau selepasnya (DNS, e-mel, sandaran).

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

Cloudron memasang, mengemas kini, membuat sandaran, dan mengeluarkan sijil TLS (transport layer security) untuk aplikasi yang dihoskan sendiri. Setiap aplikasi berjalan dalam Docker, Nginx diletakkan di hadapan kesemuanya, dan setiap aplikasi mendapat subdomain sendiri bagi domain anda. Butiran terakhir itulah sebabnya kerja DNS dilakukan terlebih dahulu di sini.

Mengapa Cloudron cerewet tentang OS asas

Skrip penyediaan memeriksa pelayan sebelum memasang apa-apa, dan kegagalan dalam pemeriksaan bermakna anda perlu memesan pelayan baharu. Baca syarat ini sebelum anda memilih imej.

• Hanya Ubuntu, dan hanya tiga keluaran. Apa-apa selain daripada itu akan keluar dengan Cloudron requires Ubuntu 20.04, 22.04, 24.04. Debian, Rocky dan Alpine tidak disokong. Ubuntu 24.04 memerlukan Cloudron 8 atau lebih baharu, dan skrip tersebut akan memeriksanya untuk anda.
• Hanya Intel atau AMD 64-bit: Error: Cloudron only supports amd64/x86_64. VPS ARM tidak boleh menjalankannya.
• Hanya virtualisasi perkakasan penuh. Pada VPS berasaskan kontena, skrip akan berhenti dengan Error: Cloudron does not support lxc, only runs on bare metal or with full hardware virtualization, kerana ia mengesan kontena tersebut dengan systemd-detect-virt --container. KVM adalah sesuai. OpenVZ dan LXC tidak.
• Sistem fail root mestilah ext4 atau xfs. Pada sistem lain, anda akan mendapat Error: Cloudron requires '/' to be ext4 or xfs, iaitu punca kegagalan imej btrfs dan zfs.
• Sekurang-kurangnya 941 MB RAM dan 20 GB pada /, diukur dengan free -m dan saiz sistem fail root.
• Pelayan yang benar-benar baharu. Jika nginx, docker atau node sudah dipasang, skrip akan menolak dengan Error: Some packages like nginx/docker/nodejs are already installed..

Pemeriksaan terakhir itulah yang sering dipertikaikan oleh pengguna, jadi inilah sebabnya. Cloudron memasang versi Docker, nginx, Node.js dan MySQL yang ditetapkan, menulis konfigurasi nginx untuk setiap aplikasi yang dihoskan, dan mengurus peraturan firewall iptables sendiri. Docker yang anda pasang semalam adalah versi yang salah, dan fail tapak nginx sedia ada anda akan diganti. Cloudron menguasai keseluruhan mesin, jadi berikan ia VPS yang khusus.

Satu lagi pemeriksaan yang mudah terlepas pandang. Pada CPU lama tanpa AVX (advanced vector extensions), skrip akan mencetak CPU has no AVX support. MongoDB will be disabled, dan setiap aplikasi yang memerlukan MongoDB tidak boleh dipasang. Periksa CPU sebelum anda membuat keputusan dengan grep -m1 -o avx /proc/cpuinfo, yang akan mencetak avx pada hos yang berkemampuan dan tidak mengeluarkan apa-apa pada hos yang lama.

Berapakah RAM yang diperlukan oleh Cloudron?

Skrip pemasangan akan menolak untuk dijalankan jika RAM kurang daripada 941 MB, dengan Error: Cloudron requires atleast 1GB physical memory, dan dokumentasi menetapkan keperluan minimum sebanyak 2 GB RAM serta 20 GB ruang cakera. Kedua-dua angka ini adalah had minimum untuk platform tersebut, bukan untuk platform berserta aplikasi anda. Sebelum anda memasang walau satu aplikasi pun, Cloudron sudah menjalankan Docker, nginx, perkhidmatan box miliknya sendiri, kontena pangkalan data yang disediakan untuk aplikasi (MySQL, PostgreSQL, MongoDB), Redis, dan timbunan mel. Jalankan docker ps pada pemasangan baharu dan kira jumlahnya.

Had memori aplikasi adalah tambahan kepada beban asas tersebut. Setiap pakej aplikasi disertakan dengan had lalai yang rendah dan anda boleh meningkatkannya menggunakan peluncur dalam paparan Resources aplikasi tersebut. Apabila sesuatu aplikasi melepasi hadnya, ia akan dimulakan semula dan menghantar pemberitahuan OOM (out of memory) kepada anda. Oleh itu, pelayan yang sentiasa memulakan semula satu aplikasi biasanya berpunca daripada masalah had memori, bukannya pepijat.

Berikut adalah spesifikasi yang saya cadangkan. Ini adalah saranan untuk pelayan yang tidak perlu anda bina semula pada bulan hadapan. Ini bukanlah hasil penanda aras yang diukur secara saintifik.

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

Dua aplikasi boleh berjalan dengan selesa pada 4 GB RAM dan 60 GB ruang cakera. Sekitar sepuluh aplikasi memerlukan 16 GB RAM dan 240 GB ruang cakera, kerana beban asas platform tidak akan berkurangan dan setiap aplikasi menambah imej Docker, pangkalan data, serta datanya sendiri. Ruang cakera penuh lebih cepat daripada jangkaan: imej, data aplikasi, dan sandaran tempatan berkongsi satu volum yang sama sehingga anda memindahkan sandaran keluar dari pelayan tersebut.

Cloudron memberikan setiap aplikasi swap tanpa had, jadi had memori yang anda tetapkan hanya terpakai pada RAM sahaja. Pada imej VPS yang tidak mempunyai fail swap, swapon --show tidak akan memaparkan apa-apa, dan tekanan memori akan terus menyebabkan aplikasi dimulakan semula akibat OOM dan bukannya menjadi perlahan. Menambah 2 GB swap adalah langkah perlindungan yang murah, walaupun ia tidak menggantikan memori sebenar. Perbezaan harga antara pelan VPS adalah kecil berbanding masa yang akan anda habiskan untuk melaraskan had memori, jadi lihat kos sebenar VPS dan beli pelan yang lebih tinggi.

DNS: rekod wildcard yang membolehkan subdomain aplikasi berfungsi

Cloudron meletakkan papan pemuka pada my.example.com dan setiap aplikasi pada subdomainnya sendiri, jadi DNS adalah prasyarat dan bukannya langkah terkemudian. Halakan rekod-rekod ini ke alamat IP awam pelayan sebelum anda membuka papan pemuka buat kali pertama:

• my.example.com sebagai rekod A. Ini ialah papan pemuka.
• *.example.com sebagai rekod A. Ini adalah rekod yang membolehkan subdomain aplikasi berfungsi, supaya wiki.example.com dan git.example.com diselesaikan sebaik sahaja anda memasang aplikasi tersebut.
• example.com sebagai rekod A, hanya jika anda mahukan aplikasi pada domain asas.

Rekod wildcard mempunyai keutamaan yang lebih rendah daripada rekod eksplisit, jadi www.example.com sedia ada yang menghala ke tempat lain akan terus berfungsi.

Semasa persediaan, anda memilih cara Cloudron mengendalikan DNS selepas itu:

• Penyedia API. Cloudron menyimpan token untuk Cloudflare, DigitalOcean, Route53, Hetzner, Porkbun, Linode, deSEC, Gandi, Namecheap dan kira-kira dua puluh yang lain, kemudian menulis setiap rekod sendiri, termasuk rekod mel.
• Wildcard. Anda menambah rekod * secara manual dan Cloudron tidak menulis apa-apa.
• Manual. Cloudron menunjukkan setiap rekod kepada anda dan menunggu sementara anda menambahnya, sebelum setiap pemasangan aplikasi.

Rekod DNS wildcard bukanlah sijil wildcard. Penyedia sijil lalai ialah Let's Encrypt Prod - Wildcard, yang membuktikan pemilikan melalui DNS, jadi ia hanya berfungsi dengan penyedia API. Pada backend Wildcard atau Manual, anda kembali kepada satu sijil bagi setiap aplikasi yang disahkan melalui HTTP, yang bermaksud port 80 masuk perlu kekal terbuka selama-lamanya. Jika pendaftar atau hos DNS anda berada dalam senarai API, gunakannya: rekod mel dan sijil kedua-duanya tidak lagi menjadi tugas anda.

Sahkan sebelum anda pergi lebih jauh. dig +short my.example.com dan dig +short anything.example.com kedua-duanya harus memaparkan alamat IP pelayan anda. Jika pertanyaan wildcard tidak memaparkan apa-apa, aplikasi akan gagal kemudian manakala papan pemuka berfungsi dengan baik.

Jika domain berada di belakang Cloudflare, tetapkan rekod kepada DNS sahaja. Proksi hanya menghantar trafik HTTP dan HTTPS, jadi port mel akan terputus, dan setiap aplikasi akan melihat alamat Cloudflare dan bukannya alamat pelawat.

Jalankan skrip persediaan

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

Jalankan skrip ini sebagai root atau melalui sudo, kerana perkara pertama yang akan dipaparkan jika tidak berbuat demikian ialah This script should be run as root.. Proses pemasangan mengambil masa beberapa minit dan berjalan secara senyap, memandangkan output apt dan Docker pull disalurkan ke fail log. Pantau proses tersebut daripada sesi SSH kedua:

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

Pada penghujungnya, skrip akan memaparkan After reboot, visit one of the following URLs and accept the self-signed certificate to finish setup. diikuti dengan alamat pelayan anda, kemudian bertanya The server has to be rebooted to apply all the settings. Reboot now ? [Y/n]. Jawab yes. Flag --skip-reboot tersedia jika anda perlu menjadualkan semula proses but semula, namun Cloudron tidak boleh digunakan sehingga pelayan selesai dihidupkan semula.

But pertama: domain, backend DNS dan akaun pentadbir

Buka https://<server-ip> dan terima amaran pelayar. Sijil tersebut ditandatangani sendiri kerana Cloudron belum mengenali domain anda, jadi ia tidak mempunyai maklumat untuk diminta daripada pihak berkuasa sijil. Dalam Chrome, klik Advanced, kemudian Proceed to <ip> (unsafe). Dalam Firefox, klik Advanced, kemudian Accept the Risk and Continue.

Skrin pertama meminta domain anda. Masukkan example.com dan papan pemuka akan ditetapkan pada my.example.com. Anda boleh menggunakan subdomain seperti cloudron.example.com sebagai ganti, dan papan pemuka akan berada pada my.cloudron.example.com. Pilih backend DNS, tampal token API jika anda mempunyainya, dan cipta akaun pentadbir dengan alamat e-mel yang anda benar-benar baca: pendaftaran Let's Encrypt dan setiap makluman platform akan menggunakan alamat tersebut.

Apabila anda menyimpan, Cloudron akan meminta sijil dan memindahkan papan pemuka ke https://my.example.com. URL alamat IP akan berhenti berfungsi pada ketika itu, jadi simpan URL baharu tersebut sebagai penanda buku.

Sijil: perkara yang diperbaharui, dan bila ia berhenti

Pembaharuan sijil adalah automatik dan mengikut ACME Renewal Information (ARI), iaitu jadual yang diterbitkan oleh pihak berkuasa sijil. Secara praktikal, pembaharuan berlaku kira-kira sebulan sebelum tarikh luput. Kegagalan pembaharuan akan menghantar e-mel kepada akaun pentadbir, dan sijil yang telah luput akan kembali menggunakan sijil self-signed terbina dalam. Kegagalan fungsi ini adalah punca sebenar amaran pelayar pada laman web yang berfungsi dengan baik semalam.

Dua punca menyumbang kepada kebanyakan masalah ini. Pengesahan HTTP memerlukan port 80 masuk, jadi menutup port 80 dengan alasan "semuanya sudah HTTPS" akan memutuskan pembaharuan bagi setiap aplikasi pada backend Wildcard atau DNS Manual. Pengesahan DNS memerlukan token API yang masih mempunyai akses tulis, jadi menukar atau mengehadkan skop token tersebut akan menyebabkan pembaharuan gagal secara senyap sehingga e-mel amaran tiba.

Paparan Domains mempunyai butang Renew All untuk memaksa percubaan dilakukan serta-merta, dan penyedia Let's Encrypt Staging untuk tujuan ujian. Sijil Staging sengaja tidak dipercayai oleh pelayar, dan itulah tujuannya: anda boleh mencuba semula sekerap yang anda mahu tanpa menghabiskan had kadar pengeluaran (production rate limit).

Patutkah anda menggunakan pelayan e-mel terbina dalam?

Cloudron membekalkan timbunan e-mel lengkap dengan peti mel IMAP, penyerahan, penapis sieve dan penandatanganan DKIM (domainkeys identified mail). Anda boleh mendayakannya bagi setiap domain di bawah Email dalam papan pemuka. Bahagian yang sukar ialah memastikan e-mel dihantar, dan kesukaran ini bukan berpunca daripada Cloudron.

• Port keluar 25 disekat oleh kebanyakan penyedia VPS sebagai kawalan spam. Sesetengah penyedia akan menyahsekatnya selepas anda menghantar tiket sokongan. Uji daripada pelayan dengan nc -zv aspmx.l.google.com 25 (pasang netcat-openbsd jika arahan tersebut tiada). Port yang terbuka akan melaporkan succeeded, manakala port yang disekat akan tergantung sehingga tamat tempoh.
• Rekod PTR (DNS berbalik) ditetapkan oleh penyedia VPS anda, bukan oleh hos DNS anda, dan ia mestilah sepadan dengan nama hos e-mel. E-mel daripada alamat dengan PTR generik akan masuk ke dalam folder spam.
• Rekod SPF, DKIM dan DMARC ditulis untuk anda pada backend DNS API. Pada backend Wildcard atau Manual, anda perlu menambahnya secara manual, dan rekod DKIM yang tiada bermakna setiap mesej yang anda tandatangani tidak dapat disahkan.

Persediaan yang berkesan untuk kebanyakan orang ialah menerima e-mel pada Cloudron dan menghantarnya melalui relay seperti SendGrid, Postmark, Mailgun atau Amazon SES, yang dikonfigurasikan dalam paparan Email. Relay tersebut mestilah membenarkan penghantaran sebagai mana-mana alamat pada domain anda, jika tidak, pemberitahuan aplikasi daripada penghantar yang berbeza akan ditolak. Jika e-mel adalah sebab utama anda membeli pelayan, jalankan pelayan e-mel khusus seperti Mailcow pada mesinnya sendiri dengan reputasi IPnya sendiri.

Jika anda tidak menggunakan Cloudron Email sama sekali, sekat port 25, 465, 587, 993 dan 4190 dalam firewall penyedia anda. Lakukan di sana dan bukan pada pelayan, kerana Cloudron menulis peraturan iptables sendiri dan menjangkakan untuk menguruskannya. Ini berbeza dengan VPS biasa, di mana anda mengurus peraturan ufw sendiri.

Konfigurasikan sasaran sandaran sebelum anda memerlukannya

Sandaran ditetapkan secara lalai ke sistem fail tempatan di /var/backups, pada cakera yang sama dengan segala-galanya. Dokumentasinya menyatakan dengan jelas: "Menyimpan sandaran pada cakera fizikal yang sama dengan pelayan platform adalah berbahaya." Satu cakera yang gagal akan melenyapkan aplikasi dan sandaran serentak.

Buka Backups, kemudian Backup Sites, dan halakan ia ke lokasi lain pada hari pertama. Storan objek yang serasi dengan S3 adalah pilihan biasa (Backblaze B2, Wasabi, Cloudflare R2, DigitalOcean Spaces, atau bucket MinIO pada pelayan kedua), dan SSHFS, NFS, CIFS serta sasaran sistem fail biasa juga disokong.

Tiga tetapan menentukan sama ada sandaran itu berguna:

• Format. tgz menulis satu arkib termampat bagi setiap aplikasi dan memuat naik semula keseluruhan fail pada setiap pelaksanaan. rsync hanya memuat naik fail yang berubah, yang jauh lebih murah untuk Nextcloud yang besar, dengan kos permintaan yang lebih banyak terhadap API storan.
• Penyulitan. AES-256 pilihan yang meliputi kandungan fail dan nama fail. Cloudron tidak menyimpan salinan kata laluan, jadi jika ia hilang, sandaran tidak boleh dinyahsulit oleh sesiapa pun, termasuk anda. Simpan ia dalam pengurus kata laluan yang dihoskan sendiri sebelum anda menekan simpan.
• Pengekalan. Ditulis sebagai kiraan seperti 7 harian dan 4 mingguan. Pengekalan yang lama pada storan objek akan mengenakan caj setiap bulan, jadi pilih nombor yang anda sanggup bayar.

Kemudian, uji pemulihan. Pasang aplikasi kecil, pulihkan ia daripada papan pemuka, dan lihat ia kembali dengan datanya. Sandaran yang tidak pernah dipulihkan oleh sesiapa hanyalah satu andaian.

Had had bagi pelan percuma

Setakat Ogos 2026, pelan percuma dihadkan kepada dua aplikasi yang dipasang. Semua ciri lain disertakan: kemas kini aplikasi, sandaran bagi setiap aplikasi, firewall, pelayan mel dan single sign-on. Aplikasi ketiga ialah titik di mana anda memerlukan lesen. Pelan berbayar membuang had aplikasi, dan pelan yang lebih tinggi menambah kumpulan pengguna dan peranan, pelayan direktori serta berbilang tapak sandaran. Harga sentiasa berubah, jadi semak halaman harga Cloudron dan bukannya bergantung pada angka dalam tutorial.

Satu lesen meliputi satu pemasangan Cloudron, jadi dua pelayan kecil menelan kos dua kali ganda berbanding satu pelayan yang lebih besar. Struktur harga tersebut mendorong kebanyakan pengguna untuk menggunakan satu VPS yang lebih besar, yang bertentangan dengan nasihat biasa untuk menyebarkan servis merentasi pelbagai mesin. Tentukan saiz pelayan dengan mengambil kira perkara ini, kerana memisahkan servis kemudian hari bermakna anda perlu membayar dua kali ganda.

Apabila berlaku kerosakan

Mulakan dengan pemeriksaan terbina dalam. Ia menyemak DNS, sijil, cakera, memori dan setiap servis secara bergilir, kemudian melaporkan ujian yang gagal:

sudo cloudron-support --troubleshoot

Selepas itu, gunakan alatan systemd (pengurus sistem dan servis) yang biasa. systemctl status box melaporkan status servis Cloudron itu sendiri, journalctl -u box -n 100 memaparkan log terkini, dan journalctl -u docker merangkumi runtime kontena di bawahnya. Sebarang masalah yang berlaku semasa pemasangan disimpan dalam /var/log/cloudron-setup.log.

Papan pemuka yang tidak dimuatkan biasanya berpunca daripada DNS atau firewall penyedia, bukannya Cloudron. Jalankan dig +short my.example.com daripada komputer riba anda dan sahkan bahawa port 80 dan 443 terbuka dalam firewall rangkaian penyedia, yang merupakan kawalan berasingan daripada peraturan pelayan itu sendiri. Jika anda ingin memulakan semula, skrip akan menolak pelaksanaan kali kedua dengan Error: Cloudron is already installed. To reinstall, start afresh, dan membina semula pelayan adalah penyelesaian yang bersih.

Apabila Cloudron bukan pilihan yang tepat

Cloudron sesuai jika anda mahukan aplikasi dan bukannya infrastruktur. Ia tidak sesuai jika anda mahu menjalankan kontena sendiri mengikut cara anda, kerana ia mengawal Nginx, Docker dan firewall, serta akan menulis ganti sebarang perubahan yang anda buat di situ. Jika rancangan anda adalah menggunakan folder fail compose, Traefik di hadapan stack Docker Compose anda sendiri memberikan anda TLS automatik dan penghalaan subdomain yang sama tanpa platform tambahan di atasnya. Jika anda belum membuat pilihan, perbandingan Cloudron, CasaOS dan Coolify meletakkan kesemuanya bersebelahan, dan senarai lebih luas tentang perkara untuk di-self-host adalah tempat yang lebih baik untuk bermula berbanding panduan pemasangan.

FAQ

Berapakah jumlah RAM yang diperlukan oleh Cloudron pada VPS?

Skrip penyediaan akan berhenti jika RAM kurang daripada 941 MB dan dokumentasi menetapkan 2 GB sebagai keperluan minimum untuk platform tanpa sebarang aplikasi. Cloudron menjalankan Docker, nginx, perkhidmatan box miliknya sendiri, kontena pangkalan data dan tindanan mel (mail stack) sejak but pertama. Peruntukkan 4 GB untuk dua aplikasi dan 16 GB untuk sekitar sepuluh aplikasi, serta tambahkan fail swap. Hal ini kerana Cloudron memberikan swap tanpa had kepada aplikasi, dan pelayan tanpa swap akan menyebabkan aplikasi dimulakan semula apabila berlaku tekanan memori.

Bolehkah saya memasang Cloudron pada Debian, atau pada pelayan yang sudah menjalankan Docker?

Kedua-duanya tidak boleh dilakukan. Skrip akan menyemak keluaran sistem dan berhenti dengan Cloudron requires Ubuntu 20.04, 22.04, 24.04, jadi Debian, Rocky dan Alpine tidak disokong. Ia juga akan berhenti jika nginx, docker atau node sudah tersedia, kerana ia memasang versi yang ditetapkan (pinned versions) untuk kesemuanya serta menulis konfigurasi nginx dan peraturan iptables secara automatik. Mulakan dengan imej Ubuntu yang bersih pada KVM VPS.

Mengapakah subdomain aplikasi saya gagal berfungsi sedangkan papan pemuka (dashboard) boleh diakses?

Rekod DNS wildcard tidak wujud. Penyediaan memerlukan rekod A untuk my.example.com, jadi papan pemuka dapat diselesaikan (resolve), manakala wiki.example.com akan memulangkan ralat NXDOMAIN dan pelayar melaporkan bahawa tapak tidak ditemui. Tambahkan rekod A untuk *.example.com yang menghala ke IP pelayan, kemudian sahkan dengan dig +short wiki.example.com sebelum anda memasang aplikasi tersebut.

Adakah saya wajib menggunakan pelayan mel Cloudron?

Tidak. Anda boleh mematikan fungsi e-mel masuk dan menghantar e-mel melalui relay luaran seperti Postmark, Mailgun atau Amazon SES. Ini adalah pilihan yang lebih selamat apabila pembekal anda menyekat port keluar 25 atau alamat IP anda tidak mempunyai reputasi mel yang baik. Jika anda tidak menggunakan Cloudron Email sepenuhnya, tutup port 25, 465, 587, 993 dan 4190 pada firewall pembekal dan bukannya pada pelayan.

Apakah yang berlaku apabila saya mencapai had dua aplikasi pada pelan percuma?

Papan pemuka akan menyekat pemasangan ketiga dan meminta kunci lesen. Aplikasi yang sedang berjalan tidak akan terjejas: ia akan terus dikemas kini, terus disandarkan dan sijilnya akan terus dikekalkan. Menambah lesen akan membuang had tersebut tanpa perlu memasang semula apa-apa, jadi pelan percuma merupakan cara yang adil untuk menguji platform ini pada domain sebenar terlebih dahulu.