GITHUB / NODE.JS

GitHubにpushしたら自動公開するには？

Node.jsアプリを公開し、次のpushで更新する

·読了 約10分

手元のNode.jsアプリを直すたびに、サーバーへファイルをコピーして再起動する。その手間を減らす方法の一つが、GitHubへのpushをきっかけにした自動デプロイです。

ただし、git pushしただけで、どのサーバーでも自動公開されるわけではありません。リポジトリ、ブランチ、実行するディレクトリ、起動コマンドを、公開先と対応させる設定が必要です。

この記事では、依存パッケージのない小さなNode.jsアプリをKamuiDashへ接続する例で、その流れを説明します。DBや独自ドメインは使わず、発行されたURLで応答と更新を確認するところまでに絞ります。

この記事の内容

pushから公開までに、何が起きる？

pushから公開へ · 概念図
GitHubの対象ブランチにpush
公開先でセットアップと起動
HTTPS URLで動作を確認

KamuiDashへリポジトリとブランチを登録すると、そのブランチへのpushを受けてビルド・デプロイが進みます。セットアップと起動のコマンドは、アプリに合わせて設定します。自分でGitHub Actionsの設定を用意しない構成でも、リポジトリへのアクセス権と公開先の設定は必要です。

最初に小さいアプリを使うと、GitHubの接続と実行設定を、DBなどの問題から分けて確認できます。

公開用の最小アプリを作る

サンプル一式をダウンロードできます。フォルダーの中身を、リポジトリのルートへ置く想定です。

package.jsonにstartを用意する

Text
{
  "name": "small-node-deploy-example",
  "version": "1.0.0",
  "private": true,
  "type": "module",
  "scripts": { "start": "node server.js" },
  "engines": { "node": ">=22" }
}

npm run startで本番用プロセスを起動できるようにしています。今回の例にTypeScriptの変換やフロントエンドのビルドはありません。

プラットフォームのPORTで待ち受ける

Text
import http from 'node:http';

const port = Number(process.env.PORT || 3000);
const server = http.createServer((req, res) => {
  const path = new URL(req.url, 'http://localhost').pathname;
  if (req.method !== 'GET') {
    res.writeHead(405, { 'content-type': 'application/json', allow: 'GET' });
    res.end(JSON.stringify({ error: 'Method not allowed' }));
    return;
  }
  res.setHeader('content-type', 'application/json; charset=utf-8');
  if (path === '/healthz') res.end(JSON.stringify({ ok: true }));
  else if (path === '/') res.end(JSON.stringify({ message: 'Hello from Node.js', version: 'v1' }));
  else { res.statusCode = 404; res.end(JSON.stringify({ error: 'Not found' })); }
});
server.listen(port, '0.0.0.0', () => console.log(`Listening on ${port}`));
process.on('SIGTERM', () => {
  server.close(() => process.exit(0));
  setTimeout(() => process.exit(1), 10000).unref();
});

/は表示用のメッセージと版を、/healthzは稼働確認用のJSONを返します。PORTは公開先で渡される値を利用し、0.0.0.0で待ち受けます。終了通知のSIGTERMを受けたときは、新しいリクエストの受付を終えてプロセスを終了します。

このサンプルはデータを保存しません。メモリ上に配列を作っても、再起動をまたいだ永続保存にはならない点は分けて考えてください。

ローカルで起動する

Node.js 22以上とnpmを用意します。

Terminal
npm ci
PORT=3000 npm run start

別のターミナルから確認します。

Terminal
curl --fail http://127.0.0.1:3000/
curl --fail http://127.0.0.1:3000/healthz

それぞれHTTP 200とJSONが返る想定です。/のversionはv1です。サンプルには外部パッケージがありませんが、依存関係を増やした後もnpm ciで確認できるよう、package-lock.jsonもGitへ保存します。

GitHubへ保存する前に、公開する中身を確認する

新しい空リポジトリをGitHubで作り、サンプルのディレクトリから次のように保存します。画面での作成方法はGitHub公式のローカルコード追加ガイドが確認先です。以下は手元のコードを最初にpushする例なので、作成時にはREADMEなどでリポジトリを初期化せず空の状態にします。すでにGit管理しているディレクトリでは、初期化からやり直さず現在の状態を確認してください。

Terminal
git init
git branch -M main
git add package.json package-lock.json server.js .gitignore
git commit -m "Add small HTTP app"
git remote add origin https://github.com/YOUR_ACCOUNT/YOUR_REPOSITORY.git
git push -u origin main

URLのYOUR_ACCOUNT/YOUR_REPOSITORYは自分が作ったリポジトリに置き換えます。GitHubへの認証も必要です。.env、APIキー、DBのパスワードをソースへ入れないよう、保存するファイルを確認します。

KamuiDashでGitHub連携と実行設定を揃える

