Openshipとは：セルフホストできるOSSデプロイ基盤（PaaS）をコードと実機で検証【2026】

Openship（oblien/openship）は、VPSや自前サーバー、あるいはローカルにアプリを公開できるセルフホスト型のオープンソースなデプロイ基盤（PaaS）だ。自分のVPSにアプリを載せたいだけなのに、Nginxのリバースプロキシ、Let’s EncryptのSSL更新、systemdのサービス化、GitHub Actionsのデプロイパイプライン……と、周辺の配管作業だけで週末が溶けた経験はないだろうか。かといってVercelやRenderのようなマネージドPaaSに寄せると、今度は課金とベンダーロックイン、そして「データがどこにあるのか分からない」問題が付いてくる。Openshipは、その配管一式を自前のサーバーに丸ごと載せてしまうことで、この2つの不満をまとめて解こうとする。

Openship（oblien/openship）は、GitHubリポジトリを指すだけでスタックを自動検出してビルドし、ドメイン・SSL・データベース・バックアップ・メールサーバーまでを1か所で管理する。操作経路はWebダッシュボード・CLI・デスクトップアプリの3つに加え、REST APIとMCP（AIエージェント向けプロトコル）を備える。ライセンスはApache-2.0、GitHubスターは約2,971、最新版はv0.1.11（いずれも2026年7月時点）である。なお、同名でEC向けの『Openship』（注文ルーティング系）とは無関係の別プロジェクトなので、検索時は「Openship セルフホスト」で絞り込むとよい。

この記事ではセルフホスト型のデプロイ基盤（DevOpsツール）としてOpenshipを解説します。自動化ツール全般の俯瞰は AI自動化ツール｜ノーコードからコードまで2026年版の比較と選び方 をご覧ください。

Openshipとは：セルフホストできるOSSのデプロイ基盤（PaaS）

Openshipを一言でいえば、「自分のサーバーに置くVercel」だ。マネージドPaaSが提供する「gitにpushしたら勝手に公開される」体験を、他人のクラウドではなく自分が管理するマシンの上で再現する。公式の説明を借りれば、リポジトリを指すとOpenshipがスタックをDetect（検出）し、ビルドし、設定を整えて公開する——設定ファイルもパイプラインもYAMLも書かずに、というのがコンセプトである。

重要なのは、これが単なる「デプロイスクリプトの集合」ではなく、プロジェクト・デプロイ・ドメイン・環境変数・バックアップ・権限までを一元管理するコントロールプレーンを備えている点だ。デプロイして終わりではなく、公開後の運用（独自ドメインの付与、SSL証明書の自動更新、データベースのバックアップ、ロールバック）までを面倒見る設計になっている。

実測で確認したプロジェクトの規模

記事化にあたり、GitHub APIで2026年7月時点の実データを取得した。誇張されがちなREADMEの数字ではなく、APIが返す事実の方を基準にする。

・⭐ GitHubスター：約2,971
・🍴 フォーク：207
・👥 コントリビュータ：5人（うち1人が全コミットの大半を占める）
・🧾 コミット数：約156
・📦 リリース：7本（v0.1.6〜v0.1.11 が直近1か月に集中）／最新 v0.1.11（2026-07-18）
・🛠️ 主要言語：TypeScript（API層はHono、ダッシュボードはNext.js、デスクトップはElectron）
・📅 プロジェクト作成：2026年3月／直近pushは2026年7月と現役

数字が語るのは、「勢いはあるが、まだ非常に若いプロジェクト」という像だ。作成からわずか4か月あまりで約2,971スターを集め、直近1か月に6本のパッチリリースを出す開発速度は本物である。一方で、コミットの大半が単独メンテナ（Hydralerne）に集中しており、いわゆるバス係数（bus factor）は実質1に近い。これは「使えるか」を判断するうえで無視できないシグナルなので、後半の判定セクションで正直に扱う。

何ができるのか：主要機能を「読者の3つの問い」で整理する

当サイトの読者が知りたいのは、結局「①何ができて／②何を解決して／③何を代替できるのか」の3点に尽きる。Openshipの機能を、この軸で整理する。公式が挙げる主要機能と、コードで実在を確認できたものを対応させながら見ていく。

ビルトインCI/CD：GitHubリポジトリへのpushをトリガーにビルド・デプロイが走る。プレビュー環境、ステージング／本番のフロー、そしてロールバックが用意されている。デプロイ履歴から過去のバージョンへ戻せるのは、自ホスト運用で最も欲しい機能のひとつだ。

