KamuiDashを使う理由

KamuiDashは、GitHubと連携してWebサービスや静的サイトを東京リージョン、日本リージョンにデプロイできるPaaSです。1か月の無料トライアル期間中も、コールドスタートなしでサービスを動かせます。

アプリを作ったあと、次に必要になるのがホスティングです。
個人開発、新規サービス、BtoB向けシステムを問わず、アプリ以外のインフラ構築に必要以上の時間を使いたくない場面があります。公開と運用に必要な構成を整え、サービスそのものの改善に集中したいからです。

ホスティングに時間を使いたくない

クラウドは柔軟ですが、最初のサービスを公開するだけでも、ネットワーク、権限、実行環境、デプロイ方法などを決める必要があります。

PaaSは手軽に使えますが、リージョン、コールドスタート、料金などがサービスの要件に合わないこともあります。KamuiDashは、その間にある選択肢として設計しています。

ここで大切なのは、すべてのインフラ機能を最初から揃えることではありません。サービスを公開・運用するために必要な設定を、開発者が理解できる範囲にまとめることです。

KamuiDashとは

KamuiDashは、GitHubリポジトリを接続するだけで、アプリをデプロイしてホストできる開発者向けのPaaSです。個人開発や新規サービスから、継続運用するBtoB向けの業務システムまでを対象にしています。

GitHubからデプロイできる

リポジトリ、ブランチ、ビルドや起動コマンドを設定すれば、普段のGitワークフローから公開できます。

東京リージョンで動かせる

日本向けのサービスを、東京リージョンに配置する選択肢を持てます。

WebとDBを同じプロジェクトで管理できる

Webサーバー、静的サイト、Postgresデータベースをプロジェクト単位で扱えます。

トライアル中もコールドスタートなし

1か月の無料トライアル期間中も、アクセスが少ないサービスをコールドスタートなしで動かせます。

東京リージョンを選ぶ

KamuiDashの初版は、日本リージョンとして東京リージョンに対応しています。日本向けのサービスを公開するとき、実行場所を意識して選べることは、PaaSを比較する上でのひとつの判断材料になります。

リージョンは、単に画面上で選ぶ項目ではありません。アプリケーション、データベース、ユーザーとの距離、障害時の切り分けなど、サービスを運用するときの前提になります。東京リージョンで運用を始め、要件の変化に応じて構成を見直すという進め方ができます。

もちろん、リージョンだけでレイテンシーや可用性が決まるわけではありません。ただ、最初から日本向けの配置を選択肢にできることは、国内向けのプロダクトやBtoBシステムにとって分かりやすいメリットです。

コールドスタートなしで試す

コールドスタートとは、停止していたアプリケーションを最初のリクエストで起動するため、初回のレスポンスが遅くなる状態です。アクセスの波があるサービスや、利用頻度が読みにくい業務システムでは、最初のアクセスだけ待ち時間が発生することがあります。

新規サービスでもBtoB向けシステムでも、ユーザーやチームが開いた瞬間にサービスが応答することは重要です。KamuiDashでは、1か月の無料トライアル期間中もコールドスタートなしでサービスを動かせます。

トライアル期間や提供条件は変更される可能性があります。公開時点の料金ページで確認してください。

他サービスよりもKamuiDashを使う理由

サービスごとに得意な構成や運用の前提は異なります。ここでは、東京リージョン、コールドスタートなし、WebアプリとPostgresをまとめて管理できることを重視する場合に、KamuiDashを検討する理由を整理します。

日本向けのサービスを東京リージョンで動かしたい、公開後の最初のアクセスでも待ち時間を発生させたくない、WebアプリとPostgresをひとつのプロジェクトで扱いたい。こうした条件があるとき、KamuiDashは運用構成を必要以上に複雑にせず、公開を始めやすくします。

1か月の無料トライアル期間中もコールドスタートなしで動かせるため、本番サービスでも検証環境でも、アクセスされたときにすぐ応答できる状態を保てます。要件に対して必要な運用の大きさを見極めたいときに、KamuiDashを選択肢にできます。

GitHubからデプロイする

KamuiDashでは、最初にプロジェクトを作成し、その中でアプリやデータベースを管理します。アプリの設定では、GitHubリポジトリ、ブランチ、ルートディレクトリ、セットアップコマンド、起動コマンド、ヘルスチェック、環境変数などを指定できます。

すでにGitHubでコードを管理している場合、デプロイのために別のファイル形式へ変換する必要はありません。リポジトリのどのブランチを使うか、どのコマンドでビルドするか、どのコマンドで起動するかを設定します。アプリの構成を自分で把握したまま、公開までの手順を短くできます。

以下はGitHubへ変更をpushする一般的なコマンド例です。KamuiDashの実際のログではありません。

git-push.sh
git add .
git commit -m "Deploy to KamuiDash"
git push origin main
GitHubからデプロイまで
コントロールプレーン
GitHubコードを連携
コード連携
KamuiDash設定 / ビルド / デプロイ
デプロイ
データプレーン東京リージョン
Webアプリアプリを実行
Postgres
GitHubからコントロールプレーンへ連携し、データプレーン内の東京リージョンへデプロイする関係を示した概念図です。

Web、静的サイト、Postgresをまとめる

KamuiDashでは、Webサーバー、静的ファイルを配信するWebページ、Postgresデータベースを扱えます。ひとつのAPIだけを動かす場合も、フロントエンドとバックエンドを分ける場合も、プロジェクト単位で整理できます。

データベースでは、データベース名やデータの取り込み、データベースタイプを指定できます。アプリ側では環境変数を設定して接続情報を渡せるため、ローカル開発から公開環境へ移るときの設定も整理しやすくなります。

AI開発ツールから確認・公開する

KamuiDashは、GUIだけでなく、Kamui CLI(GitHub)やMCPを使った操作にも対応しています。最初のセットアップ後は、Claude Code、Codex、Cursorなどの開発環境から、デプロイ状況やアプリの状態を確認できます。

GitHubリポジトリとKamuiDashプロジェクトが接続済みなら、同じ開発環境から公開も依頼できます。設定画面を行き来するのではなく、今作っているリポジトリを指して伝えるだけです。

開発環境からの依頼
あなた:
「kamui platformプロジェクトに、
 このリポジトリを blog という名前の
 static appとしてデプロイして」

KamuiDash MCP:
✓ 公開しました

たとえば「直近のデプロイは成功しているか」「アプリが起動しているか」を確認し、そのまま公開を依頼する。AIにすべてを任せるためではなく、開発者が必要な情報へ早くアクセスし、開発の流れを止めずに公開まで進めるためのインターフェースです。

使いどころを考える

KamuiDashは、個人開発、新規サービス、社内ツール、BtoB向けの業務システムなど、GitHubを中心に開発・運用するケースに向いています。東京リージョンとコールドスタートなしを重視する場合は、検討しやすい選択肢です。

一方で、複雑なマルチリージョン構成、高度なネットワーク制御、大規模な専用インフラ設計が必要な場合は、他のクラウドサービスと比較した上で選ぶ必要があります。サービスの要件に対して、必要な運用の大きさを見極めることが重要です。

アプリをGitHubに置き、東京リージョンを選び、必要な設定を登録する。個人開発からBtoB向けシステムまで、開発と運用をつなぐ選択肢として、KamuiDashを検討できます。