個人開発のデプロイ先比較：Cloudflare、Vercel、Railwayの選び方

デプロイ画面にはblog、tool-api、dashboard、worker-daily-reportの4サービスがあります。最初の2つはCloudflare、3つ目はVercelで動き、最後の一つはRailwayとWorkersのどちらに置くか決まっていません。詰まる場所も別々です。blogはbuild回数、tool-apiはWorkersのCPU、dashboardはVercelの請求、daily reportはコンテナと関数の実行時間が問題です。

個人開発でも、コンテンツサイト、ツール、SaaSの管理画面、定期処理が同時に存在します。比較すべきなのはブランドの勝敗ではなく、各サービスに合うruntimeと、料金・運用の閾値です。

1. 4つのサービスが別々の制限に当たる

blogはCloudflare Pages上のAstro静的サイトです。コンテンツ、style、設定の変更ごとにdeploymentが走るため、Freeの月500 buildsへ近づいています。20,000 filesには余裕がありますが、コメントと検索をPages Functionsで実装するとWorkersのquotaを使います。

tool-apiはloginとdata persistenceを扱う軽量APIです。trafficが増えるとFreeの100,000 requests/dayでは不足し、計算量の多いrequestは10 ms CPUを超える可能性があります。Workers Paidは月5ドルからで、requestとCPUの課金はstatic hostingと別です。

dashboardはVercel上のNext.js full-stack appです。Preview deploymentは便利ですが、usage pageではFunctions、Images、Builds、Analyticsなどが分かれています。追加のpaid seatは1人月20ドルです。HobbyにはActive CPU 4 hours、Provisioned Memory 360 GB-hrs、1 million invocationsが含まれます。

worker-daily-reportは日次reportを生成してemailで送ります。Workersでもschedule実行はできますが、長時間または計算量の多いjobはCPUとmemoryの境界に合いません。RailwayならNode processを動かせますが、RAM、CPU、egress、volumeの利用量を管理します。Hobbyは月5ドルで5ドル分の利用枠を含みます。

結論は、workloadの形に合わせて分けることです。static content、light function、full app、long-running jobを一社へ押し込む必要はありません。

2. 4プラットフォームの主要な制約

2.1 Cloudflare Pages：静的assetは無料、functionはWorkers枠

Cloudflare Pagesは静的asset hostingとglobal deliveryが中心です。Freeの現在の主な上限は次のとおりです。

• 月500 builds。Git pushと手動buildが枠を消費します。
• 1 siteあたり20,000 files。画像や自動生成pageが多い場合は総数を監視します。
• 1 assetは最大25 MiB。大きな動画やdata fileはobject storageへ置きます。
• Freeではprojectあたり100 custom domainsです。
• build timeoutは20分です。

Pages FunctionsのrequestとCPUは、Pagesのstatic枠ではなくWorkers planへ計上されます。

• static assetはPagesの上限内で配信されます。
• コメント、検索、API proxyなどのdynamic機能はWorkersのquotaとpricingを使います。
• AstroやHugoのstatic siteには適しています。Next.jsでは最新のadapterとruntime対応を確認します。

コンテンツサイトと静的ツールの出発点としてPagesは有力です。dynamic requestや重い処理が増える場合は、Workersのworkloadとして別に見積もります。

2.2 Cloudflare Workers：requestとCPUに境界がある軽量function

Workersはlight API、edge logic、ツールのbackend向けruntimeです。FreeとStandardの現在の境界は次のとおりです。

• Freeは100,000 requests/dayです。
• FreeのHTTP requestはCPU 10 msです。network I/Oの待ち時間自体はCPU時間に含まれません。
• Workers Paidのsubscriptionは月5ドルです。
• Standardは月10 million requestsを含みます。
• Standardは月30 million CPU millisecondsを含みます。
• FreeとPaidのmemoryはisolateあたり128 MBです。

適する用途は次のとおりです。

• authentication、lookup、単純なbusiness logicを行う軽量API。
• commentやsearchを実装するPages Functions。
• cache、routing、authorizationを加えるAPI proxy。

適さない用途は次のとおりです。

• report生成、batch処理などの長時間job。
• heavy computation、大量dataのmemory処理、ML inference。
• isolate runtimeに合わない従来型connection pool。

小さなツールのbackendには向きますが、成長後のrequest数とCPUを事前に見積もります。常駐processやresource-heavy jobは別のruntimeへ移します。

2.3 Vercel：Next.jsに強いが、請求はseatだけではない

VercelはNext.jsとの統合とPreview deploymentが強みです。Hobbyのfunction枠と他の課金項目は分けて確認します。

• Active CPU 4 hours。
• Provisioned Memory 360 GB-hrs。
• 1 million function invocations。
• on-demand concurrencyまたはElastic build machineを使う場合、build usageはCPU minuteあたり0.0035ドルです。
• 追加paid team seatは1人月20ドルです。
• deploymentはFreeが100/day、Proが6,000/dayです。
• uploadはFreeが5,000/day、Proが40,000/dayです。

請求項目は複数あります。

