Render

既定：自由に選べる・Webアプリどこで動かすか

乗り換える条件

• Fly.ioリージョンの指定やマシン単位の細かい制御が必要なとき
• Railway個人・検証用途

既定：PRプレビュー環境CI/CD・リポジトリ運用

乗り換える条件

• Neonのブランチ機能と組み合わせてDBも分離プレビューごとに本番相当のデータで確認したいとき

代替：デプロイRuby / Rails

既定は Kamal。サーバー管理をしたくないとき に乗り換える。

成長したら → AWS（ECS＋RDS＋Terraform）§24

きっかけ

閉域網・監査・細かい権限管理が必要になった

最初からの備え

Dockerfileでビルドし、設定はすべて環境変数から読む

ケース別の構成§19

• 業務システム・社内ツール（Rails構成）デプロイ：Kamal（オンプレVM・VPS）またはRender
• 業務システム・社内ツール（TypeScript構成）デプロイ：Render（AWSならECS on Fargate、オンプレならコンテナでVM）
• データ基盤・バッチ実行：RenderのCron Job（AWSならECSのスケジュールタスク）