個人開発をやってると、完成していくにつれて「これ、毎月いくらかかるんだ…？」ってなる人多いかなと思います。僕もありました。サーバー借りて、DB借りて、必要に応じてメール送るやつ使ったりして…ってやってると、まだ1円も稼いでないのに財布だけスッカスカになってたことありました。笑
自己紹介
現在、8年目になるエンジニア兼PMやってるやむぅ。です！普段はフリーランスエンジニアとして、8人の開発チームのPM（プロジェクトマネージャー）をしたり、AIゲームコーチングサービスなどの「個人サービス運営」「個人的なエンジニアサポート」この三つを主軸に活動しています。
- エンジニア歴: 8年目（上流の設計から下流の実装・テストまで全部経験あります）
- 得意な技術: Java, TypeScript, Next.js, Python, Go, Cursor, Claude code など
- 個人運営スクール: 個人開発や転職にコミットするプログラミングスクール「Programing Factory - ProFact」運営
- 個人開発したサービス運営
今回は、個人開発の運用コストを月0円ピッタリで回すための構成を、実際に僕が使っている組み合わせベースで書いていきます。「無料枠でどこまでいけるのか」「どこを超えると課金が始まるのか」とかも話していくので個人開発の構成どうしよって思ってる方はぜひ参考にしてください。
※この記事の無料枠の数値は 2026年6月30日時点 のものです。各サービスの無料枠はコロっと変わることあるので、本番投入の前は必ず公式で最新を確認してください。
結論：この4点セットで個人開発は月0円で回る
僕的によく使う構成として、Cloudflare（公開・ホスティング・バックエンド）＋ Supabase（DB・認証）＋ Resend（メール）＋ GitHub Actions（定期処理） の4点で、個人開発レベルなら月0円が成立します。
役割で分けるとこうです。
- Cloudflare：作ったWebアプリを公開する場所（フロント＋簡単なAPI）
- Supabase：データベース・ログイン認証・ファイル保管
- Resend：登録完了メールとか通知メールを送る
- GitHub Actions：毎朝バッチを回す、みたいな定期処理
全体構成とリクエストの流れ
ざっくり、こんな流れです。
ユーザー
│ ①画面を見る
▼
Cloudflare（Pages：フロント / Workers：軽いAPI）
│ ②データ取得・保存
▼
Supabase（PostgreSQL / Auth / Storage）
│ ③登録時などにメール送信
▼
Resend（メール配信）
（別ライン）
GitHub Actions（cron）── ④毎日決まった時間にバッチ実行 ──▶ Supabase など
何が嬉しいかというと、「常時起動しっぱなしのサーバー」を1台も持たない構成になってるところです。ここがコストの肝で、サーバーを24時間立てておくと大抵のクラウドサービスの無料枠は一瞬で溶けます（経験あり）。リクエストが来たときだけ動く・決まった時間だけ動く、にすると0円が現実的になります。
「0円でいけるなら0円を目指そう」という話
ここは技術とかじゃなくてマインドの話なんですけど。
「数百円くらい払えばいいじゃん」と思うかもですが、僕は個人開発こそ0円に寄せにいく価値があると思ってます。理由は3つあって、
- 金銭的にノーダメで継続できる：当たるか分からない個人開発で固定費が出てると、それだけで畳む理由になっちゃう。0円なら放置してても正直痛くならない
- 設計力が鍛えられる：無料枠に収めようとすると「常駐させない」「無駄に呼ばない」を自然に考える。ここは実務のコスト意識の練習にもなる
- モチベが保てる：「毎月引かれてる」ってだけで地味にしんどいけど、0円だと心理的にラクになる
もちろん「お金で殴ってラクしたほうが速い」場面もあるので、全部を0円に縛るのが正義とは言わないです。ただ個人開発の最初の一歩としては、0円縛りで設計力に全振りした方が後々いい経験になるので推奨です。
公開・デプロイ：Cloudflare
作ったアプリを公開する部分は Cloudflare Pages / Workers を使います。
Cloudflare無料プランの一番効くポイントは、WorkersとPages合わせて1日10万リクエストまで無料ってところです（Workers Pricing 公式）。個人開発のアクセス数なら、相当なことをしない限りまず初動でここは超えません。
- 静的アセット（HTML/CSS/JS/画像）の配信は無料・無制限
- 動的な処理（Workers / Pages Functions）を呼んだ分だけ、1日10万リクエストの枠を消費する
- 注意点：無料だと 1リクエストあたりのCPU時間（計算時間）に上限がある。重い処理をWorkers内でゴリゴリやると引っかかるので、重い計算は持ち込まない（Workers Limits 公式）
なので方針としては、**「画面の表示と軽いAPIはCloudflareに寄せる・重い処理はそもそも作らない」**でいくと無料枠の中で安定します。
データベース・認証・ストレージ：Supabase
DB・ログイン・ファイル保管はぜんぶ Supabase に集約できます。無料構成なのに1個で3役やってくれるのが超ありがたいです。
無料プランの主な枠はこんな感じ（Supabase Pricing 公式）。
- データベース：500MB（PostgreSQLそのもの）
- 無料プロジェクトは2つまで
- 認証（Auth）：月間アクティブユーザー5万人まで。メールログインもソーシャルログインもこの枠（メールでの新規登録が2件/hの制限あり）
- ストレージ：1GB（画像・PDFなどのファイル）
- 下り（egress）：5GB/月
ここで初心者がよく混ざるのが「DB容量」と「ストレージ容量」の違いです。
- DB（500MB）＝文字・数値などのデータ本体を入れる場所。ユーザー情報・投稿テキストとか
- Storage（1GB）＝ファイルを置く場所。アップロードされた画像や動画とか
画像をDBに突っ込むと(絶対そんな選択しないと思うけど)500MBが一瞬で死ぬので、ファイルはStorage・参照URLだけDB、が鉄則です。
「プロジェクト一時停止」がある
無料Supabaseの最大の壁がこれです。7日間まったくDBへのクエリが来ないと、プロジェクトが自動で一時停止（pause）されます（Supabase Pricing 公式 の Free 欄）。
止まると、ダッシュボードに自分でログインして手動で再開するまでアプリが完全に動かなくなります。まだ誰も使ってない状態で放置すると、久しぶりに開いた時データ取得でエラー起きてた、みたいなことが起こります。
回避策はいろいろありますが、一番目的として頑張るべきは「使ってくれる人が少なくとも一人以上」集めること。その次に「1日一回以上クエリ(データが取得されるとか)を走らすこと」です。
バックエンド：重い処理をどこで動かすか
「Cloudflare Workersだけで足りる？」というと、軽いAPIなら足ります。ただ、画像変換とか外部APIを束ねるとか、ちょっと重い・長い処理をやりたくなったとき用に、無料枠が太いサーバーレスを2つ挙げておきます。どっちも“使った分だけ・常駐しない”系なのでほぼ0円で使えます。
- Google Cloud Run：月 200万リクエスト、vCPU 180,000秒、メモリ 360,000 GiB秒まで無料。請求アカウント単位で集約されます（Cloud Run Pricing 公式）。Dockerコンテナをそのまま動かせるので自由度高め
- AWS Lambda（永久無料枠）：月 100万リクエスト＋400,000 GB秒まで無料。12ヶ月で消えるやつじゃなくてずっと無料の枠です（AWS Lambda Pricing 公式）
選び方の僕の感覚はこんな感じ。
- 画面表示＋軽いAPIだけ → Cloudflare Workersで完結
- コンテナごと動かしたい・重い処理あり → Cloud Run
- AWS寄りで組みたい・イベント駆動 → Lambda
最初はCloudflare Workersだけで始めて、「ここWorkersだとキツいわ」となってからCloud Run/Lambdaを足す、くらいで十分です。先回りして全部用意すると頭パンクします。
あとは、僕個人的にはAWS使うならAWS系で揃えたいのでLambdaは最終兵器として使います。
通知・メール：Resend
登録完了メール(これはSupabaseで可能)・通知メールとかを実装したいときは Resend で送れます。コードからメール送るやつの中だと、設定がシンプルで個人開発に向いてます。
無料プランの枠はこれ（Resend Pricing 公式）。
- 1日100通 かつ 月3,000通まで
- 独自ドメイン1つを検証して使える
- メールログの保持は30日
ここで「月3,000通より、1日100通の上限のほうが先に効く」ことです。普段は全然余裕でも、何かでメールが一気に飛ぶ日（一斉通知とか）に日次100通を超えて止まる、ってのが起きがちです。
あと独自ドメインの設定（SPF/DKIM）は最初にちゃんとやるを忘れないようにしましょう。これサボると、せっかく送ったメールが相手の迷惑メールに入って「届かない」が起きます。設定自体はResendの管理画面が案内してくれるので、そんなに難しくないはずです。
定期処理・バッチ：GitHub Actions
「毎朝9時にデータ集計」みたいな定期実行は、GitHub Actions の cron でやるのが無料で抑える&ラクです。専用のバッチサーバーとかを立てる必要がなくなります。
GitHub Actionsの無料枠はこう（GitHub Actions Billing 公式）。
- publicリポジトリ：実行時間は無料・無制限
- privateリポジトリ：月2,000分（Linux）まで無料
定期処理くらいの軽い実行なら、privateでも2,000分はまず使い切らないです。コードを公開していいやつならpublicに置けば時間を一切気にしなくてよくなります。
設定はこんな感じで .github/workflows/ にYAMLを置くだけ。
name: keepalive
on:
schedule:
# 毎日 00:00 UTC（日本時間 朝9時）に実行
- cron: "0 0 * * *"
workflow_dispatch: # 手動実行もできるようにしておくと便利
jobs:
ping:
runs-on: ubuntu-latest
steps:
- name: こんなことしたい
run: |
したいことのコマンド
cronを初めて使うにあたって注意するべき点があります。
-
時間はUTCです。日本時間で考えると9時間ずれるので「朝9時に動かしたい→
0 0 * * *（UTC 0時）」みたいに換算する - GitHub Actionsの
scheduleは実行が遅延したり、たまにスキップされることがある（混んでると後ろにずれる）。秒単位でキッチリ動かす用途には向いてないので、そこは割り切ること
無料枠、どこを超えると課金が始まるか
正直「結局どこを超えたら金取られるの？」なやつを一覧でまとめてみました。
- Cloudflare：動的処理（Functions/Workers）が1日10万リクエストを超えると有料プラン（Workers Paid）が必要。静的配信は超えても無料
- Supabase：DB 500MB / ストレージ 1GB / egress 5GB のどれかを超える、または3つ目のプロジェクトを作りたい、常時動かしたくなったらPro（有料）へ
- Resend：1日100通 or 月3,000通を超えたら有料
- GitHub Actions：publicは気にしなくてOK。privateで月2,000分を超えた分から課金
- Cloud Run / Lambda：それぞれ月200万 / 100万リクエストなどの無料枠を超えた分から従量課金
逆に言うと、このラインさえ越えない規模であれば請求は0円です。個人開発で趣味〜小さく公開、くらいの規模なら基本は全部この内側に収まります。
0円を維持するために「割り切ろう」
正直に書いておくと、0円構成にはちゃんとデメリットもあります。
- コールドスタート（最初の一発が遅い)：常駐サーバーがないぶん、しばらくアクセスがないと最初のリクエストが少しもたつくことがある
- Supabaseのpause：対策しないと止まる。完全に放置で安定運用、とはいかない
- 急にバズったら無料枠を超える：これは嬉しい反面爆弾なので、超えたら素直に課金しましょう。このフェーズまでにマネタイズできていないと詰むかもっす
つまり、「落ちてもまあいいか」が許される規模では最強・お金とデータの責任が重くなってきたら課金して堅くする、の線引きで使うのがいいと思います。
このスタックで実際に作れるもの
「で、これで何が作れるの？」というと、個人開発でやりたくなるやつはだいたいいけます。
- ログイン付きのWebサービス・ダッシュボード（Cloudflare＋Supabase Auth）
- 画像を投稿・一覧するサービス（Storageに画像・DBにメタ情報）
- 問い合わせフォーム付きのサイト（送信したらResendで自分に通知）
- 毎朝データを集めて通知するbot的なやつ（GitHub Actions cron）
※DBを必要とせず、ローカルストレージとかで完結できるのであればもっとサクッと作れる。
このように**「お金かけずにまず公開して、反応を見る」**ができるのが、個人開発で一番おいしいところだと僕は思います。作ったら作りっぱなしにせず、Xとかで「作ってみた」って出すところまでやると、もっと楽しくなります。
まとめ
- Cloudflare＋Supabase＋Resend＋GitHub Actions で個人開発は月0円で回せる
- Supabaseの7日pauseなど制限も多い
- 無料枠の**一線（10万req/日・500MB・100通/日・2000分）**を越えなければ請求は0円
- ただし本番のシビアな用途には向かない。趣味〜小さく公開の規模で使う
この生地を見ている人で、「個人開発したい」「作ってもリリースで悩んでる」という方いたらぜひ、この構成を試してみてください！コストをグッと抑えて最初の一歩を踏み出せればなと思います。