저장소만 연결하면 배포까지, 셀프 호스팅 플랫폼 Openship

저장소만 연결하면 배포까지, 셀프 호스팅 플랫폼 Openship

Openship IT & AI 뉴스 썸네일

웹 서비스를 직접 운영하려면 빌드 서버, 컨테이너, 도메인, 인증서, 로그를 따로 챙겨야 해요. Openship은 이 과정을 한 화면과 하나의 배포 흐름으로 묶은 오픈소스 플랫폼이에요. 저장소나 로컬 폴더를 연결하면 실행 환경을 감지하고, Docker 기반 배포와 라우팅까지 이어 줘요. 1

핵심 요약

구분	핵심	확인할 점
배포	저장소를 분석해 빌드·실행 명령과 포트를 찾고 배포해요	자동 감지가 틀리면 `openship.json`으로 설정을 덮어써야 해요
운영 방식	데스크톱 앱, 셀프 호스팅 서버, Openship Cloud 중에서 골라요	데스크톱 앱은 공개 웹훅을 받을 수 없어 push-to-deploy 용도와 맞지 않아요
네트워크	OpenResty가 도메인 라우팅과 Let's Encrypt 인증서를 맡아요	자체 서버의 80·443 포트와 DNS 구성을 미리 확인해야 해요
자동화	GitHub 웹훅, CLI, REST API, MCP 엔드포인트를 제공해요	API 권한과 외부 공개 범위를 먼저 제한하는 편이 안전해요
라이선스	Apache 2.0으로 공개됐어요	운영에 쓰기 전 릴리스 상태와 보안 공지를 함께 확인해야 해요

1. 배포에 필요한 조각을 한곳에 모은 Openship

설정 파일 없이 시작하되 필요하면 직접 고쳐요

Openship은 `package.json`, lockfile, 프레임워크 설정, Docker Compose 파일을 읽어 스택과 패키지 관리자, 빌드·시작 명령, 포트를 찾는다고 안내해요. 감지 결과는 배포 시점의 스냅샷으로 고정돼 재배포와 롤백에 쓰여요. 자동 설정이 프로젝트 구조와 맞지 않을 때는 `openship.json`으로 값을 지정할 수 있어요. 별도 설정이 전혀 필요 없다는 뜻보다는, 첫 배포에 필요한 입력을 줄이는 방식에 가까워요. 2

빌드가 끝나면 애플리케이션을 컨테이너나 관리되는 호스트 프로세스로 실행해요. 외부 트래픽은 OpenResty가 받아 내부 애플리케이션으로 넘겨요. 도메인이 연결되면 Let's Encrypt 인증서 발급도 처리해요. 프로젝트 문서에 따르면 DNS나 인증서 작업에 문제가 생겨도 실행 중인 앱을 바로 내리지 않고 별도 조치가 필요한 상태로 표시해요. 2

혼자 쓸 때와 팀이 쓸 때 구성이 달라요

데스크톱 앱은 로컬에서 control plane을 실행하고 SSH로 서버를 제어해요. 앱을 닫으면 로컬 control plane도 멈추며, 외부에 관리 화면을 공개하지 않아요. 개인 서버나 홈랩을 직접 다루면서 공개 관리 서버를 두고 싶지 않을 때 맞는 구성인데, GitHub 웹훅을 받을 공개 엔드포인트가 없어서 push-to-deploy에는 쓸 수 없어요.

728x90

팀 배포나 상시 자동 배포가 필요하면 `openship up`으로 셀프 호스팅 서버를 띄울 수 있어요. Linux와 Docker가 있으면 Postgres, Redis, API, 대시보드, OpenResty edge를 Compose 모드로 구성해요. macOS, Windows 또는 Docker가 없는 Linux에서는 임베디드 데이터베이스를 쓰는 bare 모드로 동작해요. 관리 부담을 피하고 싶다면 별도 관리형 서비스인 Openship Cloud도 선택할 수 있어요. 2

GitHub 푸시를 배포로 연결해요

추적 중인 브랜치에 코드가 올라오면 GitHub 웹훅이 배포 파이프라인을 다시 실행해요. 모노레포에서는 실제로 바뀐 서비스만 다시 빌드한다고 설명해요. 데스크톱 앱, 웹 대시보드, CLI는 같은 백엔드를 제어하며 REST API와 MCP 엔드포인트도 제공해요. MCP 도구로 노출되는 경로는 명시적으로 허용된 항목에 한정하고, 호출 때마다 권한을 다시 확인한다는 설명도 담겨 있어요. 2

편의성만큼 운영 권한도 살펴봐야 해요

셀프 호스팅 Compose 구성은 API 컨테이너에 호스트의 Docker 소켓을 연결해요. 이 권한이 있으면 호스트 컨테이너를 만들고 제어할 수 있으므로, 프로젝트 문서도 신뢰할 수 있는 서버에서만 실행하라고 안내해요. 관리 화면의 공개 범위, 관리자 계정, GitHub 웹훅 비밀값, 백업 저장 위치를 배포 전에 점검해야 해요.

기능 목록에는 데이터베이스, CDN, SMTP, 백업, 실시간 로그와 컨테이너 지표가 들어 있어요. 다중 노드 클러스터, 로드 밸런싱 화면, private networking, 비주얼 CI/CD 파이프라인은 향후 계획으로 구분돼요. 지금 필요한 기능과 로드맵 항목을 섞어 판단하지 않는 게 좋아요. 실제 서비스에 적용하기 전에는 작은 프로젝트로 빌드 감지, 롤백, 인증서 갱신, 장애 복구를 먼저 확인해 보는 편이 안전해요. 2

왜 중요한가요

셀프 호스팅 배포 도구는 서버 비용을 줄이는 것만으로 평가하기 어려워요. 개발팀이 직접 떠안는 인증서 갱신, 웹훅 보안, 데이터베이스 백업, Docker 권한 관리까지 합쳐야 실제 운영 비용이 보여요. Openship은 이 작업을 한 제품 안에서 다루면서도 표준 Docker 컨테이너를 사용해 특정 클라우드에 묶이지 않는 방향을 택했어요. 2

Vercel이나 Netlify처럼 빠른 배포 경험을 원하지만 실행 위치와 데이터를 직접 관리하려는 팀이라면 비교해 볼 만해요. 다만 저장소가 빠르게 바뀌고 있고 일부 기능은 계획 단계예요. 운영 환경에 바로 넣기보다 별도 VPS에서 한 서비스를 배포해 보고, 실패한 빌드의 복구와 백업 복원까지 시험한 뒤 범위를 넓히는 게 현실적이에요.

참고 자료

1. Openship - 내장 CI/CD를 갖춘 셀프 호스팅 배포 플랫폼 — GeekNews
2. oblien/openship: Self-hosted deployment platform — GitHub