셀프 호스팅 PaaS (Platform as a Service)라는 서랍은 비어 있지 않습니다. Coolify, Dokploy, CapRover, Dokku, Kamal 등이 있죠. 만약 당신이 실제로 소유할 수 있는 Heroku를 원했다면, 누군가는 이미 당신을 위해 세 가지나 만들어 두었을 것입니다.

그래서 2026년 7월 Openship이 등장하여 약 일주일 만에 수천 개의 GitHub stars를 기록했을 때, 합리적인 반응은 회의론이었습니다. 또 다른 docker compose up을 위한 대시보드일 뿐이라고 생각했죠.

하지만 이를 자세히 읽어보니, 실제로 다른 아키텍처적 결정이 하나 있었고, 이는 4 GB VPS (Virtual Private Server) 환경에서 체감할 수 있는 종류의 차이였습니다. 이 포스트에서는 그 결정이 무엇인지, 세 가지 다른 방식으로 실행하는 방법, 그리고 당신이 아끼는 무언가를 아직 여기에 올려도 될지에 대한 솔직한 견해를 다룹니다.

중요한 단 하나의 아이디어

해당 서랍에 있는 모든 셀프 호스팅 PaaS는 전체 컨트롤 플레인 (Control Plane)을 당신의 서버에서 실행합니다. 대시보드, 이를 뒷받침하는 데이터베이스, 빌드 시스템, CI (Continuous Integration) 러너, 웹훅 (Webhook) 리스너, 그리고 실제 앱이 모두 하나의 박스와 하나의 리소스 세트를 공유합니다.

4 GB VPS에서 Next.js 빌드가 실행 중인 프로덕션 컨테이너의 자원을 고갈시켜 사이트를 다운시킬 때, 당신은 이를 처음으로 깨닫게 됩니다. 당신의 배포 도구가 배포 대상인 서비스의 신뢰성 리스크가 되어버린 것입니다.

Openship은 이를 뒤집습니다. 컨트롤 플레인은 당신의 로컬 머신이나 별도의 박스에서 실행되며, SSH를 통해 당신의 서버들을 구동합니다. 빌드는 로컬에서 이루어집니다. 프로덕션으로 전송되는 것은 완성된 컨테이너 이미지입니다.

당신의 컴퓨터                              당신의 서버
┌──────────────────────┐         ┌──────────────────────┐
│  Desktop / Web UI    │   SSH   │                      │
...

실질적인 결과는 다음과 같이 명확히 설명할 가치가 있습니다:

당신의 프로덕션 서버는 빌드 규모의 리소스가 필요하지 않습니다. 서버는 컨테이너를 실행할 뿐입니다. 그게 전부입니다. 작은 VPS로도 더 많은 일을 할 수 있습니다.

당신의 배포 도구는 공개적인 공격 표면 (Attack Surface)이 없습니다. 데스크톱 구성에서 Openship은 포트를 노출하지 않으며 공개 URL도 없습니다. 인터넷에서 접속 가능한 유일한 것은 당신이 의도적으로 도메인을 할당한 앱뿐입니다.

빌드(Builds)는 당신의 노트북 CPU를 사용하며, 이는 거의 확실하게 당신의 VPS가 사용하는 공유 vCPU보다 빠릅니다.

이 트레이드오프(tradeoff)는 솔직하며 유지 관리자들도 이를 명시하고 있습니다: 대시보드는 당신의 머신이 켜져 있는 동안에만 작동합니다. 팀원의 접근도 불가능하고, 전화 접근도 불가능하며, 푸시 투 디플로이(push-to-deploy) 웹훅(webhook)을 위해서는 노트북이 갖추지 못한 안정적인 공개 엔드포인트(public endpoint)가 필요합니다. 만약 이러한 기능들이 필요하다면, 대신 서버에서 컨트롤 플레인(control plane)을 실행하면 됩니다. 이 시점에서 당신은 일반적인 구성을 다시 만든 것이지만, 기본값이 아닌 의도적인 선택으로서 재구축한 것입니다.

서버에서 빌드하는 기능 또한 설정 플래그(config flag)로 제공됩니다. README의 표현을 빌리자면, 이것은 하나의 설정 플래그이지 종교가 아닙니다.

