Cloudron CasaOS Coolify VPS 비교 추천

구축 목표

도구는 설치하는 것만큼이나 선택하는 것이 중요합니다. Cloudron, CasaOS, Coolify 세 가지 패널은 빈 VPS를 클릭만으로 앱을 호스팅할 수 있는 환경으로 바꿔준다고 약속합니다. 이 가이드에서는 각 패널을 동일한 신규 Ubuntu 24.04 서버에 설치하고 첫 번째 앱을 설치합니다. 그 후 TLS, 백업, 업데이트, 메모리 비용, 그리고 탈출 난이도와 같이 스크린샷에 잘 나타나지 않는 요소들을 심층 분석합니다. 가이드를 마치면 어떤 도구가 적합한지, 혹은 "모두 사용하지 말고 Docker Compose를 사용하라"는 것이 정답인지 알게 될 것입니다.

이 도구들은 마법이 아닙니다. 세 가지 모두 수동으로 제어 가능한 동일한 Docker Engine을 기반으로 작동합니다. 패널이 비용(금전, RAM, 또는 종속성)을 받고 제공하는 가치는 대신 처리해 주는 네 가지 작업입니다: one-click app installs, automatic TLS certificates, scheduled backups, and user management. 이 네 가지 기능이 관리 오버헤드를 감수할 만큼 가치 있다면 패널을 사용할 가치가 있습니다. 만약 한두 개의 서비스만 실행하며 서버 상태를 정확히 파악하는 것을 선호한다면, "Skip all three" 섹션을 먼저 읽고 시간을 절약하십시오.

공통 필수 요구사항 및 주의사항

세 제품 모두 컨테이너 가상화가 아닌 KVM VPS를 기준으로 합니다. Docker는 실제 커널이 필요하며, Cloudron은 OpenVZ 및 LXC를 지원하지 않습니다. systemd-detect-virt를 통해 확인하십시오. kvm 또는 qemu은 사용 가능하지만, openvz 또는 lxc은 사용할 수 없습니다. KVM 플랜에서는 명령 실행 시 kvm이 출력되며, 베어 메탈에서는 none이 출력됩니다. 두 결과 모두 설치를 계속할 수 있음을 의미합니다.

그 외의 사양은 제품마다 다르며, 이는 선택 시 가장 먼저 고려해야 할 사항입니다.

• RAM. CasaOS는 1GB 환경에서도 원활하게 작동합니다. Raspberry Pi 하드웨어 기반으로 설계되어 가볍습니다. Coolify는 최소 2GB RAM과 2개의 CPU 코어가 필요하며, 이 중 약 600 MB는 Coolify 자체 프로세스가 사용합니다. Cloudron은 최소 2GB가 필요하며 4GB 환경에서 더 안정적입니다. 앱을 설치하기 전부터 메일 서버와 데이터베이스를 실행하기 때문입니다.
• 관리 가능한 도메인 및 DNS. Cloudron과 Coolify는 모두 작동하는 DNS를 갖춘 실제 도메인이 필요합니다. Cloudron은 레코드 생성 및 와일드카드 인증서 발급을 위해 DNS 제공업체의 API 액세스 권한을 요구합니다. CasaOS는 IP 주소만으로 실행할 수 있지만, 이 경우 TLS를 사용할 수 없습니다.
• Ports. 세 제품 모두 HTTP 및 HTTPS를 위해 80 및 443 포트가 개방되어 있어야 합니다. Coolify는 추가로 대시보드용 8000 포트, 실시간 채널용 6001 포트, 브라우저 터미널용 6002 포트를 사용합니다. 모든 제품에서 SSH를 위해 22 포트를 개방해 두어야 합니다.

설치를 시작하기 전에 DNS를 서버로 연결하십시오. 호스트 이름을 자체적으로 해석할 수 없는 패널은 인증서를 요청할 수 없습니다. 이 문제를 해결하느라 설치 첫 1시간을 낭비하게 될 것입니다. 서버 IP에 A 레코드를 설정하십시오. Coolify의 경우 모든 배포 앱이 고유한 서브도메인을 가질 수 있도록 와일드카드 레코드(*.apps.example.com)를 추가하십시오.

Cloudron: 완성도 높고 독자적인 솔루션

