관리형 PaaS를 이미 떠났다면, VPS는 프로비저닝되었고, SSH 키는 추가되었으며, 터미널 커서가 설치 라인에서 깜빡이고 있습니다. 남은 질문은 하나뿐입니다: 무엇을 실행할 것인가 curl ... | bash Coolify를 위한 것인지, 아니면 Dokploy를 위한 것인지?
두 도구 모두 한 번의 명령으로 설치됩니다. 둘 다 Git-push 배포, 자동 SSL, 웹 UI, 그리고 Docker 위의 리버스 프록시를 제공합니다. 흥미로운 차이점은 프로덕션에서 드러나는 것들입니다: 각각이 표준 docker-compose.yml, 배포 중에 무슨 일이 일어나는지, 그리고 2026년 이 비교를 재편한 소식에 각 프로젝트가 어떻게 대응했는지. 여기서 가장 큰 비중을 차지하는 두 가지 소식은 다음과 같습니다: 2026년 1월 Coolify CVE 공개 그리고 Dokploy 라이선스 개편 같은 달의.
이 글은 승자를 가리기보다는 각 도구를 특정 사용 사례에 매칭합니다. 끝까지 읽으면 어느 것이 여러분의 워크플로에 맞는지 알게 되기를 바랍니다.
요약
- Coolify 는 더 오래되었고 더 큰 생태계를 갖추고 있으며(~55k GitHub 스타, 300개 이상의 원클릭 서비스 템플릿), 유휴 상태에서 더 무겁고, 전체가 Apache 2.0이며, 셀프 호스팅 쪽에는 유료 티어가 없습니다.
- Dokploy 는 더 젊고(~34k 스타), 유휴 상태에서 더 가벼우며, Apache 2.0 코어에 더해 향후 유료 기능(SSO, RBAC, 감사 로그, 화이트라벨링)을 제한하는 별도의 Source Available License를 갖추고 있습니다.
- Coolify는 현재 Docker Compose를 통한 무중단 배포를 할 수 없습니다. Dockerfile, Nixpacks, 또는 단일 이미지 배포를 통해서만 가능합니다. Dokploy는 Docker Swarm을 일급 모드로 제공합니다. Coolify의 Swarm은 실험적(experimental)으로 표시되어 있습니다.
- 2026년 1월 Coolify CVE는 v4.0.0(April 27, 2026)에서 패치되었습니다. Coolify를 업데이트하고 대시보드를 공개적으로 노출하지 마세요.
어느 도구도 정답이 아닐 때
Coolify와 Dokploy 둘 다 일부 환경에는 맞지 않는 형태입니다. 간단히 알아둘 만한 세 가지 대안:
- Kamal (37signals 제작): 한두 개의 앱을 가진 팀으로, UI를 전혀 원하지 않고 그저 노트북에서
kamal deploy를 원하는 경우. Coolify나 Dokploy보다 훨씬 더 단순하며 대시보드를 원하지 않을 때 올바른 선택입니다. - Dokku: 고전적인 Git-push 단일 서버 모델. 더 오래되었고, 범위가 더 작으며, 매우 안정적입니다. "하나의 VPS 위의 Heroku" 원조입니다.
- 베어 VPS 위의 GitHub Actions + Docker Compose: 가능한 가장 작은 스택. 오케스트레이션 UI는 없지만, 오케스트레이션 오버헤드도 없습니다. 배포 흐름이 다음과 같은 단일 앱에 적합합니다
docker compose pull && docker compose up -dCI에서 트리거됩니다.
여러분의 형태가 하나의 서버에 하나의 앱이라면, Coolify와 Dokploy 둘 다 아마 과합니다. 먼저 위의 옵션 중 하나를 시도해 보세요. 여러 앱, 여러 데이터베이스, 또는 작업을 운영하기 위해 UI가 필요한 비기술 구성원이 있는 팀이라면, Coolify-vs-Dokploy 선택이 적절합니다. 이 범주의 더 폭넓은 옵션 조사는, 다음에 대한 저희의 정리 글을 참고하세요 웹 UI가 있는 자체 호스팅 클라우드 플랫폼 가이드.
Coolify와 Dokploy 한눈에 보기
Coolify v4.0.0 stable 는 긴 베타 주기를 거쳐 April 27, 2026에 출시되었습니다. Dokploy는 다음 버전입니다 v0.29.4 May 11, 2026 기준. 둘 다 Heroku/Render/Vercel 대안 영역의 오픈소스 셀프 호스팅 PaaS 프로젝트이며, 둘 다 Docker를 UI, 기본 HTTPS 리버스 프록시(Traefik), 그리고 Git 기반 배포로 감쌉니다.
| 기능 | Coolify | Dokploy |
|---|---|---|
| 최신 안정 릴리스 | v4.0.0 (April 27, 2026) | v0.29.4 (May 11, 2026) |
| 라이선스 | Apache 2.0 | Apache 2.0 코어 + 유료 기능용 Source Available |
| 기술 스택 | PHP / Laravel | TypeScript / Node.js |
| GitHub 스타 | ~55,000 | ~34,000 |
| 최소 RAM(공식) | 2 GB | 2 GB |
| 최소 CPU(공식) | 2개 코어 | 명시되지 않음 |
| 유휴 RAM(커뮤니티 보고) | 500 MB – 1.2 GB | 300 – 400 MB |
| Docker Compose 무중단 | 지원 안 됨(Dockerfile/Nixpacks만) | 표준 Compose 처리 |
| 멀티 서버 클러스터링 | Docker Swarm(실험적) | Docker Swarm(네이티브) |
| ARM64 지원 | 예(Raspberry Pi OS 포함) | 문서에 명시되지 않음 |
| 빌드 시스템 | Nixpacks, Dockerfile, Docker 이미지 | Nixpacks, Dockerfile, Docker 이미지, Heroku Buildpacks, Paketo, Railpack |
| 리버스 프록시 | Traefik | Traefik |
| 셀프 호스팅 모니터링 범위 | 내장 메트릭 + 로그 뷰어 | 기본 리소스 메트릭 + AI 로그/빌드 오류 분석(v0.29.0+) |
저희의 견해: 더 낮은 유휴 오버헤드, 네이티브 멀티 서버 지원, 그리고 플랫폼별 손질 없는 표준 Docker Compose 처리를 원한다면 Dokploy를 선택하세요. 더 큰 원클릭 앱 라이브러리, ARM64/Raspberry Pi 지원, 또는 향후 유료 티어가 기다리지 않는 순수 Apache 2.0을 원한다면 Coolify를 선택하세요.
리소스 사용량과 VPS 사이징
셀프 호스팅 PaaS는 Heroku 비용을 절약해 줄 수 있습니다. 오케스트레이션 계층이 유휴 상태에서 2 GB VPS 중 1.5 GB를 먹어버리면, 배포할 여유가 남지 않습니다. 그래서 작은 서버에서 첫 번째 실질적인 질문은 이것입니다: 앱을 단 하나 배포하기도 전에 각 도구가 여러분에게 얼마나 많은 비용을 들게 하는가?
Coolify의 유휴 RAM 사용량은 어떤 모니터링이 활성화되어 있는지에 따라 다르며, 5–7% 기준 CPU 사용량을 보이다가 메트릭 스크레이프가 실행될 때 급증합니다. Coolify 자체 문서는 3개의 Node.js 앱, 4개의 정적 사이트, 그리고 몇 개의 데이터베이스를 실행하는 8 GB RAM, 4코어, 150 GB 스토리지의 대표적인 프로덕션 워크로드를 사용합니다. 여러분의 스택이 비슷해 보인다면 합리적인 사이징 기준입니다.
반면 Dokploy는 훨씬 가볍게 실행되며, 아무것도 배포하지 않을 때 CPU 사용량이 2%를 훨씬 밑돕니다.
A LogRocket 프로덕션 분석 글 두 도구를 나란히 실행한 결과 같은 방향의 결론에 도달했습니다: Dokploy 앱에서의 docker stop && docker start 는 전체 재빌드를 트리거하지 않지만, Coolify에서 같은 작업은 트리거합니다. 그것만으로도 안정 상태 비용이 Dokploy에 유리하게 기울어지며, 특히 재빌드 폭주가 CPU 예산을 먹어버리는 작은 VPS 플랜에서 그렇습니다.
사이징을 위해, 제가 추천하는 VPS 구성은 다음과 같습니다:
- Coolify, 가벼운 워크로드: 2 vCPU / 4 GB RAM / 120 GB NVMe is the practical starting point for Coolify plus a couple of small apps.
- Coolify, 프로덕션 기준 워크로드: 4 vCPU / 8 GB RAM / 160 GB NVMe to match Coolify's own documented 3 Node.js + 4 static sites + databases example.
- Dokploy, 가벼운 워크로드: 1 vCPU / 2 GB RAM / 60 GB NVMe is comfortable for a single small app.
- Dokploy, 프로덕션 여유분: 2 vCPU / 4 GB RAM / 120 GB NVMe gives you room for a small production stack.
프로 팁: Coolify의 유휴 RAM은 모니터링 설정에 따라 증가합니다. 메모리가 빠듯하다면, 더 큰 서버를 프로비저닝하기 전에 메트릭 스크레이프 간격을 줄이세요(또는 이미 다른 곳에서 Prometheus/Grafana를 실행 중이라면 내장 모니터링을 완전히 비활성화하세요).
배포의 현실: Docker Compose, Dockerfile, 그리고 무중단
대부분의 팀은 기존 docker-compose.yml 와 하나의 기대를 가지고 이 도구들 중 하나에 도착합니다: 파일을 붙여넣고, 배포를 클릭하고, 앱이 올라오는 것을 본다. 각 플랫폼이 표준 Compose를 어떻게 처리하는지, 그리고 다음 배포 중에 처리 중인 요청에 무슨 일이 일어나는지가 실질적인 차이가 드러나는 지점입니다.
Coolify는 Docker Compose, Dockerfile, Nixpacks(프로젝트 파일에서 자동 감지), 그리고 직접 Docker 이미지 배포를 지원합니다. 하지만 명확히 짚고 넘어갈 만한 함정이 있습니다: 무중단 배포(롤링 업데이트, 블루/그린)는 Coolify에서 Dockerfile, Nixpacks, 또는 단일 이미지 배포를 통해서만 작동합니다. Docker Compose를 통해서는 작동하지 않습니다. Coolify 메인테이너가 다음에서 확인해 주었습니다 GitHub 토론 "compose 기반 배포의 경우, 새로운 컨테이너를 시작하기 전에 모든 컨테이너가 중지되며, 현재 compose 기반 배포에는 롤링 업데이트가 없습니다."라고 했습니다. Compose에 대한 롤링 지원은 v5 로드맵에 있습니다. v4에는 추가되지 않습니다. 메인테이너가 제안하는 우회책은 Compose 스택을 개별 Coolify 서비스로 분할하는 것인데, Compose 파일이 실제 서비스 간 관계를 표현하고 있다면 이는 만만치 않은 마이그레이션입니다.
사용자가 체감하는 결과는 다음에서 드러납니다 Coolify에 관한 Hacker News 스레드, 한 운영자가 직설적으로 말했습니다: "앱을 업데이트할 때 대기 중인 요청은 그냥 죽어버립니다." 오늘날 Compose 배포에 대해서는 정확한 말입니다.
Coolify의 Compose 계층은 또한 프로젝트가 "매직 변수(magic variables)"라고 부르는 것을 추가합니다. 이는 헬퍼 이미지의 자동 주입, 네트워크 재작성, 그리고 환경 오버라이드를 의미합니다. 의도는 더 효율적이게 하는 것이지만, 부작용은 노트북에서 깔끔하게 실행되는 docker-compose.yml 가 때때로 Coolify에서 깔끔하게 실행되려면 조정이 필요하다는 것입니다. 같은 Hacker News 스레드 가 대표적인 사례를 드러냅니다: "docker-compose 안에 8개의 변수를 추가했는데, 7개만 인식됩니다." Compose 스택이 작고 표준적이라면 이런 문제를 겪지 않을 수도 있습니다. 크거나 특이하다면 겪게 될 것입니다.
Dokploy의 자세는 다릅니다. LogRocket의 실전 분석 글 은 Dokploy가 "기존 docker-compose.yml을 거의 또는 전혀 수정하지 않고 배포할 수 있"으며 Docker의 네이티브 라벨 기반 라우팅 모델에 가깝게 유지된다는 것을 발견했습니다. 같은 글은 Dokploy에서의 컨테이너 중지/시작이 전체 재빌드를 트리거하지 않는 반면, Coolify에서 같은 작업은 트리거한다고 언급합니다. 이는 Dokploy 문서의 공식적인 "무중단 보장"이라기보다는 런타임 동작에 대한 방향성 신호이지만, 작은 VPS 인스턴스에서 셀프 호스터들이 보고하는 내용과 일치합니다.
Dokploy는 또한 Nixpacks와 Dockerfile에 더해 Heroku Buildpacks, Paketo Buildpacks, 그리고 Railpack을 지원합니다. Heroku에서 넘어온 팀들에게, heroku.yml 또는 빌드팩 기반 워크플로의 경우, 그것이 가장 저항이 적은 경로입니다.
섹션 핵심 요점: 기존 서비스가 실제 Docker Compose 스택이라면, Coolify는 배포 전략을 재구성하거나 푸시마다 짧은 다운타임을 감수하도록 요구할 것입니다. Dokploy는 그렇지 않습니다.
보안: 2026년 1월 Coolify CVE 공개
저는 더 큰 이야기를 이렇게 읽습니다: Coolify는 업데이트를 유지하고 대시보드를 공개 인터넷에 노출하지 않는다면 오늘날 실행하기에 안전합니다. 이 공개가 프로젝트의 자격을 박탈하지는 않습니다. 책임 있는 공개 절차가 지켜졌고 패치가 배포되었습니다. 그것이 드러내는 것은 저권한 인증 사용자에게 열려 있던 공격 표면이 마땅한 것보다 넓었다는 점입니다. 그것은 프로젝트에는 설계 교훈이고 운영자에게는 운영 교훈입니다: 지금 노출 모델을 강화하세요.
프로 팁: 패치 후에도 Coolify 대시보드를 SSH처럼 다루세요. 사설 네트워크에 바인딩하거나, VPN 뒤에 두거나, 다음으로 앞단을 두세요 Tailscale. 설치 스크립트가 쉽게 만들어 준다는 이유만으로 8000 포트를 공개 인터넷에 노출하지 마세요.
Dokploy도 이런 종류의 문제에서 예외는 아닙니다. 다음 v0.29.3 릴리스 노트 는 Dokploy에서 확인된 보안 취약점을 인정하고 업그레이드와 함께 실행해야 하는 보안 패치 스크립트를 제공합니다. 더 작은 표면, 더 짧은 프로젝트 역사이지만, 같은 운영 규율이 적용됩니다: 패치가 나오는 날 업데이트하고, 대시보드를 공개 인터넷에 두지 마세요.
섹션 핵심 요점: CVE 이야기는 Coolify의 운영 관행에 대한 주의 신호이지 프로젝트에 대한 위험 신호는 아니지만, 업데이트 규율과 대시보드 노출 방식에 대한 기준을 높입니다.
라이선스: 무엇이 무료이고 무엇이 아닌가
Dokploy의 라이선스가 January 21, 2026에 개편되었습니다. 무엇이 바뀌었고 셀프 호스터에게 어떤 의미인지 알아봅니다.
Dokploy는 이제 코어에 대해 표준 Apache 2.0, 무엇이 오픈소스이고 무엇이 아닌지 사용자를 혼란스럽게 했던 이전의 비표준 변형 Apache 2.0을 대체합니다. 이제 별도의 Dokploy Source Available License가 다음 디렉터리의 코드를 관장합니다 proprietary/ 디렉터리: 소스는 공개되지만, 프로덕션 사용에는 비용이 발생합니다. Dokploy가 그 라이선스 뒤에 둘 것이라고 말하는 기능들:
- 싱글 사인온(SSO/SAML)과 고급 접근 제어
- 커스텀 브랜딩과 화이트라벨링
- 고가용성, 오토 스케일링, 그리고 재해 복구
- 고급 모니터링, 통합, 그리고 컴플라이언스 기능
이 프로젝트는 기존 오픈소스 기능을 유료 티어로 옮기지 않겠다고 명시적으로 약속했습니다. 향후 유료 기능은 엔터프라이즈 연결을 필요로 하는 조직을 대상으로 합니다. 오늘날 2FA는 이미 Startup 티어 뒤에 있습니다 Dokploy 가격 페이지.
Coolify의 상황은 단순합니다. 이 프로젝트는 GitHub에서 Apache 2.0. 셀프 호스팅 버전의 모든 기능이 무료입니다. 다음이 있습니다 Coolify Cloud 제공 , 메인테이너가 대신 호스팅해 주기를 원하는 팀을 위한 것이지만, 셀프 호스팅 버전은 기능 제한도 없고 지금 갖고 있지 않은 유료 티어로의 업그레이드 경로도 없는 완전한 제품입니다.
제 견해: 자신의 VPS에서 셀프 호스팅하는 솔로 개발자와 소규모 팀에게 Dokploy는 사실상 무료이며 앞으로도 그럴 것입니다. 결국 SSO, 세분화된 RBAC, 감사 로그, 또는 화이트라벨링이 필요한 조직에게는, Dokploy가 결국 유료 티어로 밀어붙일 것입니다. Coolify는 그렇지 않을 텐데, 로드맵에 그런 티어가 없기 때문입니다.
짚어둘 만한 출처 간 명확화: Dokploy의 셀프 호스팅 빌드는 기본 리소스 메트릭(CPU, 메모리, 스토리지, 네트워크)을 포함하며, v0.29.0은 다음을 추가했습니다 AI 기반 로그 및 빌드 오류 분석. Dokploy의 모니터링 시스템은 더 고급 모니터링 기능에 한해 클라우드 전용입니다. 그러나 모니터링은 기본적인 사전 컨테이너 리소스 메트릭의 경우 셀프 호스팅 설치에서 여전히 로컬로 실행됩니다.
멀티 서버와 클러스터링: 현실 vs 마케팅
조만간 단일 VPS로는 충분하지 않게 되며, 두 프로젝트 모두 랜딩 페이지에서 멀티 서버 지원을 두드러지게 마케팅합니다. 현장의 현실은 같지 않습니다.
Coolify의 공식 확장성 문서 는 그것에 대해 직설적입니다: Docker Swarm 지원은 실험적(experimental)으로 표시되어 있습니다. 표준 멀티 서버 패턴은 SSH로 연결된 검증된 원격 서버, 그들 사이에 공유되는 Docker Registry, 그리고 서버마다 실행되는 Traefik 인스턴스를 사용합니다. Swarm 모드는 같은 아키텍처(전부 ARM, 또는 전부 AMD64)의 최소 3대 서버가 필요합니다. Kubernetes는? "계획만 있을 뿐, 아직 로드맵에 없으므로 ETA가 없습니다." 이에 대한 Coolify 자체 페이지를 읽어보면, 짧게 요약하면 이렇습니다: 멀티 서버는 작동하고, Swarm은 베타이며, Kubernetes는 비전입니다.
Dokploy는 실험적 플래그 없이 Docker Swarm을 일급 모드로 제공합니다. Traefik은 단일 서버와 Swarm 설정 모두에서 라우팅을 처리합니다. v0.29.0 릴리스는 비루트 멀티 서버 지원을 추가하여, 실질적인 공백을 메웠습니다(원격 노드 추가를 위한 루트 전용 SSH가 더 이상 필요 없습니다).
멀티 노드 클러스터링이 "언젠가 슬라이드 위에서"가 아니라 향후 6개월 안에 필요한 것이라면, Dokploy가 오늘날 더 낮은 위험의 선택입니다.
섹션 핵심 요점: 클러스터링이 단기 로드맵에 있다면, Swarm 차이가 다른 축과 무관하게 추천을 Dokploy 쪽으로 뒤집습니다.
빌드 시스템과 언어 지원
Heroku에서 넘어온 팀들은 각 도구가 어떤 빌드팩 생태계를 지원하는지를 가장 중요하게 여길 텐데, 그것이 첫 배포 전에 프로젝트를 얼마나 많이 재작성해야 하는지를 결정하기 때문입니다.
Coolify의 빌드 경로는 Nixpacks(기본값, 프로젝트 파일에서 자동 감지), Dockerfile, 또는 사전 빌드된 Docker 이미지입니다. Nixpacks는 일반적인 경우(Node, Python, PHP, Go, Rust)에 견고하지만, 자동 감지에는 거친 부분이 있습니다. 여러분의 스택에 대해 확인해 볼 가치가 있습니다: 2026년 1월 Nixpacks 이슈는 둘 다 사용하는 Laravel 프로젝트에 영향을 미쳐 composer.json 및 package.json 중복된 Nginx location 블록을 생성했고, 이는 업스트림이 수정할 때까지 일부 배포를 망가뜨렸습니다.
Dokploy는 Nixpacks, Dockerfile, 그리고 Docker 이미지를 지원하며, 그 위에 Heroku Buildpacks, Paketo Buildpacks, 그리고 Railpack을 추가합니다. 프로젝트가 이미 heroku.yml 또는 빌드팩으로 깔끔하게 빌드된다면, Dokploy는 그 워크플로를 그대로 유지하게 해줍니다. Coolify는 변환을 요구할 것입니다.
겉으로 보기에 두 도구는 같아 보입니다: GitHub, GitLab, Bitbucket으로부터의 Git-push 배포, 자동 Let's Encrypt SSL, 환경 변수와 데이터베이스 관리를 위한 웹 UI. 빌드 시스템의 폭은 Dokploy가 명확히 더 멀리 뻗어 나가는 몇 안 되는 지점 중 하나입니다.
원클릭 앱 카탈로그
알려진 오픈소스 서비스(n8n, Plausible, Supabase, Ghost, Listmonk 등 흔한 셀프 호스팅 단골들)를 배포하고 싶은 비기술 운영자에게, 원클릭 템플릿 라이브러리의 규모는 실질적인 차별화 요소입니다. 일부 사용자에게는 그것이 성능이나 경량성 같은 다른 영역보다 더 중요합니다.
Coolify는 다음을 제공합니다 300개 이상의 원클릭 서비스 약 40개 카테고리에 걸쳐: AI, 분석, 자동화, 데이터베이스, 보안, 스토리지 등. 압도적인 차이로 더 큰 라이브러리이며, Compose 파일을 작성하지 않고 서비스를 배포하고 싶은 비개발자에게 실질적인 해답입니다.
Dokploy의 템플릿 라이브러리는 더 작습니다. 현재 Dokploy 문서는 정확한 수치를 공개하지 않으므로, 숫자를 제시하지 않겠습니다.
실질적인 해답: 여러분의 워크플로가 "n8n, Supabase, Plausible을 각각 두 번의 클릭으로 배포"하는 것이라면, Coolify가 이 축에서 깔끔하게 이깁니다. 직접 만든 앱을 그냥 배포하고 싶은 것이라면, 카탈로그 규모는 중요하지 않고 다른 축이 중요합니다.
선택 방법: 사용 사례별 추천
여기에 단일 승자는 없습니다. 도구와 배포 형태 사이의 매칭이 있을 뿐입니다:
- 서비스 라이브러리를 원하는 비기술 팀: Coolify. 300개 이상의 템플릿 카탈로그가 의미 있는 우위입니다.
- 경량성 + 표준 Compose 처리를 원하는 Docker 네이티브 개발자: Dokploy.
- ARM64 하드웨어(Raspberry Pi, ARM 기반 VPS): Coolify. Dokploy는 현재 문서에서 ARM64 지원을 광고하지 않습니다. ARM을 사용 중이라면, 달리 확인하기 전까지는 Coolify를 기본으로 선택하세요.
- 이번 분기에 사용할 멀티 노드 클러스터링: Dokploy. 네이티브 Swarm 대 실험적 Swarm이 결정적 요인입니다.
- 순수 Apache 2.0, 향후 유료 티어 가능성 없음: Coolify.
- Heroku에서 마이그레이션하며 Heroku Buildpacks를 유지하고 싶음: Dokploy.
- 2026년 1월 CVE가 걱정됨: 업데이트된 Coolify(v4.0.0+)면 괜찮습니다. 진짜 문제는 여러분의 노출 모델입니다. 대시보드를 사설 네트워크나 VPN에 바인딩할 수 없다면, Dokploy가 더 부담 없는 선택입니다: 더 작은 표면과 고위험 공개의 더 짧은 역사.
어느 도구든 배포에 관한 참고 사항
일단 선택하고 나면, 설치 자체는 어느 프로젝트에서나 한 번의 명령이지만, 알아둘 만한 지름길이 있습니다. Coolify와 Dokploy 둘 다 다음에서 원클릭 배포로 이용 가능하며 저희 마켓플레이스Ubuntu 24.04와 Docker가 미리 설치되어 있고 대시보드에 이미 접근할 수 있습니다. 수동 설정을 건너뛰고 싶다면, 다음에 대한 마켓플레이스 목록이 Coolify 및 Dokploy 가 가장 빠른 경로입니다. 깨끗한 OS에서 시작해 공식 설치 프로그램을 직접 실행하고 싶다면, 두 프로젝트 모두 한 줄짜리 스크립트를 공개합니다. 여러분의 프로비저닝 워크플로에 맞는 쪽을 선택하세요.
자주 묻는 질문
2026년 라이선스 변경 이후에도 Dokploy는 여전히 오픈소스인가요?
코어 플랫폼에 대해서는 예. January 21, 2026부로, Dokploy의 코어는 표준 Apache 2.0입니다. 이제 별도의 Dokploy Source Available License가 다음 디렉터리의 코드를 관장하며 proprietary/ 디렉터리, 현재는 향후 엔터프라이즈 기능(SSO/SAML, 세분화된 RBAC, 감사 로그, 화이트라벨링)으로 범위가 한정됩니다. 솔로 및 소규모 팀의 셀프 호스팅 사용에 대해, Dokploy는 사실상 오픈소스입니다.
2026년 1월 Coolify 보안 취약점은 여전히 우려 사항인가요?
공개된 11개의 CVE는 Coolify v4.0.0(released April 27, 2026)에서 패치되었습니다. v4.0.0 이상을 실행 중이라면, 공개된 취약점은 해결되었습니다. 남은 것은 노출입니다: Coolify를 업데이트 상태로 유지하고 대시보드를 공개 인터넷에 노출하지 마세요. 사설 네트워크에 바인딩하거나 VPN 뒤에 두세요.