• Functions：CPU、memory、invocation。
• Images：transformation、cache read、cache write。
• Builds：課金対象のbuild設定で使うCPU。
• Analytics：Web AnalyticsとSpeed Insights。
• Observability：event課金のmonitoringと関連add-on。

警戒点は次のとおりです。

• Previewが多いとbuild usageとdeployment数が増え、課金対象machineやconcurrencyでは追加料金が発生します。
• Image Optimizationには独立したincluded usageとon-demand rateがあります。
• AnalyticsとObservabilityも別のusageまたはadd-onです。

Next.js full-stack productには有力ですが、plan価格だけでは総額になりません。usage categoryとteam seatを個別に監視します。

2.4 Railway：resource課金のcontainer runtime

Railwayはservice、worker、database向けPaaSです。edge functionより完全なruntimeを提供し、subscriptionとresource usageを分けて課金します。

• Hobbyは月5ドル、Proは月20ドルです。
• Hobbyは月5ドル分のresource usageを含みます。
• Proは月20ドル分のresource usageを含みます。
• RAMは1 GB-monthあたり10ドルです。
• CPUは1 vCPU-monthあたり20ドルです。
• network egressは1 GBあたり0.05ドルです。
• volume storageは1 GB-monthあたり0.15ドルです。
• Freeのdefault上限はserviceごとに0.5 GB RAM、1 vCPU、0.5 GB volumeです。

運用判断は残ります。

• RAM、CPU、egress、volumeの実使用量を監視します。
• resourceとlogのalertを設定します。
• rollbackとrebuildに関係するimage-retention windowを確認します。
• health check、restart、backupを定義します。

料金の警戒点は次のとおりです。

• included creditの5ドルまたは20ドルを超えた分が請求されます。
• serviceを停止しない限り、RAM、CPU、storageの消費が続きます。
• egressとpersistent volumeは別々に増えます。

RailwayはNode service、background job、databaseに向きます。infrastructure作業を減らせますが、service ownershipは残ります。

3. workloadからplatformを選ぶdecision table

3.1 コンテンツサイトとドキュメント

個人開発の最初のdeploymentはblogやdocumentationであることが多く、大部分がstatic assetです。

workload	最初の候補	主な閾値
Astro / Hugo static site	Cloudflare Pages	月500 builds、20,000 files
Next.js SSG	Cloudflare Pages / Vercel	adapter、build time、build設定
comment / search	Pages Functions	requestとCPUはWorkersに計上

AstroやHugoにはPagesが自然です。運用の詳細はCloudflare PagesデプロイガイドとCloudflare Freeの上限を参照してください。

Next.js SSGでは、古い対応可否の断定ではなく、最新のframework supportとbuild behaviorを確認します。主にstaticならCloudflareも候補になります。

commentやsearchはPages Functionsで実装できますが、requestとCPUはWorkersです。static deliveryとdynamic executionを分けて考えます。

3.2 静的ツールと動的ツール

generatorやconverterはbrowserだけで完結できますが、loginや保存が入るとdynamic productになります。

workload	最初の候補	主な閾値
browser内で完結するtool	Cloudflare Pages	build、file数
lightweight dynamic API	Cloudflare Workers	Freeの100,000 requests/day、CPU 10 ms
full-stack Next.js tool	Vercel	Functions、Images、Builds、observability

browser内の計算だけならPagesで十分です。小さなAPIは、requestが軽くisolate runtimeに合う限りWorkersへ置けます。

full-stack Next.js toolはVercelのworkflowと相性がよい一方、preview、image、function runtime、monitoringを別々に見積もります。

3.3 SaaSの管理画面

SaaS dashboardではapplication logic、authorization、data access、collaborationが必要です。

workload	最初の候補	主な閾値
full-stack Next.js	Vercel	Functions、Images、Builds、Analytics
別のframework	Workers / Vercel	最新のframeworkとruntime対応
team collaboration	Vercel / Railway	seat、permission、plan tier

Next.js dashboardならVercelが直接的です。Proを定額全部込みとみなさず、Function、Image、preview Build、Analytics、Observability、team seatを確認します。Cloudflare料金比較も参考になります。

別frameworkではadapterとruntime featureを比較します。Workersはedge寄りのlogic、Vercelは対応するserverless frameworkに向きます。

database hostingは別の判断です。Supabase、managed Postgres、D1、Railway volumeには独自の料金とreliabilityがあります。

3.4 長時間jobとcontainer service

report生成、file処理、queue consumer、persistent APIはshort functionと異なるruntimeを必要とします。

workload	最初の候補	主な閾値
Node service / worker	Railway	RAM、CPU、egress、volume
database	Railway / managed database	volume料金、backup方針
background job	Railway	usage alert、restart方針

完全なruntimeで常駐Node processを動かせるRailwayが候補です。その代わりlimit、log、health check、restart、backupを管理します。

Railway volumeでdataを永続化できますが、storage priceだけでdatabase構成は決まりません。backupとrestore testが必要です。

scheduled workにはusage alertとresource上限を設定します。Hobbyの5ドル枠は、常駐またはmemory-heavyなworkerで超える可能性があります。

4. 料金モデルと警戒ライン