개요. Cloudron은 서버 전체를 관리형 어플라이언스로 전환하는 상용 플랫폼입니다. 자체 reverse proxy, database, mail stack을 실행하며, 패키징된 앱(Nextcloud, WordPress, Gitea, Mattermost 등)으로 구성된 App Store를 제공합니다. 자동 업데이트, 자동 인증서 발급, 자동 백업 기능이 포함된 '관리형' 앱 환경을 원하며, 이에 대한 비용을 지불할 의사가 있는 사용자를 대상으로 합니다.

설치. Cloudron은 깨끗한 상태의 서버를 요구하며, 서버의 모든 권한을 가져옵니다. 반드시 신규 Ubuntu 24.04 (Noble) 서버에서 다음 명령어를 실행하십시오. 다른 환경에서는 작동하지 않습니다.

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

스크립트는 Docker, nginx, database, mail stack을 설치한 후 시스템을 재부팅합니다. 재부팅이 완료되면 https://<your-ip>에 접속하십시오. 임시 self-signed certificate를 수락한 뒤 브라우저에서 설정을 완료하십시오. 도메인을 지정하고 DNS provider를 선택하면 my.example.com에 대시보드가 생성됩니다.

첫 번째 앱 추가. 대시보드에서 App Store를 열고, Nextcloud를 선택한 후, 서브도메인 files.example.com를 지정하고 Install을 클릭하십시오. Cloudron은 사용자가 설정 파일을 수정하지 않아도 DNS 레코드를 생성하고, Let's Encrypt 인증서를 요청하며, database를 준비하고, single sign-on을 연결하며, 백업 일정을 예약합니다. 이것이 Cloudron의 핵심 가치이며, 실제로 이를 완벽히 수행합니다.

TLS 및 백업. 세 가지 핵심 기능 중 가장 강력한 기능입니다. 모든 앱 서브도메인에는 자동으로 Let's Encrypt 인증서가 발급되며 자동으로 갱신됩니다. 백업은 내장된 스케줄에 따라 로컬 디렉토리, S3 또는 기타 원격 스토리지에 저장됩니다. 앱별 복구가 가능하며, 새로운 서브도메인으로 앱을 원클릭 복제(cloning)할 수도 있습니다.

비용 및 라이선스 (결정 전 필독). Cloudron은 무료 티어에 제한이 있는 유료 제품입니다. 무료 플랜은 두 개의 앱까지만 허용합니다. 세 번째 앱을 설치하면 결제 창이 나타납니다. 유료 구독(Pro 또는 Max, 월간 또는 연간 결제 가능, 두 플랜 모두 앱 개수 무제한)을 통해 더 많은 기능을 사용할 수 있습니다. 이것이 Cloudron에 관한 가장 중요한 사실입니다. Cloudron이 완성도가 높은 이유는 비즈니스 모델이기 때문이며, 무료 티어는 확장 중인 서비스용이라기보다 연장된 체험판에 가깝습니다.

오류 사례 1: 깨끗한 서버 규칙. 이미 다른 서비스가 실행 중인 서버에 Cloudron을 설치하려고 하면, 시스템 변경 전에 설정이 중단됩니다.

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.

이는 단순한 까다로움 때문이 아닙니다. Cloudron은 특정 버전의 nginx, Docker, Node를 고정하여 깊게 통합하므로, 기존에 설치된 버전들과 공존할 수 없습니다. 해결 방법은 신규 Ubuntu 24.04 이미지를 사용하는 것입니다. 웹 서버, Docker, 사용자가 직접 설정한 방화벽조차 설치되어 있지 않은 상태여야 합니다. 지원되지 않는 이미지를 사용한 경우에도 설치가 거부됩니다. Cloudron은 x86-64 아키텍처의 지원되는 Ubuntu LTS(22.04 또는 24.04)만 지원합니다. ARM, LXC, OpenVZ는 지원하지 않습니다.

오류 사례 2: 와일드카드 인증서와 DNS API. 설정 중 Cloudron에 API token을 제공하는 대신 "Manual" DNS 옵션을 선택하면, Cloudron이 DNS 레코드나 와일드카드 인증서를 생성할 수 없습니다. 이 경우 새 앱을 추가할 때마다 인증서 발급 전 DNS 레코드를 수동으로 추가해야 하며, 대시보드는 해당 레코드가 생성될 때까지 대기 상태로 남습니다. 지원되는 DNS provider(Cloudflare, Route 53, DigitalOcean 등)에 대한 API 권한을 Cloudron에 부여하면 모든 과정이 원클릭으로 처리됩니다.

