VPS에 Cloudron 설치하는 방법 및 필수 설정 가이드

VPS에 Cloudron 설치하기: 요약 버전

VPS에 Cloudron을 설치하려면 초기화된 Ubuntu 서버, 최소 2 GB의 RAM, 그리고 DNS 레코드를 수정할 수 있는 도메인이 필요합니다. 설치 과정은 3개의 명령어와 1번의 재부팅으로 이루어집니다. 설치 과정에서 발생하는 대부분의 문제는 설치 전(잘못된 기본 이미지, 잘못된 가상화 유형)이나 설치 후(DNS, 메일, 백업)에 발생합니다.

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

Cloudron은 자체 호스팅 애플리케이션을 설치, 업데이트, 백업하고 TLS(전송 계층 보안) 인증서를 발급합니다. 모든 앱은 Docker에서 실행되며, nginx가 모든 앱의 앞단에서 동작하고, 각 앱은 도메인의 고유한 서브도메인을 할당받습니다. 이러한 이유로 DNS 설정 작업을 가장 먼저 수행해야 합니다.

Cloudron이 기본 OS를 까다롭게 요구하는 이유

설치 스크립트는 설치를 시작하기 전에 서버 상태를 점검하며, 점검 항목을 통과하지 못하면 새 서버를 준비해야 합니다. 서버 이미지를 선택하기 전에 다음 내용을 확인하십시오.

• Ubuntu만 지원하며, 세 가지 릴리스만 가능합니다. 다른 OS를 사용하면 Cloudron requires Ubuntu 20.04, 22.04, 24.04와 함께 종료됩니다. Debian, Rocky, Alpine은 지원하지 않습니다. Ubuntu 24.04는 Cloudron 8 이상이 필요하며, 스크립트가 이를 자동으로 확인합니다.
• 64비트 Intel 또는 AMD 아키텍처만 지원합니다: Error: Cloudron only supports amd64/x86_64. ARM 기반 VPS에서는 실행할 수 없습니다.
• 완전한 하드웨어 가상화 환경이어야 합니다. 컨테이너 기반 VPS에서는 systemd-detect-virt --container을 통해 컨테이너 환경임을 감지하고 Error: Cloudron does not support lxc, only runs on bare metal or with full hardware virtualization을 출력하며 중단됩니다. KVM은 가능하지만, OpenVZ와 LXC는 지원하지 않습니다.
• 루트 파일 시스템은 ext4 또는 xfs이어야 합니다. 다른 파일 시스템을 사용하면 Error: Cloudron requires '/' to be ext4 or xfs 오류가 발생하며, btrfs나 zfs 이미지가 여기에 해당합니다.
• 최소 941 MB의 RAM과 /에 20 GB 이상의 공간이 필요하며, 이는 free -m과 루트 파일 시스템 크기로 측정됩니다.
• 완전히 초기화된 서버여야 합니다. nginx, docker 또는 node이 이미 설치되어 있다면 스크립트는 Error: Some packages like nginx/docker/nodejs are already installed.을 출력하며 설치를 거부합니다.

마지막 점검 항목은 사용자들이 가장 의문을 갖는 부분이며, 그 이유는 다음과 같습니다. Cloudron은 Docker, nginx, Node.js, MySQL의 특정 버전을 고정하여 설치하고, 호스팅하는 모든 앱의 nginx 설정을 직접 작성하며, iptables 방화벽 규칙을 직접 관리합니다. 사용자가 직접 설치한 Docker는 버전이 맞지 않을 수 있으며, 기존 nginx 사이트 파일은 덮어쓰여질 것입니다. Cloudron은 서버 전체를 제어하므로 전용 VPS를 할당해야 합니다.

한 가지 더 놓치기 쉬운 점검 사항이 있습니다. AVX(Advanced Vector Extensions)를 지원하지 않는 구형 CPU에서는 스크립트가 CPU has no AVX support. MongoDB will be disabled을 출력하며, MongoDB가 필요한 모든 앱을 설치할 수 없게 됩니다. 서버를 결정하기 전에 grep -m1 -o avx /proc/cpuinfo 명령어로 CPU를 확인하십시오. 지원되는 호스트라면 avx이 출력되고, 구형 호스트라면 아무것도 출력되지 않습니다.

Cloudron은 어느 정도의 RAM이 필요한가?