あらゆるスタックの自動検出：Next.js・Nuxt・SvelteKit・Remix・Django・Rails・Laravel・Phoenix・.NET など、フロント／バックを問わず主要フレームワークを検出してビルド設定を自動適用する。冒頭のウィザード画面がまさにこれで、フレームワークを選ぶとインストール／ビルド／起動コマンドが自動入力される。

フルバックエンド：PostgreSQL・MySQL・MongoDB・Redis といったデータベース、ワーカー、WebSocket、ストレージをプロビジョニングできる。アプリ本体だけでなく、それが依存するミドルウェアまで面倒を見る。

ドメインとSSL：Let’s Encryptによる証明書の自動発行・自動更新、ワイルドカード対応、独自ドメインの紐付けを行う。ここはコード（domain-ssl.ts / dns-resolver.ts / domain-token.ts）でも実装を確認できた。

自ホスト型メールサーバー：これがOpenshipの隠れた目玉だ。CLIの openship mail はiRedMailベースのメールサーバーをセットアップし、DKIM/SPF/DMARCの署名付きでメールを送れる。MailgunやSESに頼らず自前でトランザクションメールを送れるのは、この手のPaaSでは珍しい（後述するがコードでもDKIM/SPF/DMARCの実装を確認済み）。

バックアップ：データベースとボリュームをスケジュールバックアップし、ワンクリックで復元・エクスポートできる。CLIの openship backup からポリシー・実行・保存先を管理する。

リアルタイム監視とログ：どこまで見えるか

運用で地味に効くのが、ライブなログとメトリクスだ。ダッシュボードには「Monitoring」の項目があり、ビルドログをリアルタイムに流し、コンテナのメトリクスやリソース使用量を画面に表示する。CLI側でも openship logs <deploymentId> でデプロイのログをストリーム表示できるため、「デプロイが失敗した理由」をSSHでサーバーに入って journalctl を追う、といった手間が要らない。

ただし、ここでも誇張と現物の線引きは必要だ。README表の「Real-time monitoring」は基本的なライブログ／メトリクスの表示を指すが、公式Statusは「advanced monitoring（高度な監視）」を今後の予定として挙げている。アラートやSLO、詳細なダッシュボードといった本格的なオブザーバビリティを期待すると肩透かしを食うので、現状は「デプロイとコンテナの様子をその場で確認できる軽量な監視」と理解しておくのが正確だ。

なお、README上で押し出されている「CDN（HTTP/3・Brotli）」や「マルチノード」といった機能は、後述するようにコード上の裏付けが弱い、あるいはCloud連携やロードマップ段階だ。機能の「幅」に惹かれる前に、どこまでが現物かを見極める必要がある。

アーキテクチャと仕組み：3つの入口・1つのAPI・埋め込みPostgreSQL

Openshipが3つのUI（Web・CLI・デスクトップ）で常に同じ状態を見られるのは、アーキテクチャに理由がある。公式ドキュメントの「レストランの厨房」という比喩を借りると、注文を受けるカウンター（UI）は3つあるが、実際に料理する厨房（API）は1つだけ、という構造だ。