실제로 무엇이 포함되어 있는가

Openship은 배포 이상의 것을 묶어서 제공합니다:

내장된 메일 서버가 특이한 점입니다. 올바른 DKIM, SPF, DMARC를 갖춘 자체 SMTP를 운영하는 것은 진정으로 번거로운 일이며, 대부분의 셀프 호스팅(self-hosted) PaaS 도구들은 SES나 Mailgun을 사용하라고 권합니다. 이것이 실제 전송률(deliverability) 측면에서 살아남을 수 있을지는 별개의 문제이지만, 기능 목록에서 확실한 차별화 요소입니다.

내부적으로는 TypeScript 모노레포(monorepo)로 구성되어 있습니다: Electron 데스크톱 앱, Next.js 대시보드(React 19, Tailwind 4, 터미널용 xterm.js), 그리고 Commander와 Clack을 기반으로 구축된 CLI가 포함됩니다. 단일 OPENSHIP_TARGET 환경 플래그가 인스턴스가 desktop, selfhosted, 또는 cloud로 동작할지를 결정하며, 이것이 바로 동일한 코드베이스가 로컬 앱과 관리형 SaaS를 모두 구동하는 이유입니다.

먼저 설정을 선택하세요

설치 경로는 전적으로 누가 사용하는지, 그리고 당신의 머신이 꺼져 있을 때도 서비스가 가동되어야 하는지에 따라 달라집니다.

설치하기 전에 결정하십시오. 나중에 전환하는 것도 가능하지만, 아무런 작업이 필요 없는(no-op) 것은 아닙니다.

경로 1: 데스크톱 앱 (솔로용, 그리고 권장되는 방식)

openship.io에서 사용 중인 OS용 빌드를 다운로드하거나, CLI를 통해 가져오도록 할 수 있습니다:

openship install

Linux의 경우 다운로드되는 파일은 AppImage입니다:

chmod +x Openship.AppImage && ./Openship.AppImage

처음 실행하면 무엇을 관리할지 묻습니다:

• This Machine (이 머신) — 로컬 장비를 관리합니다.
• Another Server (다른 서버) — 호스트(host), 사용자(user), 키(key)를 사용하여 SSH를 통해 원격 서버를 추가합니다. '연결 테스트 (Test Connection)' 버튼이 있습니다. 배포 도중보다 여기서 SSH 문제가 훨씬 더 명확하게 드러나므로, 더 진행하기 전에 이 버튼을 사용하십시오.

이 설정 단계는 Openship의 아키텍처가 가장 빛을 발하는 부분입니다. 플랫폼의 어떤 것도 외부에 노출되지 않습니다. 나중에 서버 설정을 원하더라도 여기서 시작할 가치가 있는데, 공개 배포(public deployment)에 대한 디버깅 없이 모델을 익힐 수 있기 때문입니다.

경로 2: 서버에서의 CLI (팀 및 CI용)

먼저 도메인의 DNS A 레코드를 서버로 지정하십시오. 나중에 이 작업을 하면, 인증서 단계가 반복적으로 실패하는 동안 DNS 전파(propagation)를 기다려야 합니다.

API와 대시보드(dashboard)가 포함된 CLI를 설치합니다:

npm i -g openship
# 또는
curl -fsSL https://get.openship.io | sh

그 다음 실행합니다:

openship up --public-url https://ops.example.com --managed-edge

각 부분의 역할:

• openship up은 부팅 시 시작되고 자동 재시작되는 백그라운드 서비스(background service)로 Openship을 설치한 다음, 첫 번째 관리자(admin)를 생성하고 도메인을 연결하는 설정 마법사(setup wizard)를 실행합니다.
• --public-url은 대시보드에 도메인을 통해 접속할 수 있게 합니다. 로그인이 필요하며 공개 가입(public signup)은 비활성화되어 있습니다. 그 외의 인원은 초대를 통해 참여합니다.
• --managed-edge는 OpenResty를 설치하고 무료 Let's Encrypt 인증서를 프로비저닝(provisioning)하여 도메인을 대시보드로 라우팅합니다. 이미 자체 리버스 프록시 (reverse proxy)를 실행 중이라면 이 옵션을 생략하십시오. 그렇지 않으면 두 프로세스가 80 및 443 포트를 두고 경쟁하게 됩니다.