스크립트는 941 MB 미만 환경에서는 Error: Cloudron requires atleast 1GB physical memory와 함께 실행을 거부하며, 공식 문서에서는 2 GB의 RAM과 20 GB의 디스크를 요구합니다. 이 수치들은 플랫폼 자체의 최소 사양일 뿐, 플랫폼 위에서 구동할 애플리케이션까지 고려한 것은 아닙니다. 애플리케이션을 하나도 설치하지 않은 상태에서도 Cloudron은 이미 Docker, nginx, 자체 box 서비스, 애플리케이션에 제공하는 데이터베이스 컨테이너(MySQL, PostgreSQL, MongoDB), Redis 및 메일 스택을 실행 중입니다. 초기 설치 직후 docker ps를 실행하여 직접 확인해 보십시오.

애플리케이션의 메모리 제한은 이 기본 사양 위에 추가됩니다. 각 애플리케이션 패키지는 낮은 기본 제한값을 가지고 있으며, 애플리케이션의 Resources 화면에 있는 슬라이더를 통해 이를 높일 수 있습니다. 애플리케이션이 제한값을 초과하면 재시작되면서 OOM(Out of Memory) 알림을 보냅니다. 따라서 특정 애플리케이션이 계속 재시작된다면 이는 버그보다는 제한값 설정 문제일 가능성이 큽니다.

다음은 제가 권장하는 서버 사양입니다. 이는 다음 달에 서버를 다시 구축하지 않아도 될 수준의 권장 사항이며, 측정된 벤치마크 결과는 아닙니다.

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

애플리케이션 2개는 4 GB의 RAM과 60 GB의 디스크 환경에서 원활하게 동작합니다. 애플리케이션 10개 정도를 운영하려면 16 GB의 RAM과 240 GB의 디스크가 필요합니다. 플랫폼의 기본 점유 메모리는 줄어들지 않으며, 각 애플리케이션은 Docker 이미지, 데이터베이스, 자체 데이터를 추가하기 때문입니다. 디스크는 예상보다 빠르게 차오릅니다. 백업을 외부로 옮기기 전까지는 이미지, 애플리케이션 데이터, 로컬 백업이 하나의 볼륨을 공유하기 때문입니다.

Cloudron은 모든 애플리케이션에 무제한 스왑을 허용하므로, 설정한 메모리 제한은 RAM에만 적용됩니다. 스왑 파일이 없는 VPS 이미지에서는 swapon --show를 실행해도 아무것도 출력되지 않으며, 메모리 압박이 발생하면 애플리케이션이 느려지는 대신 즉시 OOM 재시작이 발생합니다. 2 GB의 스왑을 추가하는 것은 저렴한 보험과 같지만, 실제 메모리를 대체할 수는 없습니다. VPS 요금제 간의 가격 차이는 제한값을 조정하느라 소비하는 시간보다 훨씬 작으므로, 실제 VPS 비용을 확인하고 한 단계 더 높은 사양을 선택하십시오.

DNS: 앱 서브도메인을 작동하게 하는 와일드카드 레코드

Cloudron은 대시보드를 my.example.com에 배치하고 각 앱을 고유한 서브도메인에서 실행하므로, DNS는 나중에 설정하는 것이 아니라 필수 선행 조건입니다. 대시보드를 처음 열기 전에 다음 레코드들을 서버의 공인 IP 주소로 지정하십시오.

• my.example.com: A 레코드로 설정합니다. 대시보드 주소입니다.
• *.example.com: A 레코드로 설정합니다. 앱 서브도메인을 작동하게 하는 핵심 레코드이며, 이 설정 덕분에 앱을 설치하는 즉시 wiki.example.com 및 git.example.com가 올바르게 해석됩니다.
• example.com: A 레코드로 설정합니다. 베어 도메인(bare domain)에서 앱을 실행하려는 경우에만 필요합니다.

와일드카드 레코드는 명시적 레코드보다 우선순위가 낮으므로, 다른 곳을 가리키는 기존 www.example.com 레코드는 그대로 정상 작동합니다.

설치 과정에서 Cloudron이 이후 DNS를 어떻게 처리할지 선택해야 합니다.

• API 제공자: Cloudron은 Cloudflare, DigitalOcean, Route53, Hetzner, Porkbun, Linode, deSEC, Gandi, Namecheap 등 약 20여 개 업체의 토큰을 저장하여 메일 레코드를 포함한 모든 레코드를 직접 작성합니다.
• 와일드카드: 사용자가 직접 * 레코드를 추가하며, Cloudron은 아무것도 작성하지 않습니다.
• 수동: Cloudron이 각 레코드를 표시하면, 사용자가 앱을 설치할 때마다 직접 레코드를 추가해야 합니다.

