Cloudron vs CasaOS vs Coolify: Mana Pilihan Terbaik?

Apa yang anda sedang bina

Anda sedang memilih alat sama seperti anda memasangnya. Tiga panel menjanjikan untuk mengubah VPS kosong menjadi hos aplikasi yang hanya memerlukan klik: Cloudron, CasaOS, dan Coolify. Panduan ini memasang setiap satunya pada kotak Ubuntu 24.04 yang baharu, memasang aplikasi pertama, kemudian meneliti bahagian yang tidak ditunjukkan dalam tangkapan skrin: TLS, sandaran, kemas kini, kos memori, dan betapa sukarnya untuk berhenti menggunakannya. Menjelang akhir panduan ini, anda akan tahu yang mana satu sesuai, atau sama ada jawapan yang jujur ialah "tiada satu pun, gunakan sahaja Docker Compose."

Tiada satu pun daripada ini adalah magis. Di bawah ketiga-tiganya terdapat Docker Engine yang sama yang boleh anda kendalikan secara manual. Apa yang dijual oleh panel kepada anda, sama ada dalam bentuk wang, RAM, atau penguncian vendor, ialah empat tugas yang dilakukan untuk anda: pemasangan aplikasi satu klik, sijil TLS automatik, sandaran berjadual, dan pengurusan pengguna. Jika empat perkara ini berbaloi dengan overhead yang sebenar bagi anda, maka panel tersebut berbaloi digunakan. Jika anda menjalankan satu atau dua servis dan suka mengetahui dengan tepat apa yang ada pada kotak anda, baca bahagian "Langkau ketiga-tiganya" dahulu dan jimatkan masa anda.

Prasyarat bersama dan perangkap yang perlu diketahui

Ketiga-tiga perisian ini memerlukan VPS KVM, bukan virtualisasi kontena. Docker memerlukan kernel sebenar, dan Cloudron secara jelas menolak OpenVZ serta LXC. Semak dengan systemd-detect-virt: kvm atau qemu adalah memadai, manakala openvz atau lxc tidak sesuai. Pada pelan KVM, arahan tersebut akan memaparkan kvm, dan pada pelayan fizikal (bare metal) ia memaparkan none; mana-mana satu daripadanya bermakna anda boleh meneruskan proses.

Selain itu, keperluan spesifiknya berbeza, dan ini merupakan perkara pertama yang menentukan pilihan anda.

• RAM. CasaOS boleh berjalan dengan lancar pada 1GB; ia dibangunkan pada perkakasan Raspberry Pi dan kekal ringan. Coolify memerlukan sekurang-kurangnya 2GB RAM dan dua teras CPU, dengan kira-kira 600 MB digunakan oleh Coolify sendiri. Cloudron memerlukan minimum 2GB dan berfungsi dengan lebih baik pada 4GB, kerana ia menjalankan pelayan e-mel dan pangkalan data sebelum anda memasang sebarang aplikasi.
• Domain dan DNS yang anda kawal. Cloudron dan Coolify kedua-duanya memerlukan domain sebenar dengan DNS yang berfungsi. Cloudron secara idealnya memerlukan akses API kepada pembekal DNS anda supaya ia boleh mencipta rekod dan sijil wildcard secara automatik. CasaOS boleh berjalan pada alamat IP sahaja, tetapi anda tidak akan mendapat sebarang sokongan TLS.
• Port. Ketiga-tiganya memerlukan port 80 dan 443 dibuka untuk HTTP dan HTTPS. Coolify juga menggunakan port 8000 untuk papan pemuka (dashboard), serta menggunakan 6001 untuk saluran masa nyata dan 6002 untuk terminal dalam pelayar. Pastikan port 22 dibuka untuk SSH pada setiap pelayan tersebut.

