self-hosted PaaS — 내 하드웨어에서 앱을 운영한다
Heroku 나 Vercel 이 해 주는 일을 내 하드웨어에서 합니다. VPS 든 사무실 서버든 집에 둔 미니 PC 든 같습니다. 데이터와 설치한 애플리케이션은 외부 서비스가 아니라 내 장비에 남습니다.
제품을 가르는 기준
이 부류의 제품은 모두 앱을 쉽게 설치하려고 만들어졌습니다. 차이는 설치한 다음에 있습니다.
- DB 를 만들고 앱에 연결하는 일
- 도메인과 HTTPS 인증서 설정
- 앱마다 계정을 새로 만들지 않고 로그인하도록 잇는 일
- 백업 일정과 저장소 구성
- 앱과 앱 사이의 주소·자격 정보 연결
- 업그레이드와 장애 대응
대부분의 self-hosted PaaS 는 앱 설치까지를 자동화합니다. 그 뒤의 구성과 연결은 사람이 합니다.
이 글에서 함께 보는 제품
- Coolify — 오픈소스. Docker 기반이고 원클릭 카탈로그가 큽니다. 비교
- Dokploy — 오픈소스. Docker Swarm 을 쓰고 Compose 파일을 그대로 활용합니다. 비교
- CapRover — 오픈소스. Docker Swarm 기반이고 템플릿으로 앱을 설치합니다. 비교
- OpenShift — Red Hat 의 Kubernetes 플랫폼. 클러스터 운영 역량을 전제로 합니다.
- tidoly — 표준 Kubernetes(k3s) 위의 상용 PaaS. 카탈로그에서 앱을 고르면 필요한 자원과 연결까지 함께 구성합니다.
배포 방식과 장애 대응
Coolify 는 웹훅으로 빌드한 뒤 SSH 로 서버에서 컨테이너를 실행합니다. 오케스트레이션 계층이 없어 서버가 멈추면 워크로드가 다른 서버로 옮겨 가지 않습니다. 서버를 여러 대 써도 기본적으로 각각 관리합니다.
Dokploy 와 CapRover 는 Docker Swarm 을 씁니다. 노드를 여럿 두면 노드 장애 시 워크로드가 다른 노드에서 다시 뜹니다.
tidoly 는 Kubernetes(k3s) 위에서 GitOps 로 배포합니다. 배포 상태를 선언으로 관리합니다. 지금은 서버 한 대 기준이라, 노드 사이 워크로드 이동은 공유 스토리지 구성이 먼저입니다.
tidoly 가 다른 점
tidoly 의 카탈로그는 "이 앱을 설치한다" 만 정의하지 않습니다. 앱이 필요로 하는 데이터베이스·로그인·저장소·도메인까지 함께 정의합니다. 설치하면 플랫폼이 그 자원을 만들고 서로 연결합니다.
- 데이터베이스 — 생성부터 계정 발급, 자격 정보 주입까지 합니다. 비밀번호를 사람이 옮겨 적지 않습니다.
- 도메인 — 도메인을 넣으면 Ingress 와 TLS 가 붙습니다. 발급도 갱신도 자동입니다.
- 로그인 — OIDC client 생성과 콜백 주소 설정까지 합니다.
- 앱 간 연결 — 무엇이 무엇을 필요로 하는지 타입으로 정의합니다. 주소나 자격이 바뀌면 쓰는 쪽도 같이 갱신됩니다.
- 오브젝트 스토리지와 사설망 — S3 호환 저장소(SeaweedFS)와 사설망(headscale)도 다른 항목과 똑같은 카탈로그 항목이고, 연결된 채로 들어옵니다. 외부 버킷도, 키 교환도 없습니다.
- 백업 — 앱을 설치할 때 백업 일정과 저장소를 같이 구성합니다.
- MCP — 컨트롤 플레인이 MCP 서버를 열어, AI 에이전트가 회수할 수 있는 전용 계정으로 — 노트북에서 사이트 사설망(VPN)을 거쳐 — 앱을 만들고 빌드·배포합니다. 카탈로그의 Gitea 는 이슈·PR 용 MCP 서버를 같이 설치할 수 있습니다.
이 계층을 애플리케이션 의존성 해결(Application Dependency Resolution) 이라고 부릅니다. Service Binding 같은 표준은 그 아래에서 자격 정보를 워크로드에 전달하는 방법을 다룹니다. tidoly 는 그보다 앞에서 무엇이 필요하고 무엇과 이어져야 하는지를 정하고 만듭니다.
Service Binding 이 연결 정보를 전달하는 방법이라면, tidoly 는 무엇을 만들어 무엇과 연결할지 정하는 쪽입니다.
한 제품이 아니라, 한 묶음을 대신합니다
self-hosting 으로 서비스를 운영하려면 제품 하나를 설치하고 끝나지 않습니다. 다음을 각각 고르고 이어야 합니다.
- 서버 — VPS · 전용 서버 · 사내 장비 중 무엇을 쓸지
- Kubernetes 운영 — 설치, 업그레이드, 노드 관리
- 앱 배포 — Helm chart 나 Operator 를 찾고 값을 맞추고 유지
- 클러스터 관리 — Rancher 같은 관리 도구
- 관측 — 메트릭 수집, 로그, 대시보드
- 네트워크와 인증서 — Ingress, 도메인, TLS 발급과 갱신
- 로그인 — 앱마다 다른 인증 방식을 OIDC 로 연결
- 앱 카탈로그 — 무엇을 어떤 버전으로 설치하고 어떻게 업데이트할지
각 영역에는 이미 좋은 제품이 있습니다. 문제는 고르고 연결하는 일이 사람 몫이라는 것입니다.
하나를 바꾸면 다른 것도 따라 바뀝니다. DB 를 바꾸면 앱의 연결 정보가 바뀌고, 도메인을 바꾸면 인증서와 콜백 주소가 바뀝니다. 앱을 업데이트하면 설정을 다시 확인해야 합니다. 결국 이 연결 관계를 아는 사람이 계속 필요합니다.
tidoly 는 그 연결을 대신합니다. 위의 구성 요소를 하나의 설치 과정과 하나의 화면으로 묶습니다.
서버는 고객의 것입니다. tidoly 가 대신하는 건 서버를 가져가는 일이 아니라, 그 위에서 도는 서비스를 설치하고 연결하고 운영할 수 있게 만드는 일입니다.
그래서 아래 표는 "어느 제품이 더 좋은가" 가 아니라 "어디까지를 사람이 직접 해야 하는가" 를 기준으로 봐야 합니다.
self-hosting 비교표
| 항목 | tidoly | Coolify | Dokploy | CapRover | OpenShift |
|---|---|---|---|---|---|
| 기반 | Kubernetes (k3s) | Docker | Docker Swarm | Docker Swarm | Kubernetes |
| 앱 배포 | 자체 파이프라인 + GitOps | SSH + Docker | Swarm | Swarm | S2I / BuildConfig |
| 여러 노드 | 단일 서버⁷ | 개별 관리 | Swarm | Swarm | 클러스터 |
| 전담 인력(인프라 지식)¹ | X | O | O | O | O |
| 오픈소스 | X | O | O | O | X² |
| 카탈로그에서 앱 설치 | O | O | O | O | O |
| 데이터베이스 생성 | O | O | O | O | O |
| └ 앱에 자격 정보 전달까지 | O | X | X | X | X³ |
| └ 자격 변경 시 앱 갱신 | O | X | X | X | X |
| 백업 스케줄 | O | O | O | X | O |
| └ 앱 설치 시 함께 구성 | O | X | X | X | X |
| └ 백업 저장소 제공 | O | X | X | X | X |
| 도메인 + HTTPS 자동 구성 | O | O | O | O | O |
| 사설망(VPN) 연결까지 구성 | O | X | X | X | X⁶ |
| 설치한 앱의 로그인 구성 | O⁴ | X | X | X | X |
| 앱 간 연결 유지 | O | X | X | X | X |
| 업그레이드 준비 | O⁵ | X | X | X | X |
| 노드 장애 시 워크로드 이동 | 아직⁷ | X | O | O | O |
| AI 에이전트(MCP) | O | O | O | X | X |
2026년 8월 21일 각 제품의 공개 문서를 기준으로 작성했습니다.
주석
¹ 전담 인력(인프라 지식) — Docker 기반 세 제품은 Kubernetes 를 쓰지 않습니다. 그렇다고 운영 지식이 필요 없는 것은 아닙니다. DB · 백업 · 로그인 · 인증서 · 업그레이드는 여전히 사람이 구성하고 관리합니다. OpenShift 는 여기에 클러스터 운영이 더해집니다. 이 행에서만 O 가 「필요함」을 뜻합니다.
² 오픈소스 — OpenShift 는 구독 제품이고, 오픈소스 프로젝트로 OKD 가 따로 있습니다.
³ 자격 정보 전달 — Service Binding 은 자격 정보를 워크로드에 전달하는 방법을 다룹니다. 여기서 묻는 것은 그 앞 단계입니다 — 카탈로그가 앱에 필요한 자원을 선언하고, 플랫폼이 그 자원을 만들어 연결하는가.
⁴ 로그인 구성 — 카탈로그의 Gitea · Grafana · Rocket.Chat, 그리고 플랫폼의 Argo CD · Kubernetes API 가 대상입니다. OIDC 를 지원하지 않거나 유료 판에서만 지원하는 앱은 연결하지 않습니다.
⁵ 업그레이드 — 새 버전이 업그레이드 계획과 함께 내려오고, 관리자가 승인한 뒤 적용됩니다.
⁶ 사설망과 VPN — 다른 제품에도 VPN 템플릿은 있습니다. 다만 설치 후 키 · 피어 · 엔드포인트 설정이 사용자 몫으로 남는 경우가 많습니다. tidoly 는 카탈로그에서 필요한 연결까지 함께 구성합니다. 고정 IP 없이 외부에 공개하는 터널링은 별도 유료 옵션입니다.
⁷ 단일 서버 — 지금 배포판은 서버 한 대 기준입니다. 여러 노드에 걸친 고가용성은 공유 스토리지 구성이 먼저이고, 아직 제공하지 않습니다.
결국 차이는 설치 이후입니다
다섯 제품 모두 내 서버에 앱을 설치합니다. 데이터와 설치한 애플리케이션도 내 장비에 남습니다.
차이는 그다음입니다 — DB 를 만들고, 로그인을 잇고, 도메인을 붙이고, 인증서를 관리하고, 백업하고, 다른 앱과 연결하고, 업그레이드하는 일을 누가 하느냐입니다.
Coolify · Dokploy · CapRover 는 훌륭한 self-hosted PaaS 입니다. 오픈소스와 앱 카탈로그의 규모가 중요하다면 좋은 선택입니다. tidoly 는 상용 제품이고 트라이얼이 있습니다.
tidoly 가 풀려는 문제는 조금 다릅니다.
앱을 설치하는 데서 끝나지 않고, 앱이 운영에 필요로 하는 것들을 함께 만들고 연결하는 것.