와일드카드 DNS 레코드가 곧 와일드카드 인증서는 아닙니다. 기본 인증서 제공자는 Let's Encrypt Prod - Wildcard이며, 이는 DNS를 통해 소유권을 증명하므로 API 제공자를 사용할 때만 작동합니다. 와일드카드 또는 수동 백엔드를 사용하는 경우, HTTP를 통해 검증되는 앱당 인증서 방식(one certificate per app)으로 전환되며, 이 경우 인바운드 80번 포트를 항상 열어두어야 합니다. 사용 중인 도메인 등록 업체나 DNS 호스트가 API 목록에 있다면 해당 방식을 사용하십시오. 메일 레코드와 인증서 관리 업무가 자동화됩니다.

다음 단계로 넘어가기 전에 확인하십시오. dig +short my.example.com 및 dig +short anything.example.com 명령을 실행했을 때 모두 서버의 IP 주소가 출력되어야 합니다. 와일드카드 쿼리 결과가 출력되지 않으면 대시보드는 정상 작동하더라도 나중에 앱 설치가 실패합니다.

도메인이 Cloudflare 뒤에 있다면 레코드를 DNS only로 설정하십시오. Cloudflare 프록시는 HTTP와 HTTPS만 전달하므로 메일 포트가 차단되며, 모든 앱에서 방문자의 IP 대신 Cloudflare 주소만 보이게 됩니다.

설치 스크립트 실행

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

스크립트는 root 권한으로 실행하거나 sudo를 사용해야 합니다. 그렇지 않으면 가장 먼저 This script should be run as root. 메시지가 출력되기 때문입니다. 설치에는 수 분이 소요되며, apt 출력과 Docker 이미지 내려받기 과정이 로그 파일로 기록되므로 작업 중에는 별다른 메시지가 표시되지 않습니다. 두 번째 SSH 세션을 열어 다음 명령으로 진행 상황을 확인하십시오.

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

설치가 완료되면 After reboot, visit one of the following URLs and accept the self-signed certificate to finish setup. 메시지와 함께 서버 주소가 출력되며, 이어서 The server has to be rebooted to apply all the settings. Reboot now ? [Y/n] 여부를 묻습니다. yes를 입력하십시오. 재부팅 시점을 예약해야 한다면 --skip-reboot 플래그를 사용할 수 있으나, 서버가 다시 시작되기 전까지는 Cloudron을 사용할 수 없습니다.

최초 부팅: 도메인, DNS 백엔드 및 관리자 계정

https://<server-ip>을 열고 브라우저의 경고를 수락합니다. Cloudron이 아직 귀하의 도메인을 알지 못하므로 인증 기관에 요청할 수 있는 정보가 없어 인증서는 자체 서명된 상태입니다. Chrome에서는 Advanced을 클릭한 다음 Proceed to <ip> (unsafe)를 클릭합니다. Firefox에서는 Advanced을 클릭한 다음 Accept the Risk and Continue를 클릭합니다.

첫 화면에서 도메인을 묻습니다. example.com를 입력하면 대시보드가 my.example.com에 설정됩니다. cloudron.example.com과 같은 서브도메인을 대신 사용할 수 있으며, 이 경우 대시보드는 my.cloudron.example.com에 위치하게 됩니다. DNS 백엔드를 선택하고 API 토큰이 있다면 붙여넣은 뒤, 실제로 확인 가능한 이메일 주소로 관리자 계정을 생성하십시오. Let's Encrypt 등록 및 모든 플랫폼 알림이 해당 주소로 발송됩니다.

저장하면 Cloudron이 인증서를 요청하고 대시보드를 https://my.example.com로 이동시킵니다. 해당 시점부터 IP 주소 기반 URL은 작동하지 않으므로 새 URL을 즐겨찾기에 추가하십시오.

인증서: 갱신 대상 및 중단 시점

인증서 갱신은 자동으로 이루어지며, 인증 기관이 게시하는 일정인 ACME Renewal Information (ARI)을 따릅니다. 실제로는 만료 약 한 달 전에 갱신이 진행됩니다. 갱신에 실패하면 관리자 계정으로 이메일이 발송되며, 만료된 인증서는 내장된 자체 서명 인증서로 대체됩니다. 어제까지 잘 작동하던 사이트에 브라우저 경고가 뜨는 이유는 바로 이 대체 동작 때문입니다.