Halakan DNS ke pelayan sebelum anda bermula. Panel yang tidak dapat menyelesaikan nama hosnya sendiri tidak akan dapat meminta sijil, dan anda akan menghabiskan masa sejam pertama untuk menyahpepijat masalah tersebut dan bukannya menggunakan perisian itu. Halakan rekod A ke IP pelayan, dan bagi Coolify, tambah rekod wildcard (*.apps.example.com) supaya setiap aplikasi yang digunakan mendapat subdomainnya sendiri.

Cloudron: perkakas yang digilap dan berpendirian tetap

Apakah ia. Cloudron ialah platform komersial yang menukar keseluruhan pelayan menjadi perkakas terurus. Ia menjalankan reverse proxy, pangkalan data, dan mail stack sendiri, serta App Store aplikasi yang disusun rapi (Nextcloud, WordPress, Gitea, Mattermost, dan banyak lagi). Ia menyasarkan pengguna yang mahukan aplikasi mereka diuruskan, dengan kemas kini automatik, sijil automatik, dan sandaran automatik, serta sanggup membayar untuk perkhidmatan tersebut.

Pemasangan. Ia memerlukan pelayan yang bersih dan akan mengambil alih kawalan sepenuhnya. Jalankan ini pada pelayan Ubuntu 24.04 (Noble) yang baharu dan tiada apa-apa lagi:

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

Skrip ini memasang Docker, nginx, pangkalan data dan mail stack, kemudian melakukan but semula. Apabila pelayan kembali aktif, buka https://<your-ip>, terima sijil self-signed sementara, dan selesaikan persediaan dalam pelayar: halakan ia ke domain anda, pilih penyedia DNS anda, dan ia akan menyediakan papan pemuka (dashboard) sendiri di my.example.com.

Menambah aplikasi pertama. Dalam papan pemuka, buka App Store, klik (contohnya) Nextcloud, pilih subdomain files.example.com, dan tekan Install. Cloudron mencipta rekod DNS, meminta sijil Let's Encrypt, menyediakan pangkalan data, menyambungkan single sign-on, dan menjadualkan sandaran, semuanya tanpa anda perlu menyentuh fail konfigurasi. Inilah kelebihan utamanya, dan ia berfungsi dengan baik.

TLS dan sandaran. Paling mantap antara ketiga-tiga pilihan. Setiap subdomain aplikasi mendapat sijil Let's Encrypt automatik yang diperbaharui untuk anda. Sandaran dijadualkan dan terbina dalam, menyasarkan direktori tempatan, S3, atau storan jauh lain, dengan keupayaan pemulihan setiap aplikasi dan juga pengklonan satu klik aplikasi ke subdomain baharu.

Kos dan pelesenan, baca ini sebelum anda komited. Cloudron ialah produk berbayar dengan had tier percuma: pelan percuma membenarkan dua aplikasi. Pasang aplikasi ketiga dan anda akan berhadapan dengan sekatan bayaran; langganan berbayar (Pro atau Max, dibilkan bulanan atau tahunan, kedua-duanya dengan aplikasi tanpa had) membuka lebih banyak ciri. Itu adalah fakta paling penting mengenai Cloudron. Ia digilap dengan teliti kerana ia adalah sebuah perniagaan, dan tier percuma lebih kepada percubaan lanjutan berbanding tempat untuk himpunan aplikasi yang semakin berkembang.

Mod kegagalan, peraturan pelayan bersih. Cuba pasang Cloudron pada pelayan yang sudah menjalankan sesuatu dan persediaan akan terbatal sebelum ia mengubah apa-apa:

Error: Some packages like nginx/docker/nodejs are already installed. Cloudron requires
specific versions of these packages and will install them as part of it's installation.
Please start with a fresh Ubuntu install and run this script again.