KamuiDashのプロジェクトからWebサーバーを作成し、Node.jsを選びます。対象のリポジトリが表示されない場合は、GitHub Appの接続先アカウントと、許可したリポジトリを確認します。GitHubにログインできることと、KamuiDashのGitHub Appがそのリポジトリへアクセスできることは別です。インストール時の権限とリポジトリ選択は、GitHub公式のGitHub App導入ガイドで確認できます。

KAMUIDASH · SCREENSHOT
KamuiDashのアプリ作成画面。ランタイム言語とGitHubリポジトリを選択する項目。
アプリ作成画面のランタイムとGitHub選択。nodeを選び、公開したいリポジトリ・ブランチを指定します。既存の公開記事で使用している実画面です。
項目 このサンプルの設定
種類・ランタイム Webサーバー／Node.js
リポジトリ サンプルを保存したリポジトリ
ブランチ main
ルートディレクトリ 空欄（package.jsonが直下にあるため）
セットアップコマンド npm ci
起動前コマンド 空欄
起動コマンド npm run start
ヘルスチェック /healthz

Node.jsの公式設定例では、依存関係の準備、起動前処理、アプリ起動を分けています。ビルドが必要なアプリではセットアップにその処理を加えます。

サブフォルダーに入っている場合

たとえばapps/api/package.jsonという構成なら、ルートディレクトリをapps/apiにします。起動コマンドも、そのディレクトリから見たserver.jsを起動する設定に揃えます。

コマンドの実行場所 · 概念図
リポジトリ直下なら空欄
サブフォルダーなら apps/api
package.jsonの場所に合わせる

npmがpackage.jsonを見つけられないときは、依存関係を追加する前に、コマンドをどこから実行しているかを確認します。

初回公開では、URLの応答まで確認する

作成後はデプロイが完了するのを待ち、発行されたHTTPS URLの/と/healthzを開きます。versionがv1であることも確認します。

KAMUIDASH · SCREENSHOT
KamuiDashの静的サイトのアプリ詳細。稼働状態、公開URL、GitHubブランチ、コミットごとのデプロイ履歴。
アプリ詳細画面に公開URLとデプロイ履歴が表示されます。画像は既存の静的サイトの例です。今回のNode.jsサンプルでは、公開URLからJSONの内容も照合します。

ヘルスチェックが200でも、利用者向けの経路がすべて正常とは限りません。実際に使う画面やAPIも確認します。

v1からv2へ変えて、自動更新を確かめる

server.jsのversion: 'v1'をversion: 'v2'へ変更し、保存します。

Terminal
git add server.js
git commit -m "Change response version to v2"
git push origin main

GitHubへ送信できたら、KamuiDashのデプロイ履歴で対象のコミットを確認します。完了後に公開URLを再取得し、JSONの版がv2に変わったことを確認します。pushの成功とデプロイの成功は、別の結果として見ます。

起きたこと 先に調べる場所
GitHubに変更が見えない push先のリポジトリとブランチ、ローカルのコミット
GitHubは更新されたがデプロイが始まらない KamuiDashの接続先ブランチとGitHub Appの権限
ビルドが失敗した セットアップのログ、ロックファイル、実行ディレクトリ
起動後にエラーになる 起動ログ、PORT、待ち受け先、依存環境
履歴は成功だが表示が古い 成功したコミット、アクセスしているURL、キャッシュ

エラーの調査では、失敗した工程と最初の具体的なエラーを見ます。設定をまとめて変えるより、一つずつ確認すると原因を追いやすくなります。

よくある疑問

GitHub Actionsは必要ですか？

KamuiDashのGitHub連携によるビルド・デプロイだけなら、専用のActionsワークフローを自分で作る必要はありません。ただし、自動テストを通してから本番へ反映する運用は別に設計します。

mainへpushすると、すぐ利用者へ公開されますか？

接続したブランチへのpushでデプロイが始まりますが、準備・ビルド・起動には時間がかかり、失敗することもあります。共有する前に公開先の結果を確認してください。チームでは、レビュー済みの変更だけを公開ブランチへ入れる運用も必要です。

DB付きにもできますか？

できます。DBへの接続設定とマイグレーション、保存・読み取りの確認が増えます。FastAPIとPostgreSQLの公開手順では、アプリとデータを分けて確認する流れを説明しています。

いくらから試せますか？

KamuiDashの対象アプリ・DBには基本料金が30日間無料のトライアルがあります。継続利用のWebサーバーは個人プランのNanoで1レプリカ・30日あたり税抜$3からです。従量料金やオプションの扱いは費用の記事で確認できます。

最初の公開と、その後の更新を1回ずつ確かめると、GitHubのどの変更が、どのURLに反映されるかがつながります。その流れを残してから、DBやフロントエンドのビルドを追加すると進めやすくなります。

検証範囲：添付Node.jsサンプルの起動とHTTP応答はローカルで確認しています。今回、GitHubへのpushとKamuiDashへの新規デプロイは実施していません。設定確認日：2026年11月2日。

KamuiDashは、GitHubやAI連携からWebアプリを公開できる東京リージョンのPaaSです。