대부분의 문제는 두 가지 원인으로 발생합니다. HTTP 검증은 인바운드 80번 포트를 필요로 하므로, "어차피 모든 통신은 HTTPS"라는 이유로 80번 포트를 닫으면 Wildcard 또는 수동 DNS 백엔드를 사용하는 모든 애플리케이션의 갱신이 중단됩니다. DNS 검증은 쓰기 권한이 유지되는 API 토큰을 필요로 하므로, 토큰을 교체하거나 권한을 축소하면 경고 이메일이 도착할 때까지 갱신 실패 사실을 알 수 없습니다.

Domains 보기에는 즉시 갱신을 강제하는 Renew All 버튼이 있으며, 테스트를 위한 Let's Encrypt Staging 제공자도 있습니다. Staging 인증서는 의도적으로 브라우저에서 신뢰하지 않도록 설정되어 있습니다. 이는 운영 환경의 속도 제한을 소모하지 않고 원하는 만큼 재시도할 수 있도록 하기 위함입니다.

내장 메일 서버를 사용해야 합니까?

Cloudron은 IMAP 메일함, submission, sieve 필터, DKIM(DomainKeys Identified Mail) 서명 기능을 포함한 완전한 메일 스택을 제공합니다. 대시보드의 Email 메뉴에서 도메인별로 활성화할 수 있습니다. 메일 전송은 까다로운 작업이며, 이 과정에서 발생하는 어려움은 Cloudron의 문제가 아닙니다.

• 대부분의 VPS 제공업체는 스팸 방지를 위해 아웃바운드 25번 포트를 차단합니다. 일부 업체는 지원 티켓을 통해 차단을 해제해 줍니다. 서버에서 nc -zv aspmx.l.google.com 25 명령으로 테스트하십시오(명령어가 없으면 netcat-openbsd를 설치하십시오). 포트가 열려 있으면 succeeded을 반환하며, 차단된 포트는 타임아웃이 발생할 때까지 응답이 없습니다.
• PTR 레코드(역방향 DNS)는 DNS 호스트가 아닌 VPS 제공업체에서 설정하며, 메일 호스트 이름과 일치해야 합니다. 일반적인 PTR을 가진 주소에서 보낸 메일은 스팸 메일함으로 분류됩니다.
• API DNS 백엔드를 사용하면 SPF, DKIM, DMARC 레코드가 자동으로 작성됩니다. Wildcard 또는 Manual 백엔드를 사용하는 경우 직접 추가해야 하며, DKIM 레코드가 누락되면 서명된 모든 메시지를 검증할 수 없게 됩니다.

대부분의 사용자에게 적합한 설정은 Cloudron에서 메일을 수신하고, Email 설정 화면에서 구성한 SendGrid, Postmark, Mailgun, Amazon SES와 같은 릴레이를 통해 메일을 발송하는 방식입니다. 릴레이는 도메인의 모든 주소로 발송할 수 있도록 허용해야 합니다. 그렇지 않으면 서로 다른 발신자가 보낸 앱 알림이 거부될 수 있습니다. 메일 서버 운영이 서버를 구매하는 주된 목적이라면, 고유한 IP 평판을 가진 별도의 서버에 Mailcow와 같은 전용 메일 서버를 운영하십시오.

Cloudron Email을 전혀 사용하지 않는다면 제공업체의 방화벽에서 25, 465, 587, 993, 4190번 포트를 차단하십시오. 서버 내부가 아닌 외부 방화벽에서 차단해야 합니다. Cloudron은 iptables 규칙을 직접 작성하고 관리하기 때문입니다. 이는 사용자가 직접 ufw 규칙을 관리하는 일반적인 VPS와는 반대되는 방식입니다.

백업이 필요하기 전에 백업 대상을 설정하십시오

백업은 기본적으로 /var/backups의 로컬 파일 시스템, 즉 다른 모든 데이터와 동일한 디스크에 저장됩니다. 문서에서는 이를 명확히 경고합니다: "플랫폼 서버와 동일한 물리적 디스크에 백업을 보관하는 것은 위험합니다." 디스크 하나만 고장 나도 애플리케이션과 백업이 모두 사라집니다.