Puncanya bukan kerana cerewet tanpa sebab. Cloudron menetapkan versi khusus nginx, Docker dan Node serta mengintegrasikannya secara mendalam, jadi ia tidak boleh wujud bersama salinan anda sendiri. Penyelesaiannya ialah imej Ubuntu 24.04 yang baharu dan tiada apa-apa lagi: tiada pelayan web, tiada Docker, malah tiada firewall yang anda konfigurasikan secara manual. Jika anda memulakan imej yang salah, persediaan juga akan menolak sebarang sistem yang bukan Ubuntu LTS yang disokong (22.04 atau 24.04) pada x86-64; ARM, LXC dan OpenVZ tidak disokong sama sekali.

Mod kegagalan kedua, sijil wildcard memerlukan API DNS. Pilih pilihan DNS "Manual" semasa persediaan dan bukannya memberikan Cloudron token API, maka ia tidak boleh mencipta rekod atau sijil wildcard untuk anda. Setiap aplikasi baharu kemudiannya memaksa anda menambah rekod DNS secara manual sebelum sijil boleh dikeluarkan, dan papan pemuka akan menunggu rekod tersebut. Berikan Cloudron akses API kepada penyedia DNS yang disokong (Cloudflare, Route 53, DigitalOcean, dan lain-lain) dan keseluruhan aliran kerja menjadi satu klik sahaja.

CasaOS: papan pemuka makmal rumah percuma

Apa itu CasaOS. CasaOS, daripada IceWhale, ialah papan pemuka sumber terbuka dan percuma yang beroperasi di atas Docker serta menyediakan skrin utama, gedung aplikasi dan pengurus fail. Ia berkembang daripada dunia pelayan rumah, jadi sifatnya adalah untuk makmal rumah: pantas untuk disediakan, antara muka pengguna yang mesra dan tidak rumit. Ia menyasarkan pengguna yang ingin mencuba dan mahukan paparan Docker yang lebih menarik tanpa perlu membayar sesiapa.

Pemasangan. Hanya satu baris arahan, dan ia tidak memerlukan sistem yang bersih:

curl -fsSL https://get.casaos.io | sudo bash

Pemasang tersebut menambah satu set servis systemd (casaos, casaos-gateway, casaos-app-management, dan lain-lain). Pastikan gerbang (gateway) telah naik sebelum anda membuka pelayar web:

systemctl status casaos-gateway

Apabila ia berjalan, papan pemuka berada di http://<your-ip> (HTTP biasa, port 80). Cipta akaun tempatan dan anda boleh terus masuk.

Menambah aplikasi pertama. Buka App Store, pilih aplikasi, dan klik Install. CasaOS menulis projek Docker Compose di latar belakang dan mendedahkan aplikasi tersebut pada port hos, contohnya http://<your-ip>:8080. Gedungnya mengandungi barisan aplikasi pelayan rumah yang biasa, jadi pelayan media Jellyfin pada VPS atau pustaka foto Immich yang dihoskan sendiri hanya memerlukan beberapa klik sahaja. Jika anda belum membuat keputusan mengenai pelayan foto, keperluan RAM dan aplikasi telefon yang membezakan PhotoPrism daripada Immich wajar dibaca terlebih dahulu, kerana pada kotak CasaOS 1GB, pilihan tersebut menentukan sama ada aplikasi itu boleh berjalan atau tidak. Anda juga boleh mengimport mana-mana docker-compose.yaml yang anda suka, yang merupakan kekuatan sebenar: aplikasi tersebut adalah kontena biasa, bukan format proprietari.

TLS dan sandaran, titik kelemahan. Di sinilah "percuma" menunjukkan hadnya. CasaOS menghidangkan segala-galanya melalui HTTP biasa secara lalai, termasuk papan pemukanya sendiri. Tiada Let's Encrypt terbina dalam, dan tiada sandaran berjadual terbina dalam. Data anda berada dalam Docker volumes di bawah /DATA, dan melakukan sandaran adalah tanggungjawab anda (menggunakan restic atau tar yang dijadualkan dengan cron).