中核のAPIはHono（軽量で高速なWebフレームワーク）で書かれており、プロジェクト・デプロイ・ドメイン・環境変数・バックアップ・権限モデルのすべてを所有する。ダッシュボード・CLI・デスクトップアプリは、いずれも /api/* の下でこのAPIをHTTPで叩くだけの「フロント」に過ぎない。DBに直接書き込むのはAPIだけという制約があるため、どの入口から操作しても状態が食い違わない。この「単一の玄関（single front door）」設計が、3経路の一貫性を担保している。

データの置き場所も明快だ。デフォルト（DATABASE_URL 未設定）ではPGlite＝埋め込み型のPostgreSQLを使い、別プロセスのDBサーバーを立てずにディスク上のフォルダで完結する。デスクトップ版もこのモードで動く。DATABASE_URL を設定すれば通常のPostgreSQLサーバーに切り替わる。そしてセルフホスト時、ローカル／自前サーバーのプロジェクトとそのデプロイ・ドメイン・環境変数・ログは自分のインスタンスのDBだけに存在し、Cloudアカウントを一度も繋がなければ完全にスタンドアロンで動く。公式が「データ所有権（data ownership）」を独立した設計思想として掲げているのは、この点だ。

上図はデプロイの基本フローだ。ポイントは、成果物が標準のDockerコンテナである点で、公式も「プロバイダ間を自由に移動できる（Portability）」と謳っている。特定のベンダー独自形式に閉じ込められないのは、ロックイン回避として実務的な価値がある。

導入手順：CLI・Docker Compose・デスクトップの3つの入り方

導入は驚くほど短い。ここでは実際に手を動かす3パターンを、コピペで動く形で示す。なお本記事では検証のため、CLIを隔離環境に --ignore-scripts 付きでインストールし、openship --version・--help・doctor の実出力を取得した（下の画面はその実機出力である）。

① CLIで最小構成を動かす（Docker不要）。パッケージマネージャかインストールスクリプトでCLIを入れ、常駐サービスとして起動する。

npm i -g openship            # または: curl -fsSL https://get.openship.io | sh
openship up                  # 常駐サービスとして起動（再起動後も自動復帰）
openship open                # ダッシュボードをブラウザで開く

openship up はAPIを :4000、ダッシュボードを :3001 で起動し、バックグラウンドで動き続ける（一度だけ試すなら openship up --foreground）。停止は openship stop。

② プロジェクトをデプロイする。デプロイしたいリポジトリのディレクトリで初期化し、デプロイを叩くだけだ。

cd your-project
openship init                # このディレクトリをプロジェクトに紐付け
openship deploy              # デプロイを実行

③ Docker Composeスタックで本格運用する。既存のDocker環境に載せるなら、リポジトリをクローンしてComposeを立ち上げる。

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

デスクトップアプリが欲しい場合は openship install（または公式サイトからダウンロード）で入る。CLIは openship login でPersonal Access Token（opsh_pat_ で始まる文字列）を使って認証し、openship server で自前のSSHサーバーを登録すれば、そのサーバーへデプロイできる。

デプロイ先は local / 自前サーバー / Cloud の3択

Openshipのデプロイ先は3系統に分かれており、同じUIから選べる。冒頭のウィザードにあった「Build Location（Server / Local）」がまさにこの選択だ。localはOpenshipインスタンスとしているマシンやビルドをローカルPCで走らせて成果物をアップロードするモード、自前サーバー（server）はSSHで登録した任意のLinuxサーバー（Hetzner・DigitalOcean・Linode・OVH、あるいはベアメタルやホームラボ）へ配る、そしてOpenship Cloudはマネージドのホスティングに載せる、という住み分けである。

ドメインまわりも段階的だ。試すだけなら <app名>.opsh.io の無料サブドメインが即座に払い出され、SSL込みで公開できる。独自ドメインに切り替える場合は openship domain からDNS検証とLet’s Encryptの証明書発行を行う。「まず無料サブドメインで動かし、あとから独自ドメインへ」という段階的な移行がUI上で完結するため、初手の心理的ハードルは低い。ここで重要なのは、どのデプロイ先を選んでも成果物が標準Dockerコンテナである点で、あるサーバーから別のサーバー、あるいはCloudへと後から移す自由が残る。

AIエージェント連携（MCP）：Claudeからデプロイを動かすOpenshipのAI角度

Openshipがトピックに ai / agents を掲げる理由が、このMCP（Model Context Protocol）連携だ。とはいえ製品の中核はあくまでデプロイ基盤であり、MCPは「4つ目の操作経路」という位置づけである点は最初に断っておく。誇張せず、実装として何があるかを見る。

Openshipは自分のインスタンスの /api/mcp に、単一のMCPエンドポイントを持つ。ここはStreamable-HTTPのJSON-RPC 2.0で、Claude・Cursorなど任意のMCP対応クライアントが、Openshipの機能を「ツール」の集合として呼び出せる。各ツールは権限タグ付きのRESTルートに1対1で対応する。

設計として堅いのは、呼び出しごとに認証と権限チェックを毎回やり直す点だ。MCPのトークンは専用のものではなく、CLIと同じPAT、あるいはMCPクライアントがOAuth 2.1（PKCE）で取得したアクセストークンを使う。無効なトークンは 401 を返し、WWW-Authenticate ヘッダで認可サーバーを案内する。有効なトークンの権限は tools/list のフィルタにのみ使われ、実際の認可ゲートは各 tools/call が内部で本物のHono APIに投げ直したときに走る。つまりAIエージェントに渡す権限を、read専用やプロジェクト単位でスコープできる。AIに実インフラの操作を任せる際、これは現実的な安全弁になる。

接続そのものは拍子抜けするほど簡単で、MCPクライアント側に自分のインスタンスの https://<ホスト>/api/mcp を登録し、openship token create で発行したPATを渡すだけでよい。MCP専用の資格情報を別途作る必要はなく、エンドポイントはセルフホスト版・Openship Cloud版の双方で同じように利用できる。なお GET /api/mcp は 405 を返す設計で、サーバー側からのプッシュ（SSEストリーム）は行わない割り切った実装になっている。

MCP自体を体系的に理解したい場合は、当サイトのMCP関連記事も参照してほしい。ここではOpenshipが「AIからデプロイを安全に動かせる口」を持っている、という事実を押さえておけば十分だ。

既存のセルフホストPaaSとの比較（Coolify / Dokploy / CapRover / Vercel）

Openshipは無風の荒野に現れたわけではない。「自ホストのVercel」を目指すプロジェクトは既にいくつもある。代表的な選択肢と正直に並べてみる（各プロジェクトの公開情報にもとづく、2026年7月時点の整理。OpenshipについてのみGitHub API・コードで実測済み）。

読み取れる住み分けはこうだ。とにかく枯れていて情報が多いものが欲しいならCoolify、Docker Swarmで軽く回したいならDokployやCapRover、運用ゼロで最速に公開したい（かつロックインとデータ委託を許容できる）ならVercel/Netlifyになる。その中でOpenshipが独自なのは、デスクトップGUI・MCP・iRedMailメールサーバー内蔵という組み合わせだ。「ローカルのアプリのように扱えるデプロイ基盤」を志向している点で毛色が違う。

デプロイの「作り方」の思想そのものに関心があるなら、Infrastructure from Codeとは｜IaCとの違いと主要フレームワーク、AWS Blocksの登場 や、ローカルで動かしてクラウドへそのまま出す発想の AWS Blocks徹底解説｜ローカルで動かしAWSへそのままデプロイ、LocalStack系との違い も併せて読むと、この領域の見取り図がつかめる。

READMEとコードの照合：どこまでが「現物」か（誇張と実装）

ここが本記事のいちばんの価値だ。Openshipのような機能豊富なREADMEは、「書いてあること」と「動くこと」の距離を確かめないと評価を誤る。GitHub上のツリーとコードを実際に検索し、README上の主張を1つずつ照合した。

照合の方法はシンプルだ。まずGitHub APIでリポジトリの全ファイルツリー（blob 2,279件）を取得し、README上の機能名に対応するキーワード（cluster / multi-node / dkim / brotli など）でパス名を全文検索する。パス名でヒットしなかったものは、さらにGitHubのコード検索APIでファイル内容まで当たり、実装の有無とヒット件数を確認する。ファイルが存在するだけでは実装の証明にならない（たとえば email-templates.ts の存在はメール送信の証明にはなるが、DKIM署名の証明にはならない）ため、この2段構えで裏を取った。以下はその結果である。

⚠️ 誇張ぎみ・ロードマップ段階だったもの。まず、Features表に「Scaling：multi-node ready on self-hosted（自ホストでマルチノード対応）」とあるが、リポジトリ全体を検索しても cluster / multi-node / load-balanc / swarm に該当するコードは0件だった。しかもREADME自身の「Status」セクションは、multi-nodeクラスタとload-balancing UIを「Coming next（今後）」に列挙している。つまり同じREADMEの中で現在形の機能とロードマップが矛盾している。マルチノードは現時点で「ある」とは言えない。

次に「CDN：HTTP/3・Brotli・edge caching」。これも http3 / brotli / quic に一致する実コードは見つからず、存在したのは managed-edge-proxy.ts と cloud-edge-proxy.service.ts、そして nginx.ts アダプタだった。しかも managed-edge-proxy.ts は冒頭で「Openship Cloudにリンクしたメンバーがいないとエッジプロキシを同期できない」と明記しており、エッジ配信は実質的にマネージドのOpenship Cloud連携が前提だ。自ホスト単体で得られるのはnginxベースのリバースプロキシまでで、「HTTP/3対応のCDN」を額面どおり期待すべきではない。

そして「Production-ready core」という表現。中核が動くのは事実だが、版はv0.1.11でプロジェクトは作成4か月、ドキュメントも公式が「まだ作成中（work in progress）」と認めている。「本番投入できる中核」＝「成熟したプロダクト」ではないという距離感は持っておきたい。

✅ 逆に、コードで実在を確認できたもの。push-to-deploy／ロールバック／プレビュー、Docker Composeの解釈（compose-parser.ts）、ドメイン＋SSL自動（domain-ssl.ts ほか）、資格情報の暗号化（credential-encryption.ts）は、いずれもコードが存在する。とりわけメールサーバーは本物で、apps/email 配下に独立したメールエンジンを持ち、dkim / spf / dmarc に一致するコードがそれぞれ数十件ヒットする（fail2banのjail設定サンプルまである）。iRedMailベースの自ホストメールは、このカテゴリでは確かに差別化点だ。MCP連携も前セクションのとおり実装済みである。

結論として、Openshipは「READMEがやや盛り気味だが、中核は現物」というタイプだ。盛られている部分（マルチノード・CDN）を割り引いて、CI/CD・ドメイン/SSL・メール・MCPという実在する中核で評価すれば、十分に面白いプロジェクトである。

「使えるか」判定：ライセンス・依存・活性度・バス係数

最後に、導入を検討する人向けに「使えるか」を正直に採点する。良い面も懸念も両方書く。

ライセンス（◎）：Apache-2.0で、商用利用・改変・クローズドソースへの組み込みまで許諾される。LICENSE本文も正規のApache-2.0であることを確認済みで、「OSSを名乗りつつ再配布制限」型の罠はない。安心して自ホストできる。

依存・要件（○）：CLI最小構成ならNode環境で動き、埋め込みPGliteのおかげでDBサーバーの別立ても不要。本格運用ではDocker/Docker ComposeとPostgreSQLを使う。検証時の openship doctor は node 22.13.1・bun 1.3.11 を検出した。特殊な依存はなく、要件はモダンなVPSで十分満たせる。

活性度（◎）：直近1か月でv0.1.6〜v0.1.11の6リリース、pushは連日と、開発は明確に現役だ。約4か月で2,971スターという伸びも、需要の裏付けになる。

バス係数（△）：ここが最大の懸念だ。コントリビュータは5人だが、コミットの大半が単独メンテナ（Hydralerne）に集中しており、実質バス係数は1に近い。企業スポンサーが明示されているわけでもなく、開発の継続はこの1人に強く依存する。ただし有料のOpenship Cloudという収益源を持つため、「趣味の週末プロジェクト」よりは継続の動機がある構造ではある。

成熟度（△）：版はv0.1系、ドキュメントはWIP、マルチノード等はロードマップ段階。小〜中規模の自ホスト用途や検証環境には十分実用的だが、可用性が最重要のミッションクリティカルな本番投入は、v1.0到達やクラスタ機能の実装を見てからでも遅くない。

こんな用途に向く／向かない

判断を早めるために、向き不向きを言い切っておく。向くのは、個人開発やサイドプロジェクトを自分のVPSにまとめて置きたいケース、社内ツールや検証環境をクラウド課金なしで回したいケース、データを第三者クラウドに置けない事情があるケース、そして「デプロイもトランザクションメールも1つの基盤で完結させたい」ケースだ。特にメールサーバー内蔵は、MailgunやSESの契約を1つ減らせるという実利がある。AIエージェントにインフラ操作を安全に委譲したい実験用途にも、権限スコープ付きMCPは面白い土台になる。

逆に向かないのは、高可用性やマルチノード構成が最初から要件に入っている本番システム、厳格なSLAやコンプライアンス監査が求められる環境、そして「枯れた情報とコミュニティの答えがすぐ見つかること」を重視するチームだ。これらはCoolifyのような成熟プロジェクトか、素直にマネージドPaaSを選ぶ方が総コストは低い。v0.1系のプロジェクトに本番を預けるリスクを、自分たちが引き受けられるか——判断軸はここに尽きる。

総合すると、Openshipは「今すぐ全社の本番を預ける」プロダクトではないが、自分のVPSやサイドプロジェクトを賢く自ホストしたい人が、今から触って損はない有望株だ。特に「デプロイもメールもAIエージェント連携も1つに寄せたい」というニーズには、現時点で他に代えがたい組み合わせを提供している。まずはCLIかデスクトップで小さく試し、READMEの誇張部分を割り引いたうえで、中核機能の使い心地を自分の目で確かめるのがよいだろう。

参照ソース

・oblien/openship — GitHubリポジトリ（README・LICENSE・ソースコード）（2026年7月時点の実測に使用）
・Openship 公式ドキュメント（Architecture / CLI / MCP API / Data ownership）
・Openship 公式サイト
・GitHub API（stars・commits・releases・contributors の実測値取得）