Backups를 열고 Backup Sites로 이동하여 첫날부터 다른 곳을 지정하십시오. S3 호환 객체 스토리지(Backblaze B2, Wasabi, Cloudflare R2, DigitalOcean Spaces 또는 두 번째 서버의 MinIO 버킷)가 일반적인 해결책이며, SSHFS, NFS, CIFS 및 일반 파일 시스템 대상도 지원합니다.

다음 세 가지 설정이 백업의 가치를 결정합니다:

• 형식(Format). tgz는 애플리케이션당 하나의 압축 아카이브를 생성하며 실행할 때마다 전체를 다시 업로드합니다. rsync은 변경된 파일만 업로드하므로 대용량 Nextcloud의 경우 비용이 훨씬 저렴하지만, 스토리지 API에 대한 요청 횟수가 훨씬 많아집니다.
• 암호화(Encryption). 파일 내용과 파일 이름을 모두 보호하는 선택적 AES-256 암호화입니다. Cloudron은 비밀번호 사본을 보관하지 않으므로, 비밀번호를 분실하면 본인을 포함한 누구도 백업을 복호화할 수 없습니다. 저장 버튼을 누르기 전에 자체 호스팅 비밀번호 관리자에 비밀번호를 저장하십시오.
• 보존(Retention). 7일간의 일일 백업과 4주간의 주간 백업과 같이 개수로 설정합니다. 객체 스토리지에 장기간 보존하면 매달 비용이 청구되므로, 지속적으로 지불할 의사가 있는 수치를 선택하십시오.

그런 다음 복원을 테스트하십시오. 작은 애플리케이션을 설치하고 대시보드에서 복원하여 데이터와 함께 정상적으로 돌아오는지 확인하십시오. 한 번도 복원해 본 적 없는 백업은 추측에 불과합니다.

무료 티어 제한 사항

2026년 8월 기준으로 무료 플랜은 설치된 앱 2개까지로 제한됩니다. 앱 업데이트, 앱별 백업, 방화벽, 메일 서버, 싱글 사인온(SSO) 등 나머지 모든 기능은 동일하게 제공됩니다. 3번째 앱부터는 라이선스가 필요합니다. 유료 플랜은 앱 개수 제한을 해제하며, 더 높은 등급의 플랜은 사용자 그룹 및 역할, 디렉터리 서버, 다중 백업 사이트 기능을 추가로 제공합니다. 가격은 변동될 수 있으므로 튜토리얼의 숫자를 확인하기보다 Cloudron 가격 페이지를 확인하십시오.

라이선스는 Cloudron 설치 1건당 적용되므로, 소형 서버 2대를 운영하는 비용은 대형 서버 1대를 운영하는 비용의 2배가 됩니다. 이러한 가격 정책 때문에 대부분의 사용자는 단일 대형 VPS를 선택하게 되는데, 이는 서비스를 여러 장비로 분산하라는 일반적인 권장 사항과는 배치됩니다. 나중에 서비스를 분리하면 비용을 두 번 지불해야 하므로, 이 점을 고려하여 서버 크기를 결정하십시오.

문제가 발생했을 때

내장된 점검 도구부터 시작하십시오. 이 도구는 DNS, 인증서, 디스크, 메모리 및 각 서비스를 순차적으로 확인하며 어떤 테스트에서 실패했는지 알려줍니다.

sudo cloudron-support --troubleshoot

그 후에는 일반적인 systemd(시스템 및 서비스 관리자) 도구를 사용하십시오. systemctl status box은 Cloudron 서비스 자체의 상태를 보고하며, journalctl -u box -n 100은 최근 로그를 출력하고, journalctl -u docker는 하위 컨테이너 런타임을 다룹니다. 설치 중 발생한 모든 오류는 /var/log/cloudron-setup.log에 기록됩니다.

대시보드가 로드되지 않는다면 대개 Cloudron의 문제라기보다 DNS나 제공업체의 방화벽 문제일 가능성이 큽니다. 노트북에서 dig +short my.example.com을 실행하여 서버 자체 규칙과는 별도로 관리되는 제공업체의 네트워크 방화벽에서 80번 및 443번 포트가 열려 있는지 확인하십시오. 처음부터 다시 시작하는 경우, 스크립트는 Error: Cloudron is already installed. To reinstall, start afresh와 함께 재실행을 거부하므로 서버를 새로 구축하는 것이 깔끔한 해결책입니다.