Mod kegagalan, tiada TLS, dan ia senyap. Tiada ralat yang muncul. Anda memasang aplikasi, membuka http://<your-ip>:8080, dan ia berfungsi melalui sambungan tidak disulitkan yang ditandakan oleh pelayar anda sebagai "Not Secure." Kata laluan dan kuki sesi dihantar melalui rangkaian dalam teks jelas. Lebih buruk lagi, CasaOS pernah mengalami kerentanan pelaksanaan kod jauh (remote-code-execution) pada papan pemukanya (CVE-2023-37265 dan CVE-2023-37266, iaitu pintasan pengesahan yang membawa kepada kompromi hos sepenuhnya), jadi mendedahkan port HTTP tersebut terus ke internet adalah risiko sebenar, bukan sekadar isu gaya. Penyelesaiannya adalah dengan tidak mendedahkan CasaOS secara terus. Letakkan reverse proxy di hadapan yang menamatkan TLS, seperti nginx dengan sijil Let's Encrypt daripada Certbot, Caddy, atau Cloudflare Tunnel, dan halakan trafik ke CasaOS pada rangkaian tempatan sahaja. Perlu diingat bahawa CasaOS sudah mengikat port 80, jadi proksi anda dan CasaOS akan bertembung melainkan anda menukar port CasaOS terlebih dahulu.

Kos. Benar-benar percuma, selama-lamanya, tiada had aplikasi. Anda membayar dengan usaha operasi: anda sendiri yang menguruskan TLS, sandaran dan pengukuhan keselamatan.

Coolify: PaaS yang dihoskan sendiri

Apa itu Coolify. Coolify ialah platform-as-a-service sumber terbuka yang dihoskan sendiri, setara dengan Heroku atau Vercel pada pelayan anda sendiri. Unit asalnya bukanlah "pasang aplikasi pakej" tetapi "deploy repositori Git": sambungkan repositori, dan Coolify akan membina aplikasi tersebut (melalui Nixpacks atau Dockerfile anda sendiri) serta menghantarnya, kemudian melakukan deploy semula pada setiap push. Ia juga menyediakan pangkalan data dan servis dengan satu klik. Ia disasarkan kepada pembangun yang melakukan deploy kod sendiri dan mahukan fungsi push-to-deploy tanpa perlu menyewa PaaS.

Pemasangan.

curl -fsSL https://cdn.coollabs.io/coolify/install.sh | sudo bash

Skrip ini memasang Docker dan menjalankan timbunan kontena Coolify sendiri. Pastikan kesemuanya sihat sebelum anda meneruskan:

docker ps --format 'table {{.Names}}\t{{.Status}}'

Anda sepatutnya melihat coolify, coolify-db, coolify-redis, coolify-realtime, dan coolify-proxy kesemuanya melaporkan Up. Papan pemuka berada di http://<your-ip>:8000. Cipta akaun pentadbir anda dengan segera, kerana halaman pendaftaran terbuka sehingga akaun pertama dibuat, dan sesiapa sahaja yang mengaksesnya dahulu akan mengawal pelayan tersebut. Kemudian, tetapkan domain instans anda dan halakan wildcard DNS record (*.example.com, atau *.apps.example.com) ke pelayan tersebut supaya Coolify boleh memberikan subdomain sendiri kepada setiap aplikasi yang di-deploy.

Menambah aplikasi pertama. Sambungkan sumber Git (GitHub, GitLab, atau URL repositori biasa), pilih cawangan, tetapkan domain, dan lakukan deploy. Proksi Traefik terbina dalam Coolify akan menghalakan subdomain dan meminta sijil. Bagi perisian sedia guna, katalog Services membolehkan anda melakukan deploy dengan beberapa klik sahaja: timbunan automasi aliran kerja n8n yang mungkin anda pasang secara manual hanyalah satu entri, begitu juga dengan Uptime Kuma untuk pemantauan halaman status.

