導入：PaaSは「高くなりすぎる」問題から目を背けない
「HerokuやRenderの請求額が、サービスの成長とともに無視できなくなってきた……」
「Kubernetesを導入するほど大規模ではないが、Dockerでモダンに運用したい」
Railsエンジニアであれば、
一度はこうした悩みに直面したことがあるのではないでしょうか。
PaaS（Render / Heroku / Fly.io など）は立ち上げが圧倒的に楽です。
しかしアプリが成長し、メモリやCPUを増やした途端、請求額が一気に跳ね上がります。
そこで近年注目を集めているのが、
37signals（Basecamp・HEY）が開発したデプロイツール「Kamal（カマル）」です。
Kamalは、
- Kubernetesほど重くない
- Capistranoよりモダン
- Docker前提で
- どこにでもデプロイできる
という、Rails時代の現実解とも言える存在です。
本記事では、
- Kamalとは何か
- RenderなどのPaaSと何が違うのか
- どんな人に向いているのか
- 実際の導入手順イメージ
を、エンジニア目線で徹底解説します。
Kamal（旧MRSK）とは何か？
Kamalは、Dockerコンテナ化されたアプリケーションを、
SSH接続できる任意のサーバーへデプロイするツールです。
位置づけとしては、
- Capistranoの思想
- Dockerの実行環境
- Kubernetesの一部（ローリングデプロイ）
を必要最小限だけ組み合わせたもの、と考えると分かりやすいでしょう。
Kamalの本質はこれ
「Dockerが動くサーバーなら、どこでも本番環境にできる」
- VPS（さくら / ConoHa / Hetzner）
- AWS EC2
- GCP Compute Engine
- オンプレミス
- 自宅サーバー
すべて同じ手順で扱えます。
クラウド事業者にロックインされず、
インフラの主導権をアプリ開発者が取り戻す──
それがKamalの思想です。
なぜ名前が変わったの？
もともとは MRSK（Moriarty） という名前でしたが、
- 発音しづらい
- 覚えづらい
という理由から Kamal に改名されました。
Kamalはアラビア語で「完全」「完成」を意味します。
Render（PaaS）とKamalの本質的な違い
結論から言えば、
- 手軽さを買うなら Render
- コスト効率と自由度を取るなら Kamal
です。
コスト・パフォーマンスの差は「成長するほど」開く
RenderのようなPaaSは、初期は非常に安価に見えます。
しかし、リソースを増やすたびに線形以上でコストが増大します。
例：
- Render：2GBメモリ → 約 $44 / 月
- 同等VPS：→ 約 $20 / 月（約55%削減）
4GB・8GBクラスになると差はさらに広がり、
70%以上のコスト削減になるケースも珍しくありません。
Kamalは単なるデプロイツールなので、
- サーバー代のみ
- PaaSマージンなし
- リソース完全専有
という構成になります。
パフォーマンスと制限の違い
Renderはマルチテナント環境です。
- 他ユーザーの負荷影響を受ける
- 同時接続数・プロセス数に制限がある
- プランに縛られる
一方Kamalでは、
- CPU・メモリを100%専有
- 人工的な制限なし
- OSレベルまで最適化可能
という違いがあります。
DX（開発体験）とCI/CDの考え方
Render：何もしなくていい代わりに、任せきり
Renderの最大の魅力は、
- GitHub連携
- push = deploy
- GUIで完結
- SSL・ドメイン自動
という圧倒的な手軽さです。
インフラを考えたくないなら、正直かなり快適です。
Kamal：多少の手間と引き換えに、完全な自由
Kamalは、
- サーバー準備
- SSH
- OSアップデート
- ファイアウォール
といった責任は利用者側にあります。
ただし、
kamal deploy一発- GitHub Actionsから実行可能
- Rails 8で公式デフォルト予定
- destination（環境複製）対応
など、CI/CDとの親和性は非常に高いです。
「自分たちのCI/CDに組み込みたい」チームには、
むしろKamalの方が自然にフィットします。
スケーラビリティと構成の考え方
自動スケールはPaaSの勝ち
- Render：自動スケール対応（プラン依存）
- Kamal：基本は手動スケール
突発的なトラフィック急増が頻発するなら、
- PaaS
- Kubernetes
の方が向いています。
中規模までならKamalが最適解
一方で、
- 常時安定トラフィック
- Rails中心
- Kubernetesは過剰
というケースでは、Kamalは最もシンプルで堅牢です。
データベースはどうする？
ここは重要ポイントです。
- KamalでもDBコンテナは立てられる
- しかし本番DBの同居は非推奨
多くのKamalユーザーは、
- DB：マネージド（RDS / Supabase / Render）
- App：Kamal + VPS
というハイブリッド構成を採用しています。
【実践】Kamalの基本設定（HCB対応）
Rails 7.1以降ではDocker関連ファイルが標準で含まれています。
インストール
gem install kamal初期化
kamal initdeploy.yml の例
service: my-app
image: user/my-app
servers:
web:
- 192.168.0.100
registry:
username: user
password:
- KAMAL_REGISTRY_PASSWORD
env:
secret:
- RAILS_MASTER_KEY
clear:
DB_HOST: 192.168.0.101セットアップ & デプロイ
kamal setup
kamal deployこれだけで、
- Dockerセットアップ
- ロードバランサ
- SSL（Let’s Encrypt）
- ゼロダウンタイムデプロイ
まで自動で完了します。
Kamalに向いている人・向いていない人
✅ 向いている人
- インフラコストを下げたい
- Linux / Dockerに抵抗がない
- ベンダーロックインを避けたい
- サーバーを「理解して使いたい」
❌ 向いていない人
- インフラを一切触りたくない
- 運用責任を負いたくない
- お金で手間を解決したい
まとめ：Railsエンジニアよ、主導権を取り戻せ
Kamalは、
- PaaSの便利さ
- 自前運用の自由度
- 現実的な運用コスト
を絶妙にバランスさせたツールです。
37signalsがRenderからKamalへ移行した理由も、
「クラウド費用が無視できなくなった」からでした。
Railsエンジニアが、
再びインフラの選択権を持つ時代が来ています。
次のプロジェクトでは、
ぜひKamalで Deploy Anywhere を体験してみてください。
参考リンク
- Kamal公式：https://kamal-deploy.org/
- GitHub：https://github.com/basecamp/kamal