4.1 Cloudflareの料金モデル

CloudflareではPagesのstatic deliveryとWorkersのdynamic executionを分けます。

Pagesのstatic asset：

• Pagesのproduct limits内では、static assetのtransferはusage課金されません。
• 月500 buildsへ近づいたら、不要なdeploymentを減らしbuild ignoreを検討します。
• 20,000 filesへ近づいたら、大きなassetをobject storageへ移します。
• Pages Functionsは別の無料dynamic枠ではなくWorkers quotaを使います。

Workersのexecution：

• Freeは100,000 requests/dayとHTTP requestあたりCPU 10 msです。
• Workers Paidは月5ドルのsubscriptionから始まります。
• Standardは月10 million requestsを含みます。
• Standardは月30 million CPU millisecondsを含みます。

cost threshold：

• hard limitへ達するとPagesのbuildを続けられない場合があります。
• Workers Freeは初期に有用ですが、requestまたはCPUが増えるとPaidが必要です。
• Pagesのstatic予算が無料でもPages Functionsが無制限になるわけではありません。

最初はPagesとWorkers Freeを組み合わせられます。trafficやCPUが増える前にPaidへ移る条件を決めておきます。

4.2 Vercelの料金モデル

Vercelはmanaged infrastructureとdeveloper experienceのresourceを複数に分けています。

Hobbyのfunction resource：

• Active CPU 4 hours。
• Provisioned Memory 360 GB-hrs。
• 1 million invocations。
• on-demand concurrencyまたはElastic build machineでは、build CPU minuteあたり0.0035ドルです。

usage category：

• Functions：Active CPU、Provisioned Memory、invocation。
• Images：transformation、cache read、cache write。
• Builds：課金対象machineやconcurrencyでのpreview / production build。
• Analytics：Web Analytics、Speed Insights。
• Observability：event課金とmonitoring。

team seat：

• 追加paid seatは1人月20ドルです。
• seat料金に他のinfrastructureやadd-on超過分は含まれません。

cost threshold：

• preview deploymentが多いとbuild usageとdeployment数が増えます。
• image処理には独立したincluded amountとon-demand rateがあります。
• AnalyticsとObservabilityを別に確認します。
• FunctionのCPU、memory、invocationをplan枠と照合します。

usage pageをcategory別に読むのが安全です。Next.jsの開発時間を減らせても、請求は複数行になります。

4.3 Railwayの料金モデル

Railwayはsubscriptionとmetered resource usageを組み合わせます。

planとincluded usage：

• Hobbyは月5ドルで5ドル分のresource usageを含みます。
• Proは月20ドルで20ドル分のresource usageを含みます。
• Freeはserviceあたり最大0.5 GB RAM、1 vCPU、0.5 GB volumeと小さな月次creditを提供します。

resource rate：

• RAMは1 GB-monthあたり10ドルです。
• CPUは1 vCPU-monthあたり20ドルです。
• network egressは1 GBあたり0.05ドルです。
• volume storageは1 GB-monthあたり0.15ドルです。
• 削除したdeployment imageはplanごとのretention window内だけ利用できます。

cost threshold：

• included creditを超えた利用分が差額として請求されます。
• serviceを止めなければRAM、CPU、storageを消費し続けます。
• egressとvolumeはsubscriptionとは別に増加します。

RailwayはVPSの初期設定を減らしますが、resource監視は残ります。persistent workerやdatabaseをproductionへ出す前にalertとrollback windowを確認します。

5. maintenance：deployment頻度、log、rollback、collaboration

変更頻度の高いprojectではbuildとdeploymentのquotaが効きます。collaborationではseatとpermissionも増えます。

deploymentとbuildの頻度

• Cloudflare Pages Freeは月500 builds、同時buildは1です。Git経由のpreview buildも枠を消費します。
• VercelはFreeで100 deployments/day、Proで6,000/dayです。previewが多いとbuild usageも増えます。
• Railwayは同じ形式のdeployment回数比較ではありませんが、削除imageはplanごとのrollback window内だけ保持されます。

Pagesのbuild数とVercelのdeployment数は、iterationを止める前に監視します。Vercelでは選択したbuild machineとconcurrencyが課金対象かも確認します。

log、rollback、team access

• Cloudflare Pagesにはbuild log、deployment history、rollbackがあります。collaboratorのaccountとpermissionは最新条件を確認します。
• Vercelにはpreview、deployment history、log、Analytics、paid seatがあります。追加paid seatは月20ドルです。
• Railwayにはlogとmetricsがあります。health check、restart rule、backup、workspace collaborationは明示的に設定します。

最も重要なserviceで繰り返し作業を減らせるworkflowを選びます。Next.js appではpreviewが、content siteでは予測可能なstatic buildが重視されます。

6. 次はdatabase、storage、CI/CD

deployment platformはstackの一層にすぎません。database、storage、CI/CD、monitoring、alertingは別に決めます。次の記事ではSupabase、Postgres、Railway volume、object storageを比較します。

目標はvendor数を最小にすることではありません。trafficが増える前に、各workloadのlimit、請求、運用責任を説明できるruntimeへ置くことです。