TLS dan sandaran. Let's Encrypt automatik bagi setiap aplikasi melalui Traefik yang disertakan, jadi setiap subdomain yang di-deploy akan mendapat sijil. Sandaran adalah berasaskan pangkalan data: anda boleh menjadualkan dump Postgres dan MySQL ke storan yang serasi dengan S3. Sandaran keseluruhan instans (konfigurasi Coolify itu sendiri, yang terletak di bawah /data/coolify) adalah lebih manual, jadi eksport dan simpan sendiri fail tersebut.

Kos dan pelesenan. Edisi yang dihoskan sendiri adalah sepenuhnya sumber terbuka dan percuma, tanpa had aplikasi. Terdapat pilihan Coolify Cloud (berbayar) yang menghoskan control plane untuk anda sementara aplikasi anda masih berjalan pada pelayan anda sendiri; ia memudahkan tetapi tidak diwajibkan.

Mod kegagalan, aplikasi berjaya di-deploy tetapi domainnya tidak dimuatkan. Papan pemuka berfungsi dengan baik pada http://<ip>:8000, proses binaan berjaya (hijau), tetapi URL aplikasi itu sendiri memaparkan ralat sambungan atau 404 page not found Traefik. Ini menunjukkan masalah pada proksi atau DNS, bukan pada aplikasi anda. Dua punca biasa. Pertama, port 80 atau 443 sudah digunakan apabila proksi cuba bermula, menyebabkan kontena tersebut mati dengan ralat Docker:

Error response from daemon: driver failed programming external connectivity on endpoint coolify-proxy: Bind for 0.0.0.0:443 failed: port is already allocated

Kedua, wildcard DNS record tiada, jadi Traefik tidak pernah menerima permintaan untuk hostname tersebut. Jika sebaliknya kad pelayan keseluruhan dalam Coolify memaparkan "Server is not reachable," itu adalah kerosakan yang berbeza: Coolify tidak dapat berhubung dengan soket Docker pelayan sama sekali, biasanya disebabkan oleh daemon Docker yang terhenti atau kunci SSH yang rosak. Baca punca sebenar dalam log sebelum membuat andaian:

docker logs coolify-proxy --tail 100

Selesaikan masalah daripada halaman Proxy: tekan Restart Proxy, atau tetapkan semula konfigurasi proksi kepada lalai dan mulakannya semula, kemudian tunggu kira-kira dua minit untuk ia stabil. Pastikan port 8000 hanya boleh diakses daripada IP anda sendiri (atau buka semula buat sementara waktu apabila proksi berkelakuan tidak betul) dan bukannya membiarkannya terbuka kepada umum. Ia menyediakan papan pemuka melalui HTTP biasa, dan dokumentasi Coolify sendiri menyatakan port 8000, 6001 dan 6002 boleh ditutup sebaik sahaja papan pemuka diakses melalui domainnya sendiri.

Overhed sumber pada VPS yang sama

Diukur semasa melahu pada kotak 4GB yang sama, sebelum menggunakan sebarang beban kerja sebenar. Semak nilai anda dengan free -m dan docker stats --no-stream dan jangan hanya mempercayai satu nombor, kerana jumlahnya berubah mengikut campuran aplikasi anda.

• CasaOS adalah yang paling ringan. Panelnya terdiri daripada set kecil perkhidmatan Go; jangkakan overhed sekitar 150 hingga 300 MB di samping mana-mana kontena yang anda jalankan.
• Coolify menjalankan beberapa kontena sokongan miliknya sendiri (aplikasi, Postgres, Redis, perkhidmatan masa nyata, dan Traefik), jadi ia berada sekitar 600 MB hingga 1 GB semasa melahu sebelum anda menggunakan apa-apa.
• Cloudron adalah yang paling berat semasa melahu, kerana ia menjalankan nginx, pangkalan data, tindanan mel dan pemantauan sendiri sama ada anda menggunakannya atau tidak; peruntukkan 1 hingga 1.5 GB semasa melahu. Itulah sebabnya ia memerlukan minimum 2GB dan berfungsi dengan lebih lancar pada 4GB.

