OpenShipは、アプリを自前サーバーやクラウド上にデプロイするためのOSSです。リポジトリやローカルフォルダを指定すると、ビルド、起動、ルーティング、TLSまわりをまとめて扱う方向のツールです。
ただ、最初に引っかかるのは「自分のPCに入れるのか」「サーバーに入れるのか」です。ここを曖昧にしたまま試すと、使い方を間違えます。
この記事では、OpenShipそのものをいきなり本番サーバーへ入れません。まず、OpenShipでデプロイする対象として使える小さなNode.jsアプリを作り、ローカルとDockerで動くことを確認します。その上で、OpenShipをPCで使う場合とLinuxサーバーへ入れる場合の違いを整理します。
サンプル一式は、GitHubの openship-staging-health に置いています。記事では主要部分を抜粋し、手元で動かすファイルはリポジトリ側で確認できる形にしています。
OpenShipは何をするツールか
デプロイ基盤として見る
OpenShipは、VercelやNetlifyのようなデプロイ体験を、自分で管理するサーバー側に寄せたいときの選択肢です。
公式READMEでは、OpenShipを「open-source, self-hostable deployment platform with built-in CI/CD」と説明しています。
この記事で見る範囲では、次の仕事をまとめて扱うツールだと考えると分かりやすいです。
1. リポジトリやローカルフォルダを読む
2. アプリの種類や起動方法を判定する
3. ビルドして実行する
4. ドメインやTLSの入口を用意する
5. pushをきっかけに再デプロイするCI/CDの文脈では、ビルド、テスト、デプロイの手作業を減らすところが中心になります。OpenShipは、その中でもデプロイ先のサーバー、ドメイン、証明書、実行プロセスまでまとめて扱う方向のツールです。
別物のOpenShipと混ぜない
似た名前で、ECの注文ルーティング向けOpenShipも検索に出ます。この記事で扱うのは、oblien/openshipのセルフホスト型デプロイ基盤です。
PCに入れるものとサーバーに入れるものを分ける
PCは操作元として使う
OpenShipのREADMEでは、使い方が大きく分かれています。ひとりで試すならデスクトップアプリ、チームや常時稼働のデプロイ基盤にするならセルフホストサーバー、という分け方です。
WindowsやmacOS、Linuxデスクトップで使う場合は、デスクトップアプリからSSH先のサーバーやOpenShip Cloudを操作する形です。この場合、PC上のアプリ自体が公開Webアプリをホストするわけではありません。
tomoPCに入れるだけで検証環境が公開される、という理解だとずれます。PCは操作画面で、公開アプリを置く場所は別に考えます。
Linuxサーバーは公開口を持つ
Linuxサーバーに openship up を入れる場合は話が変わります。Dockerが使えるLinuxでは、Postgres、Redis、API、ダッシュボード、OpenRestyのedgeを含む構成になります。HTTP/HTTPSの入口として 80 と 443 を使うため、既存のnginxやApacheが動いているサーバーにそのまま入れるのは危険です。
検証用PCで軽くコマンドを試す感覚で openship up を実行すると、常駐サービス、Docker、公開ポート、証明書、Docker socket権限の話が一気に入ります。 最初は使い捨ての検証サーバーか、影響範囲を分けた環境で確認します。
最初にデプロイ対象の小さなアプリを作る
本物の業務アプリを最初に載せない
OpenShipを評価するとき、いきなり本物の業務アプリを載せると、どこで失敗しているのか分かりにくくなります。先に、環境変数、ヘルスチェック、ログだけを持つ小さなアプリを用意します。
今回作ったサンプルはNode.js 22以上を前提にしています。外部ライブラリは使わず、標準のhttpだけで動かします。
{
"name": "openship-staging-health",
"version": "0.1.0",
"private": true,
"scripts": {
"start": "node server.js"
},
"engines": {
"node": ">=22"
},
"dependencies": {}
}最初のデプロイ対象は、アプリの都合をできるだけ減らします。 DB接続や認証を入れる前に、OpenShip側のビルド、起動、ルーティングを見たいからです。
確認用の入口を3つに絞る
見るエンドポイントは3つだけです。
| path | 確認すること |
|---|---|
/ | アプリが起動し、環境名とリリース番号を返すか |
/health | デプロイ後の疎通確認に使えるJSONを返すか |
/config-check | 環境変数が入っているか。秘密値そのものは返さないか |
PORTは実行環境から渡される前提にしています。OpenShipのようなデプロイ基盤に載せるアプリでは、アプリ側で固定ポートを決め打ちするより、環境変数で待ち受ける方が扱いやすいです。
const http = require("node:http");
const port = Number(process.env.PORT || 3000);
const appEnv = process.env.APP_ENV || "local";
const releaseVersion = process.env.RELEASE_VERSION || "dev";
const featureFlagSample = process.env.FEATURE_FLAG_SAMPLE === "true";
const hasSecretCheckValue = Boolean(process.env.SECRET_CHECK_VALUE);秘密値は、値そのものを返しません。SECRET_CHECK_VALUEが設定されているかどうかだけをhasSecretCheckValueとして返します。検証環境でも、画面やログに秘密情報を出す癖を付けないためです。
ローカルとDockerで先に動作確認する
Node.jsだけで起動する
OpenShipへ渡す前に、アプリ単体で動くことを確認します。WindowsでもLinuxでも、Node.js 22以上が入っていれば同じ確認ができます。
npm install
$env:PORT="3310"
$env:APP_ENV="local-test"
$env:RELEASE_VERSION="manual-local"
$env:FEATURE_FLAG_SAMPLE="true"
$env:SECRET_CHECK_VALUE="local-secret"
npm startLinuxやmacOSなら、同じ内容を環境変数付きで実行します。
npm install
PORT=3310 APP_ENV=local-test RELEASE_VERSION=manual-local FEATURE_FLAG_SAMPLE=true SECRET_CHECK_VALUE=local-secret npm start別のターミナルから確認します。
curl http://127.0.0.1:3310/
curl http://127.0.0.1:3310/health
curl http://127.0.0.1:3310/config-check手元では、/、/health、/config-checkがすべてHTTP 200で返りました。最初は3000番で確認しようとしましたが、別のローカルアプリが使っていたため、3310番に変えて確認しています。こういうポート衝突は、デプロイ基盤の評価でもよく混ざるので、先に切り分けておきます。
ローカル確認で大事なのは、OpenShipを疑う前にアプリ単体の失敗を消すことです。ポート衝突、環境変数の不足、起動コマンドの誤りは、先にここで見つけます。
Dockerイメージとして起動する
Dockerでも確認します。
docker build -t openship-staging-health .
docker run --rm -p 3311:3000 --env-file .env.example openship-staging-health手元の確認では、Docker上でも3つのエンドポイントがHTTP 200で返りました。コンテナ内では3000番で待ち受け、ホスト側では3311番に割り当てています。
RootService: openship-staging-health
HealthStatus: ok
ConfigEnv: staging
ReleaseVersion: local
FeatureFlag: false
HasSecret: trueここまで通っていれば、少なくとも「アプリが起動しない」「環境変数を読めない」「Docker化できていない」という問題はOpenShipの前に潰せています。
OpenShip導入前に確認すること
入れ方を先に決める
OpenShip本体を試す前に、次を決めます。
1. デスクトップアプリでSSH先を操作するだけか
2. Linuxサーバーに常駐のOpenShipを入れるか
3. 80/443番ポートをOpenShipに渡せるか
4. Docker socketを扱ってよい検証サーバーか
5. GitHub連携やpush-to-deployまで試すか
6. 検証後に消す手順を用意しているかWindows PCで試すなら、最初はデスクトップアプリで十分です。Linuxサーバーでセルフホスト構成を試すなら、既存Webサーバーや別サービスが入っていない検証用ホストを用意します。
tomoまずは「PCに入れる」のか「サーバーに入れる」のかを分けます。ここを分けるだけで、試すコマンドをかなり絞れます。
バージョンと手順を固定して読む
OpenShipのCLIは、インストールやセルフホスト環境のセットアップも扱います。2026年8月1日時点では、GitHub Releasesの最新はv0.5.0です。リリース直後のOSSなので、記事を読んだ時点ではバージョンや手順が変わっている可能性があります。導入前にReleasesとREADMEを見直します。
この記事では、手元PCにOpenShipの常駐サービスを入れるところまでは実行していません。検証したのは、OpenShipへ載せる前提のNode.jsアプリをローカルとDockerで動かすところまでです。OpenShip本体は、ポート、Docker、証明書、常駐サービスの影響を分けられる環境で試します。
検証環境デプロイで見るポイント
デプロイ成功だけで終わらせない
OpenShipを評価するときは、デプロイが通ったかだけを見ない方がいいです。業務システムの検証環境として使うなら、最低限、次を確認します。
- pushしたリリース番号を画面やAPIで確認できるか
- 環境変数をstaging/prodで分けられるか
- ヘルスチェック用URLを運用監視に渡せるか
- ログでリクエストとステータスを追えるか
- 秘密情報を画面やログに出していないか
- ロールバックや再デプロイの手順を説明できるか今回のサンプルは、このうちリリース番号、環境変数、ヘルスチェック、ログ、秘密値の扱いだけを確認するためのものです。DB、メール、ストレージ、バックアップまでは入れていません。
失敗の切り分けを残す
最初の検証では、対象を小さくする方が判断しやすいです。小さなアプリでデプロイの流れを確認し、次にDB接続やバックグラウンドジョブを足す。その順番にしておくと、OpenShipの問題なのか、アプリ側の問題なのかを分けやすくなります。
デプロイ基盤の検証では、失敗した事実だけでなく、どこまで通っていたかを残します。 ローカル起動、Docker起動、OpenShipでのビルド、ルーティング、ヘルスチェックを分けて記録します。
次に試す環境を決める
OpenShipは、デプロイを楽にする可能性があるツールです。ただ、楽に見える部分ほど、サーバーの権限、公開ポート、証明書、Dockerの扱いを先に決めておく必要があります。
まずは今回のような小さなアプリを1つ用意して、PCではローカルとDockerで動くことを確認する。そのあと、捨てられる検証サーバーでOpenShip本体を試す。この順番なら、業務システムの検証環境に使えるかを落ち着いて判断できます。
tomo次に進むなら、使い捨てのLinux検証サーバーを用意して、OpenShip本体の導入、サンプルアプリのデプロイ、削除手順までを1セットで確認したほうがいいでしょう。
まとめ
OpenShipは公開先を決めてから試す方がよい
OpenShipは、アプリのビルド、起動、ルーティング、TLS、push-to-deployをまとめて扱うデプロイ基盤です。ただし、PCに入れる場合とLinuxサーバーに常駐させる場合では意味が違います。
PCのデスクトップアプリは操作元です。Linuxサーバーに入れるopenship upは、Docker、80/443番ポート、証明書、常駐サービスを扱います。最初に決めるべきことは、OpenShipをどこに入れるかではなく、どこを公開先として使うかです。
今回試したこと
この記事では、OpenShip本体をいきなりインストールせず、先にデプロイ対象の小さなNode.jsアプリを作りました。/health、/config-check、ログ、環境変数だけを持たせ、ローカル起動とDocker起動まで確認しています。
この順番にすると、OpenShipで詰まったときに「アプリが動かない」のか「デプロイ基盤側で詰まっている」のかを分けやすくなります。業務システムの検証環境で使うなら、この切り分けはかなり大事です。
次にやること
次にやるなら、既存Webサーバーが入っていないLinux検証サーバーを用意します。そこでOpenShip本体を入れ、今回のopenship-staging-healthをデプロイし、URL、TLS、ログ、再デプロイ、削除手順まで確認します。
本番サーバーや共用の検証サーバーで、いきなりOpenShip本体を試すのは避けます。 まずは捨てられる環境で、導入から削除までを1回通す。その結果を見て、業務システムの検証環境に使うかどうかを判断します。
