為什麼使用 KamuiDash

KamuiDash 是可與 GitHub 連結、部署 Web 服務與靜態網站的 PaaS。即使在一個月的免費試用期間,也能在沒有冷啟動的情況下執行服務。

完成應用程式之後,接下來需要處理的就是託管。
不論是個人開發、新服務,或持續維運的 B2B 系統,都不希望在應用程式以外的基礎設施上花費過多時間。我們希望整理好公開與維運所需的配置,把心力放回服務本身的改善。

不想把時間花在託管上

雲端很有彈性,但即使只是公開第一個服務,也必須決定網路、權限、執行環境與部署方式等項目。

PaaS 很容易上手,但區域、冷啟動與費用等條件未必總能符合服務需求。KamuiDash 正是為了提供另一種平衡的選擇而設計。

重要的不是一開始就備齊所有基礎設施功能,而是將公開與維運服務所需的設定,整理在開發者可以理解與掌握的範圍內。

什麼是 KamuiDash

KamuiDash 是面向開發者的 PaaS,只要連結 GitHub 儲存庫,即可部署並託管應用程式。它適用於個人開發、新服務,以及持續維運的 B2B 業務系統。

可從 GitHub 部署

設定儲存庫、分支、建置與啟動指令後,就能依照平常的 Git 工作流程公開服務。

可選擇部署區域

若服務面向日本使用者,可選擇在東京區域執行應用程式。

在同一個專案中管理 Web 與資料庫

可依專案單位管理 Web 伺服器、靜態網站與 Postgres 資料庫。

試用期間也沒有冷啟動

在一個月的免費試用期間,即使服務存取量較少,也能避免冷啟動。

選擇適合服務的區域

KamuiDash 初版支援在東京區域執行。對於面向日本的服務,能夠在規劃時考量應用程式的執行位置,是比較 PaaS 時的一項判斷材料。

區域不只是畫面上的一個選項。它與應用程式、資料庫、使用者的距離,以及發生問題時的排查都有關係。可以先以符合服務需求的配置開始,並在需求變化時重新檢視架構。

當然,延遲與可用性不會只由區域決定。不過,能夠在服務設計中考慮部署位置,對需要明確掌握維運前提的團隊仍然有幫助。

無冷啟動地開始使用

冷啟動是指原本停止的應用程式必須在第一個請求到來時才啟動,因此第一次回應可能變慢。對於流量有波動的服務,或使用頻率難以預測的業務系統,使用者可能只會在第一次存取時遇到等待。

無論是新服務或 B2B 系統,使用者或團隊開啟服務時能立刻得到回應都很重要。KamuiDash 在一個月的免費試用期間也能讓服務保持無冷啟動執行。

試用期間與提供條件可能調整,請以公開時的價格頁面為準。

選擇 KamuiDash 的理由

每個服務擅長的架構與維運前提都不同。這裡整理了在重視無冷啟動、將 Web 應用程式與 Postgres 集中管理,以及依需求選擇部署區域時,考慮 KamuiDash 的理由。

希望公開後的第一次存取也不必等待、希望在同一個專案中處理 Web 應用程式與 Postgres、希望維持容易理解的維運結構;當這些條件很重要時,KamuiDash 能協助你不必把配置變得過於複雜,就開始公開服務。

一個月的免費試用期間也沒有冷啟動,因此無論是正式服務或驗證環境,都能維持被存取時立即回應的狀態。當你希望依需求判斷合適的維運規模時,KamuiDash 是可考慮的選項。

從 GitHub 部署

在 KamuiDash 中,先建立專案,並在其中管理應用程式與資料庫。應用程式設定可指定 GitHub 儲存庫、分支、根目錄、設定指令、啟動指令、健康檢查與環境變數等內容。

若程式碼已在 GitHub 管理,不需要為了部署而轉換為另一種檔案格式。只要設定要使用的分支、建置指令與啟動指令,即可在掌握自身應用程式架構的同時縮短公開步驟。

以下是將變更推送到 GitHub 的一般指令範例,並非 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 適合以 GitHub 為中心進行開發與維運的情境,包括個人開發、新服務、內部工具與 B2B 業務系統。若重視無冷啟動與清楚的部署流程,它是容易評估的選項。

另一方面,若需要複雜的多區域架構、高度進階的網路控制,或大規模的專用基礎設施設計,仍應與其他雲端服務比較後再選擇。重要的是依服務需求判斷合適的維運規模。

將應用程式放在 GitHub、選擇需要的部署設定並完成公開。從個人開發到 B2B 系統,KamuiDash 都是串連開發與維運時可考慮的選項。