Pada VPS 2GB yang kecil, CasaOS meninggalkan ruang paling banyak untuk aplikasi sebenar manakala Cloudron meninggalkan ruang paling sedikit. Jika pelan anda adalah 2GB dan anda mahu menggunakan Cloudron dengan pelayan melnya berjalan, rancang untuk menaik taraf pelayan tersebut.

Perbandingan kemas kini, sandaran dan penguncian vendor

Kemas kini. Cloudron mengemas kini platform dan setiap aplikasi untuk anda mengikut jadual yang telah diuji: usaha paling minimum dengan bantuan paling banyak. Coolify mengemas kini dirinya sendiri daripada papan pemuka dengan satu butang. CasaOS mengemas kini panel melalui skrip pemasangannya atau apt, namun aplikasi yang anda pasang perlu ditarik (pull) dan dimulakan semula oleh anda sendiri.

Penguncian vendor, bahagian yang memberi kesan pada tahun kedua. CasaOS adalah yang paling kurang terikat: aplikasinya merupakan projek Compose biasa, jadi anda boleh menyalin docker-compose.yaml dan volum di bawah /DATA ke mana-mana hos lain dan meneruskan operasi. Coolify berada di pertengahan: proses deploy adalah Dockerfile dan repositori anda sendiri, tetapi konfigurasinya disimpan dalam pangkalan data Coolify, jadi menukar hos bermakna anda perlu mencipta semula projek tersebut di tempat baharu. Cloudron adalah yang paling terikat: aplikasi dibungkus oleh Cloudron, dan walaupun data anda boleh dikeluarkan dengan bersih melalui sandaran yang cemerlang, kaedah pembungkusannya tidak boleh dipindahkan, jadi anda perlu melakukan deploy semula pada platform destinasi. Data mudah alih, infrastruktur tidak mudah alih.

Yang mana satu patut anda pilih

Versi ringkas, diikuti dengan jalan keluar. Pilih Cloudron jika anda mahukan pelayan yang paling kurang memerlukan penyelenggaraan manual antara ketiga-tiganya, akan menjalankan beberapa aplikasi berbungkus, dan sanggup membayar yuran tahunan untuk TLS terurus, sandaran serta kemas kini. Pilih CasaOS jika ini adalah makmal rumah di sebalik rangkaian anda sendiri atau reverse proxy, anda mahukan antara muka mesra untuk Docker, dan anda enggan membayar apa-apa. Pilih Coolify jika anda menggunakan kod sendiri daripada Git dan mahukan fungsi push-to-deploy dengan TLS automatik, tanpa perlu membayar harga PaaS yang dihoskan. Jika tiada satu pun daripada ketiga-tiga pilihan tersebut menggambarkan situasi anda, bahagian seterusnya adalah jawapan yang jujur.

Langkau ketiga-tiganya jika...

Jujurlah tentang skala anda. Jika anda hanya menjalankan satu atau dua aplikasi, atau anda ingin memahami dan mengawal sepenuhnya apa yang ada pada pelayan anda, langkau panel kawalan. Kos overhed dan penguncian vendor tidak berbaloi untuk susunan (stack) yang kecil dan stabil. Laluan DIY adalah dengan menggunakan reverse proxy di hadapan fail Compose anda sendiri: Traefik dengan TLS automatik di hadapan beberapa aplikasi Docker Compose memberikan anda HTTPS yang setara dengan satu klik tanpa bebanan panel, dan anda boleh membuat sandaran dengan tugasan restic melalui cron yang anda benar-benar fahami.

services:
  whoami:
    image: traefik/whoami
    labels:
      - traefik.enable=true
      - traefik.http.routers.whoami.rule=Host(`whoami.example.com`)
      - traefik.http.routers.whoami.tls.certresolver=le
    networks: [web]
