Openship는 "저장소를 가리키기만 하면 빌드하고, 배포하고, 라우팅하고, TLS까지 처리해 준다"는 셀프 호스팅 배포 플랫폼이다. Vercel이나 Railway 같은 관리형 서비스가 제공하는 경험을, 자기 서버나 홈랩에서도 그대로 누릴 수 있게 만드는 것이 목표이다. 오픈소스이며 Apache 2.0 라이선스로 배포되고, 상용·비공개 제품에 포함해도 되는 조건이다.
이 프로젝트에서 눈에 띄는 부분은 "어떻게 실행할지"를 사용자 상황에 맞춰 세 갈래로 나눠 제시한다는 점이다. 혼자 쓰는 경우에는 데스크톱 앱을 열어둔 동안에만 제어판이 로컬에서 돌아가고, 앱 자체는 노트북에서 공개 앱을 호스팅하지 않고, 연결한 서버나 Openship Cloud에 배포한다. 팀 단위로 쓰거나 푸시 한 번으로 자동 배포(push-to-deploy)가 필요하면 openship up 명령으로 상시 구동되는 서버를 세운다. 아예 아무것도 직접 운영하고 싶지 않다면 Openship Cloud라는 관리형 옵션도 있다.
실제 동작 방식: 감지, 빌드, 실행, 라우팅
Openship가 저장소를 배포하는 과정은 문서상 다섯 단계로 설명된다. 먼저 package.json, 프레임워크 설정 파일, 락파일, docker-compose.yml 등을 읽어 어떤 스택인지, 어떤 패키지 매니저와 빌드·시작 명령을 써야 하는지 자동으로 판단한다. 이어서 대상 서버나 오케스트레이터에서 Docker 이미지나 경량 릴리스로 빌드한다. 이때 확정된 설정을 스냅샷으로 고정해두기 때문에, 나중에 재배포하거나 롤백해도 그 시점에 실제로 배포됐던 내용을 그대로 재현할 수 있다. 세 번째로 컨테이너나 감독되는 프로세스로 앱을 실행하는데, 컨테이너는 항상 루프백(내부용) 포트로만 열리고 외부에 직접 노출되지 않다. 마지막으로 OpenResty 기반 엣지가 도메인에 맞는 리버스 프록시 설정을 쓰고 Let's Encrypt 인증서를 발급한다. 라우팅과 인증서 처리가 앱이 이미 뜬 뒤에 이뤄지기 때문에, DNS나 인증서 문제가 생겨도 배포 자체가 실패하거나 기존 서비스가 내려가지 않는다는 점을 문서는 강조한다.
주의해서 봐야 할 지점: Docker 소켓 마운트
셀프 호스팅 스택을 Docker Compose로 직접 띄우는 경우, api 컨테이너가 호스트의 Docker 소켓을 마운트한다. 그래야 제어판이 사용자의 앱을 호스트 컨테이너로 빌드하고 실행할 수 있기 때문인데, 공식 문서는 이 구성이 "소켓을 통해 호스트 권한을 갖는다"는 점을 명시하며 신뢰할 수 있는 호스트에서만 실행하라고 직접 경고한다. 편의성과 보안 경계 사이의 트레이드오프를 프로젝트 스스로 투명하게 밝혀둔 셈이다. 자체 서버에 이런 도구를 올릴 계획이라면, 이 권한을 가진 컨테이너의 접근 대상을 제한해야 한다.
포함된 기능과 아직 없는 기능
README에 정리된 기능 목록에는 푸시 한 번으로 배포되는 CI/CD, Node·Python·Go·Rust·PHP·Ruby·Java·.NET 등 대부분의 스택 지원, Postgres·MySQL·MongoDB·Redis를 포함한 백엔드, 자동 Let's Encrypt와 무제한 도메인, HTTP/3와 Brotli 압축을 지원하는 CDN 엣지 캐싱, DKIM/SPF/DMARC를 갖춘 내장 SMTP 메일 서버, 예약 백업과 원클릭 복원이 들어 있다. AI 에이전트를 위한 MCP 엔드포인트도 제공되는데, 옵트인한 라우트만 MCP 도구로 노출되고 모든 호출이 매번 권한을 다시 확인하며, 자격 증명·토큰 관련 라우트는 애초에 MCP 도구가 될 수 없도록 막아 놓았다고 설명한다. 다만 README는 프로젝트 상태를 "프로덕션에 쓸 수 있는 핵심 기능은 갖췄지만 계속 개발 중"이라고 밝히면서, 멀티 노드 클러스터, 로드밸런싱 UI, 프라이빗 네트워킹, 시각적 CI/CD 파이프라인은 아직 나오지 않은 다음 계획으로 남겨 두었다. 자체 서버에 올릴 계획이라면 위에서 짚은 Docker 소켓 권한 구조부터 확인해 볼 필요가 있다.