Cloudron이 적합하지 않은 경우

애플리케이션 운영이 목적이고 인프라 관리를 원치 않는다면 Cloudron이 적합합니다. 하지만 자신만의 방식으로 컨테이너를 직접 운영하려 한다면 Cloudron은 적합하지 않습니다. Cloudron은 nginx, Docker, 방화벽 설정을 직접 관리하므로 사용자가 수동으로 변경한 내용을 덮어쓰기 때문입니다. 만약 docker-compose 파일들을 관리하는 것이 계획이라면, 자신만의 Docker Compose 스택 앞에 Traefik 배치하기를 통해 플랫폼을 별도로 설치하지 않고도 동일한 자동 TLS 및 서브도메인 라우팅 기능을 구현할 수 있습니다. 아직 선택하지 않았다면 Cloudron, CasaOS 및 Coolify 비교를 통해 각 도구를 대조해 볼 수 있으며, 셀프 호스팅 가능한 서비스 목록을 먼저 확인하는 것이 설치 가이드부터 시작하는 것보다 더 나은 출발점이 될 것입니다.

FAQ

Cloudron은 VPS에서 어느 정도의 RAM을 필요로 합니까?

설치 스크립트는 941 MB 미만에서는 실행되지 않으며, 문서에서는 2 GB를 요구합니다. 하지만 이는 앱이 하나도 없는 플랫폼의 최소 사양일 뿐입니다. Cloudron은 첫 부팅부터 Docker, nginx, 자체 box 서비스, 데이터베이스 컨테이너 및 메일 스택을 실행합니다. 앱 2개 운영 시 4 GB, 앱 10개 정도 운영 시 16 GB를 예산으로 책정하십시오. 또한 스왑 파일을 추가해야 합니다. Cloudron은 앱에 무제한 스왑을 허용하므로, 스왑이 없는 서버는 메모리 부족 시 프로세스가 재시작될 수 있습니다.

Debian이나 이미 Docker가 실행 중인 서버에 Cloudron을 설치할 수 있습니까?

둘 다 불가능합니다. 스크립트는 릴리스 버전을 확인하여 Cloudron requires Ubuntu 20.04, 22.04, 24.04가 발생하면 중단되므로 Debian, Rocky, Alpine은 지원하지 않습니다. 또한 nginx, docker, node이 이미 설치되어 있어도 중단됩니다. Cloudron은 모든 구성 요소의 특정 버전을 고정 설치하며, nginx 설정과 iptables 규칙을 직접 작성하기 때문입니다. KVM VPS에서 깨끗한 Ubuntu 이미지로 시작하십시오.

대시보드는 작동하는데 앱 서브도메인이 실패하는 이유는 무엇입니까?

와일드카드 DNS 레코드가 누락되었기 때문입니다. 설치 과정에서 my.example.com에 대한 A 레코드를 생성하거나 요구하므로 대시보드는 해석되지만, wiki.example.com는 NXDOMAIN을 반환하며 브라우저는 사이트를 찾을 수 없다고 보고합니다. *.example.com에 대한 A 레코드를 서버 IP로 지정하여 추가한 뒤, 앱을 설치하기 전에 dig +short wiki.example.com 명령으로 확인하십시오.

Cloudron 메일 서버를 반드시 사용해야 합니까?

아닙니다. 수신 메일 기능을 끄고 Postmark, Mailgun, Amazon SES와 같은 외부 릴레이를 통해 메일을 발송할 수 있습니다. 이는 호스팅 제공업체가 아웃바운드 25번 포트를 차단하거나 IP 주소의 메일 평판이 없을 때 더 안전한 선택입니다. Cloudron Email을 완전히 사용하지 않는다면, 서버 내부가 아닌 제공업체의 방화벽에서 25, 465, 587, 993, 4190번 포트를 닫으십시오.

무료 플랜에서 앱 2개 제한에 도달하면 어떻게 됩니까?

대시보드에서 세 번째 앱 설치가 차단되며 라이선스 키를 요구합니다. 이미 실행 중인 앱은 영향을 받지 않으며, 계속 업데이트되고 백업이 수행되며 인증서도 유지됩니다. 라이선스를 추가하면 재설치 없이 제한이 해제되므로, 무료 플랜은 실제 도메인에서 플랫폼을 먼저 테스트해 보기에 적합한 방법입니다.