CasaOS: 무료 홈랩 대시보드

개요. IceWhale에서 개발한 CasaOS는 Docker 기반의 무료 오픈 소스 대시보드입니다. 홈 화면, 앱 스토어, 파일 관리 기능을 제공합니다. 홈 서버 환경을 기반으로 개발되었으므로 설정이 빠르고 UI가 친숙하며 절차가 간소합니다. 비용 지불 없이 Docker를 더 편리하게 사용하려는 사용자에게 적합합니다.

설치. 다음 명령어를 입력하면 됩니다. 깨끗한 상태의 OS가 아니어도 설치 가능합니다.

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

설치 프로그램은 일련의 systemd 서비스(casaos, casaos-gateway, casaos-app-management 등)를 추가합니다. 브라우저를 열기 전에 게이트웨이가 실행되었는지 확인하십시오.

systemctl status casaos-gateway

실행 중인 대시보드 주소는 http://<your-ip> (HTTP, port 80)입니다. 로컬 계정을 생성하면 접속할 수 있습니다.

첫 번째 앱 추가. App Store를 열고 앱을 선택한 뒤 Install을 클릭합니다. CasaOS는 백그라운드에서 Docker Compose 프로젝트를 작성하고 앱을 호스트 포트(예: http://<your-ip>:8080)에 노출합니다. 스토어에는 일반적인 홈 서버용 앱들이 포함되어 있습니다. VPS에서 Jellyfin 미디어 서버 또는 자체 호스팅 Immich 사진 라이브러리를 몇 번의 클릭만으로 설치할 수 있습니다. 또한 원하는 docker-compose.yaml를 직접 가져올 수 있습니다. 이는 CasaOS의 핵심 강점입니다. 앱은 독자적인 형식이 아닌 일반적인 컨테이너로 동작합니다.

TLS 및 백업 문제. 이 부분은 "무료" 소프트웨어의 한계입니다. CasaOS는 대시보드를 포함한 모든 서비스를 기본적으로 일반 HTTP로 제공합니다. Let's Encrypt 기능이나 예약 백업 기능이 내장되어 있지 않습니다. 데이터는 /DATA 하위의 Docker volumes에 저장됩니다. 따라서 백업은 사용자가 직접 수행해야 합니다(cron을 이용한 restic 또는 tar 사용).

TLS 미사용 시의 위험성. 오류 메시지는 나타나지 않습니다. 앱을 설치하고 http://<your-ip>:8080를 열면 작동은 하지만, 브라우저에 "Not Secure"라고 표시되는 암호화되지 않은 연결을 사용하게 됩니다. 비밀번호와 세션 쿠키가 평문으로 전송됩니다. 더 심각한 문제는 CasaOS 대시보드에서 실제 원격 코드 실행(RCE) 취약점이 발견되었다는 점입니다(CVE-2023-37265 및 CVE-2023-37266, 인증 우회를 통한 호스트 전체 권한 탈취). 따라서 HTTP 포트를 인터넷에 직접 노출하는 것은 단순한 스타일 문제가 아닌 심각한 보안 위험입니다. 해결 방법은 CasaOS를 직접 노출하지 않는 것입니다. Certbot의 Let's Encrypt 인증서를 사용하는 nginx, Caddy 또는 Cloudflare Tunnel와 같은 역방향 프록시를 앞에 배치하여 TLS를 종료하고, 로컬 네트워크의 CasaOS로 전달하십시오. CasaOS가 이미 port 80을 사용 중이므로, CasaOS의 포트를 먼저 변경하지 않으면 프록시와 포트 충돌이 발생합니다.

비용. 앱 개수 제한 없이 영구적으로 무료입니다. 대신 사용자가 직접 TLS 설정, 백업, 보안 강화 작업을 수행해야 합니다.

Coolify: self-hosted PaaS

개요. Coolify는 Heroku나 Vercel과 유사한 기능을 제공하는 오픈 소스 self-hosted platform-as-a-service입니다. 이 플랫폼의 기본 단위는 "패키지 앱 설치"가 아니라 "Git repository 배포"입니다. 저장소를 연결하면 Coolify가 Nixpacks 또는 사용자의 Dockerfile을 통해 빌드하고 배포하며, push가 발생할 때마다 재배포를 수행합니다. 또한 클릭 한 번으로 데이터베이스와 서비스를 생성할 수 있습니다. PaaS를 임대하지 않고 직접 코드를 배포하며 push-to-deploy 방식을 원하는 개발자를 대상으로 합니다.

설치.

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

이 스크립트는 Docker를 설치하고 Coolify 전용 컨테이너 스택을 실행합니다. 다음 단계로 넘어가기 전에 컨테이너 상태가 정상인지 확인하십시오:

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

coolify, coolify-db, coolify-redis, coolify-realtime, coolify-proxy가 모두 Up 상태여야 합니다. 대시보드 주소는 http://<your-ip>:8000입니다. 즉시 관리자 계정을 생성하십시오. 첫 번째 계정이 생성될 때까지 등록 페이지가 열려 있으므로, 먼저 접속하는 사람이 서버를 제어하게 됩니다. 그 다음 인스턴스 도메인을 설정하고, Coolify가 배포된 각 앱에 서브도메인을 할당할 수 있도록 wildcard DNS record (*.example.com 또는 *.apps.example.com)를 서버로 지정하십시오.

첫 번째 앱 추가. Git 소스(GitHub, GitLab 또는 일반 repo URL)를 연결하고, 브랜치를 선택하고, 도메인을 설정한 뒤 배포합니다. Coolify에 내장된 Traefik proxy가 서브도메인 라우팅과 인증서 요청을 처리합니다. 기성 소프트웨어의 경우, Services 카탈로그를 통해 몇 번의 클릭만으로 배포할 수 있습니다. 직접 구성해야 했을 n8n workflow-automation stack이나 상태 페이지 모니터링을 위한 Uptime Kuma 모두 단일 항목으로 제공됩니다.

TLS 및 백업. 내장된 Traefik을 통해 앱별로 Let's Encrypt가 자동으로 적용되므로, 모든 배포된 서브도메인은 인증서를 받습니다. 백업은 데이터베이스 중심입니다. Postgres 및 MySQL 덤프를 S3 호환 스토리지에 예약할 수 있습니다. 전체 인스턴스 백업(/data/coolify에 저장되는 Coolify 설정 자체)은 수동 작업이 더 많이 필요하므로 직접 내보내기하여 저장하십시오.

비용 및 라이선스. self-hosted 에디션은 완전한 오픈 소스이며 무료이며, 앱 개수 제한이 없습니다. 선택 사항으로 Coolify Cloud(유료)가 있습니다. 이는 앱은 사용자의 서버에서 실행하되 제어 평면(control plane)만 대신 호스팅해 주는 서비스로, 편리하지만 필수 사항은 아닙니다.

장애 사례: 앱은 배포되었으나 도메인이 로드되지 않음. 대시보드는 http://<ip>:8000에서 정상 작동하고 빌드도 성공(green)했으나, 앱의 URL이 연결 오류 또는 Traefik 404 page not found을 반환하는 경우입니다. 이는 앱의 문제가 아니라 프록시 또는 DNS의 문제입니다. 두 가지 일반적인 원인이 있습니다. 첫째, 프록시가 시작될 때 80 또는 443 포트가 이미 사용 중이어서 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

둘째, wildcard DNS record가 누락되어 Traefik이 해당 호스트네임에 대한 요청을 받지 못하는 경우입니다. 만약 Coolify의 서버 카드가 "Server is not reachable"라고 표시된다면 이는 다른 문제입니다. Coolify가 서버의 Docker socket와 통신할 수 없는 상태이며, 대개 Docker 데몬이 중지되었거나 SSH 키가 손상된 경우입니다. 추측하기 전에 로그에서 실제 원인을 확인하십시오:

docker logs coolify-proxy --tail 100

Proxy 페이지에서 문제를 해결하십시오. Restart Proxy를 누르거나, 프록시 설정을 기본값으로 초기화한 후 다시 시작하십시오. 설정이 완료될 때까지 약 2분 정도 기다려야 합니다. 8000 포트는 전 세계에 개방하지 말고 본인의 IP에서만 접속 가능하도록 유지하십시오(프록시 오류 발생 시에만 일시적으로 개방). 8000 포트는 일반 HTTP로 대시보드를 서비스하며, Coolify 공식 문서에 따르면 대시보드가 자체 도메인을 통해 서비스되면 8000, 6001, 6002 포트는 닫아도 됩니다.

동일 VPS에서의 리소스 오버헤드

실제 워크로드를 배포하기 전, 동일한 4GB 사양의 시스템에서 유휴 상태(idle)를 기준으로 측정했습니다. 전체 오버헤드는 애플리케이션 구성에 따라 달라지므로, 단일 수치만 신뢰하지 말고 free -m 및 docker stats --no-stream를 사용하여 직접 확인하십시오.

• CasaOS가 가장 가볍습니다. 패널은 소규모 Go 서비스 세트로 구성됩니다. 실행 중인 컨테이너 외에 약 150 ~ 300 MB의 오버헤드가 발생합니다.
• Coolify는 자체 지원 컨테이너(app, Postgres, Redis, realtime service, Traefik)를 여러 개 실행합니다. 따라서 배포 전 유휴 상태에서 약 600 MB ~ 1 GB를 점유합니다.
• Cloudron은 유휴 상태에서 가장 무겁습니다. 사용 여부와 관계없이 자체 nginx, database, mail stack, monitoring을 실행하기 때문입니다. 유휴 상태에서 1 ~ 1.5 GB를 할당하십시오. 이 때문에 최소 2GB를 요구하며, 4GB 환경에서 원활하게 작동합니다.

2GB 사양의 소형 VPS에서는 CasaOS가 실제 앱을 위한 공간을 가장 많이 확보해주며, Cloudron이 가장 적게 확보해줍니다. 만약 2GB 플랜을 사용하면서 메일 서버가 포함된 Cloudron을 사용하려면, 서버 업그레이드를 고려하십시오.

Updates, backups, and lock-in compared

Updates. Cloudron은 검증된 일정에 따라 platform과 모든 app을 자동으로 업데이트합니다. 이는 사용자의 노력을 최소화하고 관리를 자동화합니다. Coolify는 dashboard에서 버튼 하나로 자체 업데이트를 수행합니다. CasaOS는 install script 또는 apt를 통해 panel을 업데이트하지만, 설치된 app의 업데이트 및 재시작은 사용자가 직접 수행해야 합니다.

Lock-in, 2년 차에 발생하는 문제. CasaOS는 lock-in 위험이 가장 낮습니다. app이 일반적인 Compose project이므로, docker-compose.yaml와 /DATA 아래의 volumes를 다른 host로 복사하여 계속 사용할 수 있습니다. Coolify는 중간 단계입니다. deploy에 사용된 Dockerfiles와 repos는 사용자의 소유이지만, 설정 정보는 Coolify의 database에 저장됩니다. 따라서 host를 이전하려면 대상 서버에서 project를 다시 생성해야 합니다. Cloudron은 lock-in 위험이 가장 높습니다. app이 Cloudron 전용 패키지로 구성되어 있습니다. 우수한 backup 기능을 통해 data는 안전하게 추출할 수 있지만, 패키지 구조는 그대로 유지되지 않습니다. 따라서 대상 platform에서 app을 다시 배포해야 합니다. 데이터는 이동 가능하지만, 시스템 구성 요소는 이동할 수 없습니다.

어떤 것을 선택해야 합니까

요약된 선택 기준을 먼저 제시한 후 상세 내용을 설명합니다. 세 가지 옵션 중 서버 관리 부담이 가장 적은 것을 원한다면 Cloudron을 선택하십시오. 여러 패키지 앱을 실행하며, 관리형 TLS, 백업 및 업데이트를 위해 연간 비용을 지불할 의사가 있는 경우에 적합합니다. 개인 네트워크 뒤에 있는 홈 랩(home lab)이나 리버스 프록시(reverse proxy) 용도로 사용하며, Docker를 쉽게 다루고 싶고 비용 지불을 원하지 않는다면 CasaOS를 선택하십시오. Git에서 직접 코드를 배포하며, 호스팅형 PaaS 비용 없이 자동 TLS를 포함한 push-to-deploy 기능을 원한다면 Coolify를 선택하십시오. 위 세 가지 중 해당 사항이 없다면 다음 섹션에서 정답을 확인하십시오.

다음 세 가지를 모두 건너뛰려면...

규모를 정확히 파악하십시오. 앱을 한두 개만 실행하거나, 서버 내부 상태를 직접 이해하고 제어하기를 원한다면 패널 사용을 건너뛰십시오. 규모가 작고 안정적인 스택의 경우, 오버헤드와 종속성(lock-in)이 발생하므로 패널 사용의 실익이 적습니다. DIY 방식은 자체 Compose 파일 앞에 reverse proxy를 배치하는 것입니다. 여러 Docker Compose 앱 앞에 자동 TLS를 지원하는 Traefik 배치를 사용하면 패널의 무게감 없이 원클릭 방식과 동일한 HTTPS를 구현할 수 있습니다. 또한, 구조를 완전히 파악할 수 있는 cron 기반의 restic 작업으로 백업을 수행할 수 있습니다.

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

단일 주요 앱을 운영하는 경우 상황은 더욱 명확합니다. TLS 및 자체 백업 루틴을 포함한 Docker 기반 Nextcloud 설치는 하나의 Compose 파일과 하나의 인증서로 구성됩니다. 이를 실행하기 위해 전체 어플라이언스를 구축하는 것은 비용만 많이 들고 이점이 없습니다. 실행할 소프트웨어를 결정하기 전에 운영 방식을 고민 중이라면, 2026년에 셀프 호스팅할 가치가 있는 소프트웨어 가이드가 더 적합한 시작점입니다.

FAQ

self-hosting panel이 꼭 필요한가요?

패널이 자동화하는 네 가지 기능, 즉 원클릭 설치, 자동 TLS, 예약 백업, 사용자 관리가 여러 앱에 걸쳐 필요할 때만 사용하십시오. 한두 개의 서비스만 운영한다면 Traefik 기반의 Docker Compose를 사용하는 것이 좋습니다. 이 방식은 오버헤드가 훨씬 적고 종속성(lock-in)이 없습니다. 패널은 운영하는 앱이 많고, 패널이 사용하는 RAM 비용보다 관리자의 시간이 더 중요할 때 가치가 있습니다.

초보자에게 가장 적합한 패널은 무엇인가요?

외부 인터넷에 노출되지 않는 홈 랩(home lab) 환경이라면 CasaOS가 가장 쉽습니다. 명령 한 줄과 친숙한 UI를 제공하며 비용이 들지 않습니다. 하지만 CasaOS는 기본적으로 HTTP로 동작하므로, 서비스를 외부에 노출하기 전에 반드시 TLS를 종료하는 reverse proxy를 앞에 배치해야 합니다. 관리형 TLS와 백업 기능이 필요하고 비용을 지불할 의사가 있다면, Cloudron이 가장 편리합니다. 단, 무료 플랜은 두 개의 앱까지만 허용됩니다.

Cloudron은 무료인가요?

부분적으로 무료입니다. 무료 티어에서는 두 개의 앱을 사용할 수 있으며, 이는 테스트용이나 소규모 설정에 적합합니다. 그 이상의 앱을 사용하려면 월간 또는 연간 구독료를 지불해야 하며, 유료 티어에서는 앱 개수 제한이 없습니다. Cloudron은 무료 소프트웨어가 아니라 무료 플랜 제한이 있는 상용 제품입니다. 서비스 규모가 커질 예정이라면 예산을 고려하십시오.

기존 앱들과 함께 패널을 실행할 수 있나요?

Cloudron: 불가능합니다. Cloudron은 깨끗한 상태의 Ubuntu 서버를 요구합니다. nginx, Docker 또는 Node가 이미 설치되어 있으면 설치가 중단됩니다. 이는 Cloudron이 시스템 전체를 관리하기 때문입니다. CasaOS와 Coolify는 자체 Docker stack을 설치하므로 이론적으로 한 서버를 공유할 수 있어 더 유연합니다. 하지만 두 패널 모두 80 및 443 포트를 사용하므로, 이미 실행 중인 웹 서버나 proxy와 충돌이 발생합니다. 이미 서비스가 호스팅 중인 서버에 패널을 설치하는 것은 적절하지 않습니다. 대신 Traefik과 Compose를 사용하십시오.

나중에 패널을 어떻게 제거하고 이전하나요?

이전 계획을 미리 세워두십시오. CasaOS의 경우, 앱의 docker-compose.yaml와 /DATA 볼륨을 새 호스트로 복사한 뒤 다시 시작하면 됩니다. Coolify의 경우, 각 프로젝트의 설정을 내보낸(export) 후 대상 서버의 동일한 repo를 가리키도록 설정하십시오. Cloudron의 경우, Cloudron 패키지 자체는 이동할 수 없으므로 백업에서 데이터를 복구하여 새 플랫폼의 앱에 넣어야 합니다. 모든 경우에 대해, 기존 서버를 삭제하기 전에 테스트용 서버에서 복구 테스트를 반드시 수행하십시오.