networks:
  web:
    external: true

Bagi satu aplikasi utama, keadaannya lebih jelas: pemasangan Nextcloud pada Docker dengan TLS dan rutin sandaran sendiri hanyalah satu fail Compose dan satu sijil. Memasang keseluruhan perkakas (appliance) untuk menjalankannya hanya akan menambah kos tanpa sebarang faedah. Jika anda masih membuat keputusan apa yang ingin dijalankan sebelum menentukan bagaimana caranya, panduan tentang perkara yang berbaloi untuk di-self-host pada tahun 2026 adalah titik permulaan yang lebih baik.

FAQ

Adakah saya benar-benar memerlukan panel self-hosting?

Hanya jika anda mementingkan empat perkara yang diotomatiskan oleh panel merentas beberapa aplikasi: pemasangan satu klik, TLS automatik, sandaran berjadual dan pengurusan pengguna. Untuk satu atau dua servis, Docker Compose biasa di belakang Traefik melakukan tugas TLS yang sama dengan bebanan yang jauh lebih rendah dan tiada pengikatan vendor (lock-in). Panel berbaloi apabila anda menjalankan banyak aplikasi dan masa anda lebih berharga daripada RAM yang digunakan oleh panel tersebut.

Panel manakah yang terbaik untuk pemula?

Untuk makmal rumah (home lab) di mana tiada apa-apa yang didedahkan kepada internet yang berbahaya, CasaOS adalah permulaan yang paling mudah: satu arahan dan UI yang mesra, tanpa sebarang bayaran. Namun, anda mesti meletakkan reverse proxy yang melakukan TLS termination di hadapan sebelum mendedahkan apa-apa, kerana ia menghantar HTTP biasa. Jika anda mahukan TLS terurus dan sandaran yang dikendalikan untuk anda serta sanggup membayar, Cloudron adalah yang paling banyak membantu, dalam had dua aplikasi percuma.

Adakah Cloudron percuma?

Sebahagiannya. Peringkat percuma membenarkan dua aplikasi, yang memadai untuk mencubanya atau untuk persediaan yang sangat kecil. Selain daripada itu, Cloudron adalah langganan berbayar, dibilkan secara bulanan atau tahunan, dengan aplikasi tanpa had pada peringkat berbayar. Ia adalah produk komersial dengan pelan percuma yang terhad, bukan perisian percuma, jadi sediakan bajet jika susunan aplikasi anda akan berkembang.

Bolehkah saya menjalankan panel ini bersama aplikasi sedia ada saya?

Cloudron: tidak. Ia memerlukan mesin Ubuntu yang bersih dan akan membatalkan pemasangan jika nginx, Docker atau Node sudah dipasang, kerana ia menguruskan keseluruhan mesin. CasaOS dan Coolify lebih mesra kerana ia memasang susunan Docker sendiri dan boleh berkongsi mesin pada dasarnya, tetapi kedua-duanya mahukan port 80 dan 443, jadi ia akan bertembung dengan mana-mana pelayan web atau proksi yang anda jalankan. Pada mesin yang sudah menempatkan pelbagai perkara, panel biasanya bukan alat yang sesuai; gunakan Traefik dan Compose sebaliknya.

Bagaimanakah cara untuk berpindah keluar daripada panel kemudian hari?

Rancang jalan keluar anda sebelum anda memerlukannya. Daripada CasaOS, salin docker-compose.yaml aplikasi dan volum /DATA miliknya ke hos baharu dan mulakannya semula. Daripada Coolify, eksport konfigurasi setiap projek dan halakannya ke repositori yang sama di destinasi. Daripada Cloudron, pulihkan data daripada sandarannya ke dalam aplikasi yang baru dipasang pada platform baharu, kerana pembungkusan Cloudron tidak boleh dipindahkan, hanya datanya sahaja. Dalam setiap kes, uji pemulihan pada mesin sementara sebelum anda memadamkan mesin lama.