연결된 상태로, 서비스 형태가 아닌 실행을 원할 경우:

openship up --foreground

멋진 점은, 실행이 완료되면 Openship이 자체 대시보드에 앱으로 등록된다는 것입니다. 도메인을 관리하고, 로그를 테일링(tail)하며, 다른 모든 항목과 함께 Live 상태로 목록에 표시되는 것을 확인할 수 있습니다. 컨트롤 플레인 (control plane)을 예외적인 케이스가 아닌 일급 앱 (first-class app)으로 셀프 호스팅(Self-hosting)하는 이러한 디테일은, 누군가가 실제로 이 도구를 실전에서 치열하게 사용해 보았음을 시사합니다.

관리자 비밀번호를 분실한 경우:

openship reset-admin-password

이 명령은 내부 토큰을 사용하여 로그인 없이 로컬 머신에서 작동합니다. 이는 또한 다음과 같은 의미를 갖습니다: 해당 서버에 셸 (shell) 액세스 권한이 있는 사람은 누구나 귀하의 Openship 인스턴스를 소유하게 됩니다. SSH 액세스 권한을 그에 따라 적절히 관리하십시오.

경로 3: Docker Compose (그리고 유지 관리자가 이를 권장하지 않는 이유)

git clone https://github.com/oblien/openship.git && cd openship
cp .env.example .env
docker compose up -d

이 방법도 작동하지만, 문서는 이를 권장되지 않는 경로라고 명시적으로 표시하고 있으며, 그 이유는 무시하기보다는 이해할 가치가 있습니다.

Compose 스택은 컨트롤 플레인 컨테이너에 **호스트 Docker 데몬 (host Docker daemon)**에 대한 액세스 권한을 부여합니다. 이는 사실상 호스트 수준의 권한입니다. 호스트의 Docker 소켓 (socket)과 통신할 수 있는 컨테이너는 권한이 부여된 컨테이너를 시작하거나, 호스트 파일 시스템을 마운트(mount)하여 탈출할 수 있습니다. 이는 이론적인 것이 아니라 잘 알려진 권한 상승 (escalation) 경로입니다.

컨테이너화된 컨트롤 플레인을 원하는 정당한 이유가 있을 수 있습니다. 다만, 이 행위가 애초에 이 아키텍처의 핵심이었던 보안 태세 (security posture)를 맞바꾸는 일이라는 점을 인지하십시오.

무언가 배포하기

컨트롤 플레인이 실행되면, 앱 워크플로우는 간단합니다:

cd my-project
openship init          # 이 디렉토리를 프로젝트(.openship/project.json)에 연결
openship deploy        # 배포 트리거
...

Openship은 스택을 감지하고, 빌드하며, 설정을 연결하고, 컨테이너를 배포(ship)합니다. YAML 파이프라인 (pipeline)이나 Dockerfile이 필요하지 않습니다 (사용자가 원하는 경우 제외). 기존의 Docker Compose 파일도 있는 그대로 배포할 수 있습니다.

자동 감지(auto-detection) 주장은 실제로 믿기 전에 귀하의 실제 리포지토리(repo)를 대상으로 테스트해 봐야 할 부분입니다. 프레임워크 감지는 일반적인 Next.js 앱의 경우에는 쉽지만, 모노레포(monorepo) 구조가 복잡해질수록 그 마법 같은 기능은 점차 줄어듭니다.

CLI 치트 시트 (CLI cheat sheet)

인스턴스 관리 (Instance management):

배포 및 검사 (Deploy and inspect):

인프라 및 인증 (Infrastructure and auth):

대부분의 읽기 명령(read commands)에서 --json 옵션이 작동하므로 CI(지속적 통합) 환경에서 스크립트로 활용할 수 있습니다. 또한 openship api가 gh api 패턴을 따르는 것은 좋은 선택인데, 이는 이미 존재하는 엔드포인트(endpoint)에 대해 CLI 명령어가 작성될 때까지 기다리며 차단되는 일이 없음을 의미하기 때문입니다.

MCP 관점, 주의사항 포함 (The MCP angle, with a caveat)

Openship는 AI 에이전트가 배포를 수행할 수 있도록 MCP 지원을 제공합니다. 핵심 제안은 대략 이렇습니다: MCP 서버를 추가하면, 귀하의 에이전트가 작업을 수행할 수 있습니다.

잠시 멈춰서 생각할 가치가 있는 부분입니다. 귀하는 에이전트에게 배포 권한, 비밀 정보(secrets) 접근 권한, 그리고 운영 환경 롤백(rollback) 제어권을 넘겨주는 것입니다. 표준적인 MCP 위생 수칙(hygiene)이 적용되며, 여기서는 더욱 엄격하게 적용됩니다: 노출하는 도구(tools)의 범위를 제한하고, 에이전트가 운영(production) 환경이 아닌 스테이징(staging) 환경을 가리키도록 하며, 작동 가능한 가장 좁은 권한을 가진 개인 액세스 토큰(Personal Access Token)을 사용하고, 에이전트가 수행한 작업에 대한 감사 추적(audit trail)을 유지하십시오.

배포할 수 있는 에이전트는 아무도 지켜보지 않는 새벽 3시에 잘못된 것을 배포할 수도 있습니다.

실제로 얼마나 준비되었는가 (How ready is this, actually)

솔직하게 말씀드리겠습니다. 이 부분을 건너뛰는 dev.to 게시물들은 광고이기 때문입니다.

알려진 미흡한 점 (Known rough edges). 2026년 7월 기준으로, CLI 설치 프로그램과 셀프 호스팅(self-hosted) SSH 배포 경로에서 작동 오류가 발생한다는 보고가 열려 있습니다. 여기에는 성공적인 Docker 빌드 직후 배포가 즉시 실패하는 문제도 포함됩니다. 이슈 큐(issue queue)가 활발하게 운영되고 있다는 점은 대응 속도 측면에서 좋은 신호이며, 아직 초기 단계라는 명확한 증거이기도 합니다.

라이선스 (License). 이 부분은 매우 중요하며 잘못 파악하기 쉽습니다. Openship은 AGPL-3.0에 Commons Clause를 추가하여 출시되었습니다. 이는 오픈 소스 (Open Source)라기보다는 소스 가용 (Source-available) 방식이며, 이를 호스팅 서비스 (Hosted service)로 제공하는 것을 금지합니다.

로드맵 공백 (Roadmap gaps). 멀티 노드 클러스터 (Multi-node clusters), 로드 밸런싱 (Load balancing) UI, 프라이빗 네트워킹 (Private networking), 그리고 시각적 CI/CD 파이프라인 (Visual CI/CD pipelines)은 모두 출시된 것이 아니라 출시 예정 목록에 올라와 있습니다. 만약 클러스터링 (Clustering)이 필수 요구 사항이라면, 이 도구는 아직 당신을 위한 것이 아닙니다.

사용해야 할까요

다음의 경우라면 지금 바로 사용해 보세요: 당신이 1인 개발자 또는 소규모 팀이고, 사이드 프로젝트나 중요도가 낮은 서비스를 운영 중이며, 로컬 빌드 (Local-build) 아키텍처가 마음에 든다면 말입니다. 데스크톱 앱은 무엇도 노출하지 않고 평가를 위해 서버가 필요하지 않기 때문에, 실험해 보기에 진정으로 리스크가 낮습니다.

이 프로젝트의 진정한 기여는 아키텍처에 있습니다. 빌드 인프라 (Build infrastructure)를 프로덕션 박스 (Production box)에서 분리하는 것은 올바른 방향이며, 셀프 호스팅 PaaS (Self-hosted PaaS)가 이를 선택 사항이 아닌 기본값으로 취급하기까지 이렇게 오래 걸렸다는 점은 다소 이상합니다. 설령 Openship 자체가 이 카테고리에서 승리하지 못하더라도, 그 아이디어는 전파되어야 합니다.

링크:

• Repo: github.com/oblien/openship

만약 실제 VPS에서, 특히 SSH 배포 경로를 통해 실행한다면, 무엇이 작동하지 않았는지 댓글로 남겨주세요. 초기 프로젝트는 실패 보고가 구체적일 때 가장 빠르게 발전합니다.