月0円で自分のサイトを持つ公開までの全手順

本記事は2026年7月26日に各サービスの公式資料を再確認し、当サイトでの実運用をもとに増補しています。

「自分のサイトを持つ=レンタルサーバーを月額で借りる」という方法だけが選択肢ではありません。この記事では、当サイト(テック羅針盤)自身も採用している「静的サイトをサーバー代0円で配信する構成」と、公開後の更新までを実録ベースで解説します。

月0円になるのは、Astroで作った静的ファイルをGitHub経由でCloudflare Pagesへ送り、無料の pages.dev アドレスで公開する範囲です。独自ドメインを使う場合は取得・更新費用が別にかかり、価格は末尾の種類や購入時期、為替などで変わります。パソコン、通信環境、作業時間も「月0円」には含めていません。

この記事のゴールは、次の四つを自分で確認できる状態です。

パソコン上でAstroの初期画面が開く。
npm run build がエラーなく終わり、dist フォルダができる。
GitHubへ原本を保存できる。
Cloudflare Pagesの プロジェクト名.pages.dev で同じ画面が開く。

独自ドメインは任意です。まず無料アドレスまで公開し、仕組みが動くことを確かめてから追加しても構いません。

まず確認: 月0円になる範囲と、ならない範囲

この構成では、静的アセット(=あらかじめ作ったHTML、CSS、画像など)の配信にCloudflare Pagesを使います。Cloudflareの公式料金説明では、Functionsを呼び出さない静的アセットへのリクエストは、無料・有料プランとも無料かつ無制限です。一方、Pages Functionsという動的処理を使うリクエストはWorkersプランの利用枠に数えられます。つまり「静的サイトの配信」と「サーバー側で動く機能」は、費用の境界が違います。(Pages Functionsの料金)

項目	この手順での扱い	費用を考え直す場面
Astro	静的HTMLを作る道具として利用	有料テーマや外部サービスを追加するとき
GitHub	GitHub Freeのリポジトリを利用	非公開リポジトリ向けの高度な機能が必要なとき
Cloudflare Pages	静的ファイルを配信	Functionsや別の有料製品を使うとき
公開アドレス	`pages.dev` を利用	独自ドメインを取得・更新するとき
パソコンと通信	手元にある環境を利用	新しい機器や回線を用意するとき

Cloudflare Registrarは、ドメインの登録・更新に上乗せ手数料を加えず、レジストリとICANNから請求される額を請求すると説明しています。ただし、すべてのドメインが同じ固定価格になるという意味ではありません。購入画面に表示される初年度と更新時の金額を見て判断します。(Cloudflare Registrarの概要)

月0円を優先するなら、独自ドメインを買わずに pages.dev で運用を始められます。サイト名や発信テーマが固まってから独自ドメインへ移す方法もあります。ただし公開後にアドレスを変えると、既存ページからの転送、検索サービスの設定、名刺やSNSに載せたURLの更新が増えます。長く使う名前がすでに決まっている場合は、その手間とドメイン費用を比べます。

全体の仕組み: 3つの無料サービスをつなぐ

構成はシンプルで、役割の違う三つを直列につなぎます。

Astro(静的サイトジェネレーター) — 記事のMarkdownファイルを、配信用のHTMLへ変換する道具です。サイトの見た目と構造はここで作ります。
GitHub(ソース置き場) — サイトの元データと変更履歴を置く場所です。GitHub Freeでは、機能に一部差がある非公開リポジトリも利用できます。(GitHubのリポジトリ解説)
Cloudflare Pages(配信) — GitHubから元データを受け取り、Astroをビルドして、出来上がったHTMLを公開します。

流れを一行にすると、次のようになります。

Markdownを書く → AstroがHTMLを作る → GitHubへ送る → Cloudflare Pagesが公開する

この構成の肝は「静的サイト」であることです。WordPressのようにアクセスのたびにデータベースから本文を取り出す構成とは違い、あらかじめ作っておいたHTMLを配ります。自分でアプリケーションサーバーやデータベースを常時運転する必要がなく、管理する部品を減らせます。

ただし、静的であることは安全の保証ではありません。GitHubとCloudflareのアカウント、公開前の原稿、npmの依存パッケージ、独自ドメインを使う場合のDNSは残ります。管理画面やデータベースを持たない構成にできる分、確認対象を絞りやすいと考えるのが正確です。

方式	記事の保存場所	公開時の処理	向きやすい用途	主に管理するもの
Astroの静的サイト	Markdownやコード	更新時にまとめてHTMLを生成	ブログ、案内サイト、作品集	Git、依存関係、ビルド
一般的なCMS	データベース	閲覧時に本文を組み立てることがある	管理画面から頻繁に編集するサイト	CMS、DB、更新、バックアップ
Webアプリ	DBや外部API	利用者の操作に応じて処理	会員、予約、投稿、個別表示	認証、DB、API、監視

準備: アカウント、Node.js、ターミナルをそろえる

必要なのは、GitHubアカウント、Cloudflareアカウント、Node.jsとGitを使えるパソコンです。ターミナル(=文字で命令を入力する画面)は、WindowsならPowerShellやWindows Terminal、macOSならターミナルを使えます。

Astroの公式資料が示す現在の前提はNode.js v22.12.0 以上で、v23 のような奇数版はサポート対象外です。(Astroのインストール手順) Node.jsの公式ダウンロードページにはLTS(=長期サポート版)とCurrentが分かれて表示されます。初めて環境を作るならLTSを選ぶと、短期間でサポート終了になる版を避けやすくなります。(Node.jsのダウンロード)

まず、ターミナルで次を実行します。

node -v
npm -v
git --version

三つともバージョン番号が表示されれば、次へ進めます。node や npm が「認識されていません」「command not found」と表示される場合はNode.jsが未導入か、インストール後のターミナル再起動が済んでいない可能性があります。npm公式は、Node.jsとnpmの有無を node -v と npm -v で確認する方法と、複数のNode.js版を切り替えられるバージョン管理ツールの利用を案内しています。(Node.jsとnpmの導入)

作業前に、次の名前も決めます。

プロジェクト名: この記事では my-site とします。半角英数字とハイフンにすると各サービスで扱いやすくなります。
GitHubリポジトリ名: プロジェクト名と同じ my-site にすると対応関係を追いやすくなります。
公開用ブランチ: この記事では main とします。ブランチは変更の流れを分ける単位です。

アカウント作成時は、GitHubとCloudflareで多要素認証を設定しておくと、パスワードだけが漏れた場合の防壁を増やせます。また、サイトの本文にAPIキーやパスワードを入れないでください。静的サイトのファイルは、公開後に閲覧者へ配られる前提で扱います。

手順1: Astroでサイトの骨組みを作る

作業用フォルダを開いたターミナルで、次のコマンドを実行します。

npm create astro@latest my-site

Astroの作成ウィザードが始まり、テンプレート、依存パッケージのインストール、Gitの初期化などを聞かれます。質問文は版によって変わるため、この記事では選択肢の文字を固定しません。初めてなら、内容が少ない基本テンプレートを選び、依存パッケージはインストールします。Gitの初期化はここで行っても、次の手順で行っても構いません。

作成後、プロジェクトへ移動して開発画面を起動します。

cd my-site
npm run dev

ターミナルに Local とURLが表示されたら、そのアドレスをブラウザで開きます。Astroの初期画面が表示され、ターミナルに赤いエラーが出ていなければ、手元での起動は成功です。止めるときはターミナルで Ctrl+C を押します。

次に、公開用ファイルを作れるか確認します。

npm run build

コマンドが終了コード0で終わり、プロジェクト直下に dist フォルダができれば、Cloudflareへ渡す静的ファイルの準備ができています。Astroの既定の出力方式は static、astro build の既定の出力先は ./dist です。(Astroの設定リファレンス)

必要なら、配信用に作られた結果を手元で開きます。

npm run preview

dev は編集中の確認、build は配信用ファイルの生成、preview は生成後の結果の確認です。公開でだけ崩れる問題を減らすには、dev の表示だけで終えず、build を通すことが大切です。

記事を増やすサイトでは、Markdownファイルを読み込むContent Collectionsを使うと、タイトル、日付、カテゴリなどのfrontmatter(=記事冒頭の管理情報)にスキーマを設定できます。スキーマは、必要な項目や値の形をビルド時に検査する仕組みです。(Content Collections API) 最初の一ページを公開するだけなら、ここでContent Collectionsまで作り込む必要はありません。記事が増えて管理ミスが出始めた段階で導入しても間に合います。

手順2: GitHubに原本を置く

GitHubの右上にある作成メニューから New repository を開き、所有者、リポジトリ名、公開範囲を選びます。すでに手元にAstroプロジェクトがある場合は、GitHub側でREADME、.gitignore、ライセンスを先に生成しない方が、最初の送信時の競合を避けやすくなります。GitHub公式も、既存リポジトリを取り込む場合はこれらを事前作成するとマージ競合につながり得ると案内しています。(新しいリポジトリの作成)

公開範囲はPublicまたはPrivateを選べます。Publicではソースも誰でも読めます。Privateでは許可した利用者に閲覧を絞れますが、Cloudflareへ公開されたサイト自体は別です。原本をPrivateにしても、pages.dev の公開ページが非公開になるわけではありません。

GitHub Freeでは、機能に一部制限があるPrivateリポジトリを利用できます。個人サイトの原本を置く用途ではPrivateから始める選択もできます。(GitHubのリポジトリ解説)

Gitの初期化をAstro作成時に行わなかった場合は、プロジェクト内で次を実行します。

git init
git branch -M main

GitHubで作った空のリポジトリを origin という名前で登録します。YOUR_REPOSITORY_URL は、GitHubのQuick Setupに表示される自分のリポジトリURLへ置き換えます。

git remote add origin YOUR_REPOSITORY_URL

送信前に、対象ファイルを確認します。

git status

.env、秘密鍵、認証情報、個人情報を含むファイルが一覧にあれば、そのまま送らず .gitignore の対象にします。Astroのひな形が作る .gitignore では通常 node_modules や dist が除外されますが、自分で追加したファイルは別に確認します。

問題がなければ、最初の変更履歴を作ってGitHubへ送ります。

git add .
git commit -m "サイトの土台を作成"
git push -u origin main

GitHubのリポジトリ画面を再読み込みし、package.json、src、public などが見えれば成功です。node_modules が大量に並んでいる場合は送信対象が広すぎます。依存パッケージ本体ではなく、package.json とロックファイルから再現できる状態にします。

手順3: Cloudflare Pagesにつなぐ

Cloudflareへログインし、ダッシュボードの Workers & Pages を開きます。表示名が更新されている場合も、Pagesの作成画面から「既存のGitリポジトリを読み込む」経路を選びます。公式手順では、Pagesタブから既存Gitリポジトリを選び、GitHubリポジトリを指定してセットアップへ進みます。(AstroをCloudflare Pagesへ公開する手順)

GitHubとの初回連携では、Cloudflare Workers & Pages GitHub Appへリポジトリのアクセス権を渡します。すべてのリポジトリではなく、Only select repositories を選び、公開に使うリポジトリだけを許可します。Cloudflare公式も、Pagesでビルドする予定のリポジトリへ権限範囲を限定するよう勧めています。(Cloudflare PagesのGitHub連携)

ビルド設定では、次の値を入力します。

設定欄	入力する値	意味
Production branch	`main`	本番として公開する変更の流れ
Build command	`npm run build`	Astroへ配信用ファイルを作らせる命令
Build directory	`dist`	出来上がったファイルが入る場所
Project name	任意の利用可能な名前	`プロジェクト名.pages.dev` の一部

Root directoryという欄がある場合、Astroプロジェクトがリポジトリ直下にあるなら既定のままです。一つのリポジトリ内のサブフォルダにサイトを置いた場合だけ、そのフォルダを指定します。

Save and Deploy を押すと、CloudflareがGitHubからコードを取得し、依存パッケージを入れ、npm run build を実行します。デプロイの状態が成功になったら、発行された プロジェクト名.pages.dev を開きます。手元で見たAstroの画面と同じ内容が表示されれば、最初の公開は完了です。

CloudflareのAstro向け公式表では、Production branchは main、Build commandは npm run build、Build directoryは dist です。プロジェクト名は pages.dev のサブドメインに使われ、以後のpushごとに再ビルドと公開が行われます。(AstroをCloudflare Pagesへ公開する手順)

ここではGitHub Actionsを追加しません。PagesのGit連携だけで、ブランチへのpushをきっかけにビルドとデプロイが動きます。GitHub Actionsは、追加のテストを行う、別の配信方式を使うなど、目的が生まれたときに分けて考えます。最短手順へ二つのデプロイ経路を混ぜると、どちらが公開したのか追いにくくなります。

手順4: 記事の更新を自動公開する

最初の公開後は、次の順番が日常の更新作業になります。

MarkdownやAstroファイルを編集する。
npm run dev で表示を確認する。
npm run build を実行し、エラーがないことを確認する。
Gitへ変更を記録する。
main をGitHubへpushする。
Cloudflare PagesのDeploymentsで成功を確認する。
公開URLで変更箇所を開く。

コマンドにすると次の形です。

npm run build
git status
git add .
git commit -m "記事を更新"
git push

PagesのGit連携は、接続したブランチへpushするたびにコードを自動デプロイします。別ブランチやプルリクエストには、Productionへ影響しないプレビューURLを作れます。GitHub側にはビルドとデプロイの状態も表示されます。(Cloudflare PagesのGit連携)

いきなり main へ送るのが不安なら、作業用ブランチを作ってプレビューを確認し、問題がなければ main へ取り込む方法があります。プレビューURLは公開前の確認に便利ですが、URLを知る人がアクセスできる状態になる場合があります。未公開情報や個人情報の置き場にはしません。

当サイトでは、記事の形式チェックに通らない変更を公開しないため、ビルド前の機械検査も組み合わせています。これはPagesへ公開するための必須条件ではなく、記事数が増えた後の品質管理です。最初は npm run build を毎回通すところから始め、同じミスが繰り返されるようになったら、そのミスを検査するコマンドを追加すると管理しやすくなります。

GitHubは変更履歴を残せますが、アカウントへ入れなくなった場合まで含めたバックアップではありません。定期的に別の保存先へコピーする、手元の作業フォルダを失わないようにするなど、原本の所在を一つにしない運用も検討します。

無料枠の上限を数字で確認する

静的アセットへのリクエストが無料かつ無制限でも、ビルド回数やファイルには上限があります。2026年7月26日に確認したCloudflare Pages Freeプランの主な上限は次のとおりです。(Cloudflare Pagesの上限)

項目	Freeプランの上限	個人サイトで気をつける場面
ビルド回数	月500回	保存のたびにpushする自動処理を組む場合
同時ビルド	1件	複数ブランチを短時間に連続更新する場合
1回のビルド時間	20分でタイムアウト	重い画像処理や大量生成をビルドへ入れる場合
1サイトのファイル数	20,000ファイル	画像や生成ページが非常に多い場合
1ファイルの最大サイズ	25MiB	動画や大きな配布ファイルを直接置く場合
独自ドメイン	1プロジェクト100件	多数のブランドや顧客ドメインを束ねる場合
Pagesプロジェクト	1アカウント100件	サイトを大量に分ける場合

月500回は、一日平均に直すと十数回です。通常の記事更新なら収まりやすい一方、外部データを数分おきに取得して自動公開する用途には向きません。ビルド回数を減らすには、細かな修正をまとめる、変更がないときはpushしない、データ更新とサイト全体の再ビルドを同じ頻度にしない、といった設計が必要です。

25MiBを超える動画や大きな配布物を置きたい場合は、Pagesへ直接入れず、用途に合うストレージや動画配信を分けます。サイト本体の軽いHTMLや画像と、大容量ファイルの配信を同じ場所へ押し込まない方が、ビルド時間と転送方法を管理しやすくなります。

上限は変更される可能性があります。この記事の数値だけで長期計画を固定せず、利用量が近づいた時点で公式のLimitsを見直します。

任意: 独自ドメインを正しい順序でつなぐ

独自ドメインは、当サイトなら tech-rashinban.com に当たるサイト固有の住所です。無料の pages.dev で目的を満たすなら、この節は飛ばせます。

独自ドメインを使う場合は、DNSへCNAMEを先に追加するのではなく、Cloudflare Pages側で対象ドメインを関連付けるところから始めます。

Cloudflareの Workers & Pages から対象プロジェクトを開く。
Custom domains を開く。
Set up a domain を選ぶ。
使いたいドメインまたはサブドメインを入力する。
画面に示されたDNS設定を行う。
状態が有効になった後、独自ドメインと pages.dev の両方を開く。

example.com のように左側へ名前が付かないapexドメイン(=ルートドメイン)を使う場合は、そのドメインをCloudflareのzoneへ追加し、ネームサーバーをCloudflareへ向ける必要があります。www.example.com や blog.example.com のようなサブドメインは、外部DNSから <YOUR_SITE>.pages.dev へCNAMEを向けられます。(Cloudflare Pagesの独自ドメイン設定)

重要なのは順序です。Pagesの画面で関連付けず、DNSへCNAMEだけを手作業で追加すると、Cloudflare公式が説明する 522 エラーになることがあります。以前の「CNAMEを1〜2件追加するだけ」という理解では、apexとサブドメインの違い、Pages側の関連付けが抜けます。

HTTPSについては、Cloudflareへ追加して有効になったドメインにUniversal SSL証明書が発行され、発行・更新・配備はCloudflare側で処理されます。Freeプランも対象です。(Cloudflare Universal SSL) ただし、有効化前から証明書が使えるわけではありません。CAAレコードがCloudflareの利用する認証局を許可していない、Accessやリダイレクトがドメイン確認を妨げる、といった場合は設定の見直しが必要です。

ドメイン名は後から変更できますが、公開済みURL、検索サービス、外部リンク、メールアドレスなどの変更作業が発生します。取得時は価格だけでなく、サイト名との一致、更新価格、更新方法、管理アカウントを確認します。

つまずきやすいポイントを順番に切り分ける

問題が起きたときは、設定を一度に変えず、「手元のビルド」「Pagesのビルド」「pages.dev」「独自ドメイン」の順に境界を分けます。どこまで動いているかが分かれば、見る場所を絞れます。

`npm run build` が手元で失敗する

Cloudflareへ進む前に、ターミナルの最初のエラーを読みます。最後に出る長い追跡情報より、最初に示されたファイル名と行番号が原因に近いことがあります。

command not found や「認識されていません」なら、Node.js、npm、依存パッケージの導入を確認する。
Cannot find package や Cannot find module なら、プロジェクト直下で npm install を実行し、package.json とロックファイルを確認する。
Markdownやfrontmatterのエラーなら、示された記事ファイルの引用符、日付、区切りを確認する。
画像や内部リンクのエラーなら、ファイル名の大文字・小文字と実在を確認する。

手元の npm run build が失敗したままCloudflareへ送ると、Pagesでも同じ原因で失敗する可能性が高くなります。

Cloudflare Pagesのビルドが失敗する

Cloudflareダッシュボードで、対象プロジェクトの Deployments → View details → Build log を開きます。公式のデバッグ手順も、ビルドログを入口にし、Build command、Output folder、Environment variablesを確認するよう案内しています。(Cloudflare Pagesのデバッグ)

次を照合します。

ログや状態	最初に見る場所	代表的な修正
コマンドが見つからない	Build command	`npm run build` になっているか
成果物が見つからない	Build directory	Astro既定なら `dist` か
パッケージ導入で失敗	`package.json` とロックファイル	手元とGitHubの内容が一致しているか
リポジトリを取得できない	GitHub Appの権限	対象リポジトリが許可されているか
手元だけ成功する	Node.js版、環境変数	ログに表示された環境との差を確認する

出力フォルダの指定ミスだけに決めつけず、ログが止まった段階から判断します。

`pages.dev` が404または白い画面になる

最初にDeploymentが成功しているかを見ます。Cloudflare公式は、ルートの pages.dev で404になる場合、プロジェクトのルートに index.html がない可能性を挙げています。Astroでは npm run build 後の dist に index.html があるか、Build directoryが dist かを確認します。(Cloudflare Pagesのデバッグ)

白い画面でも、ブラウザの開発者ツールにエラーが出ている場合は、JavaScriptや画像のパスが原因かもしれません。まず npm run preview で同じ症状が出るかを確認し、手元でも出るならAstro側、Pagesだけならビルド設定側へ分けます。

独自ドメインだけ表示されない

pages.dev が表示できるなら、サイト本体のビルドは動いています。次にPagesの Custom domains で状態を見て、DNSレコード、Pages側の関連付け、apexとサブドメインの設定を照合します。

522 なら、CNAMEだけを先に作ってPagesへ関連付けていない可能性を確認する。
Verifying のままなら、Access、Redirect Rule、WorkerなどがHTTPによる確認を妨げていないかを見る。
CAAを独自設定しているなら、Cloudflareが使う認証局の証明書発行を許可しているかを見る。
pages.dev と独自ドメインで挙動が違うなら、独自ドメイン側のzone設定を確認する。

DNSは反映待ちになることがありますが、待つ前に設定値と状態を確認します。誤ったレコードは時間を置いても正しくなりません。

更新したのに古い内容が見える

まず、GitHubに最新commitがあるか、Pagesの最新Deploymentがそのcommitで成功しているかを見ます。次に pages.dev と独自ドメインを別々に開きます。pages.dev だけ新しければ、独自ドメイン側のキャッシュやzone設定を調べます。Cloudflare公式は、独自ドメインで新しい内容が出ない場合、Cache Everything を設定したPage Ruleがないか確認するよう案内しています。(Cloudflare Pagesのデバッグ)

最後にシークレットウィンドウや別ブラウザでも開くと、手元のブラウザだけが古いデータを持っているかを切り分けられます。最初からキャッシュと決めつけず、commit、Deployment、pages.dev、独自ドメイン、ブラウザの順に確認します。

この構成が向く人・向かない人

向くのは、記事を書いて公開することが目的の個人サイト、ブログ、ポートフォリオ、会社や活動の案内ページです。内容をGitで管理したい人、公開前にビルド検査を入れたい人、管理画面やデータベースを自分で保守したくない人とも相性があります。

一方、次の用途では、この構成単体では足りません。

複数人がブラウザの管理画面から記事を編集したい。
利用者の会員登録、ログイン、権限管理が必要。
コメント、予約、決済、投稿、個別のダッシュボードが必要。
閲覧者ごとに違う内容をサーバー側で生成したい。
大きな動画や配布ファイルを多数置きたい。
数分おきのデータ更新など、月500回のビルドを超えやすい。

問い合わせフォームも注意が必要です。HTMLの入力欄を表示するだけなら静的に作れますが、送信内容を受け取り、保存し、通知する処理は別に必要です。外部フォームサービスやWorkersを使うと、利用規約、個人情報の扱い、迷惑送信対策、費用の確認対象が増えます。

Astro公式は、静的サイトとして使う場合はアダプターが不要だと説明しています。また、現在の @astrojs/cloudflare アダプターはCloudflare Pagesへのデプロイ対応を終了しており、動的機能ではCloudflare Workersへの移行を案内しています。(AstroのCloudflareアダプター)

Cloudflareの移行資料でも、Workersは静的アセットに加えてバックエンドAPIやSSR(=アクセス時にサーバー側で画面を作る方式)を扱え、Durable Objects、Cron Triggers、より広い観測機能などを備えると説明しています。(PagesからWorkersへの移行) 会員機能や定期処理が必要になったら、静的Pagesへ無理に追加するより、Workersや目的に合う別サービスを比較します。

公開後に続ける管理

月額のサーバー管理がなくても、サイト運営の作業がゼロになるわけではありません。少なくとも次の五つは残ります。

依存パッケージの更新: Astroや周辺パッケージの更新内容を読み、npm run build を通してから反映します。
アカウント保護: GitHubとCloudflareの多要素認証、不要になったGitHub App権限、共有相手を見直します。
原本の保全: GitHubだけに依存せず、別の保存先や手元のコピーから復元できる状態を考えます。
独自ドメインの更新: 利用する場合は、有効期限、更新価格、支払い方法、登録メールを管理します。
公開内容の確認: 個人情報、秘密、権利を確認してからpushし、公開URLでも表示を見ます。

静的サイトの利点は、運用が不要になることではなく、管理する部品と失敗の分かれ道を減らしやすいことです。更新手順を毎回同じ順番にすると、どこで問題が起きたかを後から追いやすくなります。

最小の運用チェックは次の形です。

編集
  ↓
手元で表示
  ↓
ビルド成功
  ↓
Gitの差分確認
  ↓
push
  ↓
Pagesの成功確認
  ↓
公開URLの確認

記事が増えたら、内部リンク切れ、必須項目、禁止表現、画像の実在などを機械検査へ移します。最初から大きな自動化を作るより、実際に起きたミスを一つずつ検査へ追加する方が、不要な仕組みを増やしにくくなります。

よくある質問

本当に毎月0円で公開できますか

Astroで静的ファイルを作り、GitHub Freeの範囲で原本を管理し、Cloudflare Pagesの無料枠と pages.dev を使う構成なら、この記事で扱うサーバー配信の月額を0円にできます。Cloudflareは、Functionsを呼び出さない静的アセットへのリクエストを無料かつ無制限としています。(Pages Functionsの料金)

ただし、独自ドメイン、パソコン、通信環境、作業時間、有料テーマ、外部フォーム、画像や動画の外部サービスは別です。Functionsを使う場合もWorkersの利用枠を確認します。

GitHubのリポジトリは非公開でも使えますか

GitHub Freeでは、機能に一部制限があるPrivateリポジトリを利用できます。Cloudflare PagesのGitHub Appに対象リポジトリへのアクセスを許可すれば、Privateリポジトリからもビルドできます。(GitHubのリポジトリ解説)

Privateなのは原本であり、Cloudflare Pagesへ配信したサイトは公開されます。未公開の文章や秘密をリポジトリへ置く場合も、Cloudflareのビルド対象や公開フォルダへ混ざらないようにします。

更新のたびにCloudflareの画面で操作が必要ですか

Git連携では、Production branchへpushするたびにPagesがビルドとデプロイを行います。通常の更新で毎回 Save and Deploy を押す必要はありません。失敗時のログ確認、設定変更、独自ドメインの管理ではCloudflare画面を使います。(Cloudflare PagesのGit連携)

独自ドメインはCNAMEを追加するだけですか

一律ではありません。最初にPagesの Custom domains で関連付けます。apexドメインではCloudflareのzoneとネームサーバー設定が必要です。外部DNSでサブドメインを使う場合は、pages.dev へCNAMEを向けられます。Pagesへ関連付けずCNAMEだけを作ると、522 になる場合があります。(Cloudflare Pagesの独自ドメイン設定)

`@astrojs/cloudflare` アダプターは必要ですか

この記事の静的サイトには不要です。Astroの既定の static 出力を dist へ作り、Pagesがそのフォルダを配信します。Astro公式も、静的サイトビルダーとして使う場合はアダプターが不要だと説明しています。現在のCloudflareアダプターはPagesへのデプロイ対応を終了しているため、SSRや動的機能が必要ならWorkers向けの現行手順を検討します。(AstroのCloudflareアダプター)

無料枠を超えたらサイトがすぐ消えますか

上限ごとに影響が異なるため、「超えたらすべて同じ動き」とは言えません。たとえばビルド上限は新しい公開処理、ファイル数やファイルサイズは配信物の作り方に関係します。利用量が上限へ近づいたら、Cloudflareの最新説明とダッシュボードの表示を確認し、画像の置き場所、ビルド頻度、PagesとWorkersの使い分けを見直します。(Cloudflare Pagesの上限)

まとめ: 静的なまま小さく始める

この構成では、Astroが静的HTMLを作り、GitHubが原本と履歴を持ち、Cloudflare Pagesが公開を担当します。pages.dev と無料枠を使う範囲なら、サーバー配信の月額を0円にして始められます。

最初に達成する順番は、次の四つです。

npm run dev で手元の画面を開く。
npm run build で dist を作る。
GitHubへ原本をpushする。
Pagesで main、npm run build、dist を設定し、pages.dev を開く。

独自ドメインは任意で、追加するならPages側の関連付けを先に行います。ビルド失敗はBuild log、独自ドメインの問題は pages.dev との差から切り分けます。会員、コメント、データベース、SSRなどが必要になったら、静的Pagesの範囲を越えた合図です。その時点でWorkersや別の基盤を比較します。

「まず器を無料で持ち、記事に集中する」という考え方は、個人ブログや案内サイトを小さく始めるときに有効です。同時に、無料枠にも上限があり、アカウント保護、依存更新、バックアップ、公開内容の確認は運営者に残ります。費用だけでなく、続けられる更新手順まで含めて選ぶことが大切です。

本記事の手順・料金・上限は、2026年7月26日時点の各サービス公式情報と当サイトの実運用に基づきます。無料枠の条件、画面名、必要バージョン、価格は変わることがあるため、利用時点の公式情報も確認してください。

Sources

確認日：2026年7月26日。当サイトの実運用にもとづく記述を除き、外部仕様と数値は以下の公式資料で確認しました。

Astro公式

Install Astro — Node.jsの要件、奇数版の扱い、新規プロジェクト作成コマンド、標準スクリプトを確認。
Configuration Reference — output の既定値が static、outDir の既定値が ./dist であることを確認。
Content Collections API Reference — Markdownなどの読み込みとfrontmatterのスキーマ定義を確認。
@astrojs/cloudflare — 静的サイトにはアダプターが不要で、現行アダプターがPagesへのデプロイ対応を終了したことを確認。

GitHub公式

Creating a new repository — Web画面での作成手順と、既存プロジェクトではREADMEなどの事前生成が競合につながり得ることを確認。
About repositories — GitHub FreeのPublic・Privateリポジトリと公開範囲を確認。

Cloudflare公式

Deploy an Astro site — main、npm run build、dist の設定と pages.dev での公開を確認。
Git integration — pushごとの自動デプロイ、ブランチとプルリクエストのプレビューを確認。
GitHub integration — GitHub Appの権限を対象リポジトリへ限定する案内を確認。
Pages Functions pricing — 静的アセットのリクエストとFunctionsの利用枠の違いを確認。
Pages limits — 月500ビルド、20分、20,000ファイル、25MiBなどのFreeプラン上限を確認。
Custom domains — apexとサブドメインの違い、Pages側の関連付け、CNAMEだけを作った場合の 522 を確認。
Debugging Pages — Build logの場所、ビルド設定、独自ドメイン、CAA、キャッシュの切り分けを確認。
Universal SSL — 証明書の発行・更新・配備とFreeプランでの提供を確認。
Cloudflare Registrar — 登録・更新に上乗せ手数料を加えない料金方針を確認。
Migrate from Pages to Workers — Workersで扱える静的アセット、API、SSRとPagesより広い機能を確認。

npm・Node.js公式

Downloading and installing Node.js and npm — node -v、npm -v での確認とバージョン管理ツールの案内を確認。
Download Node.js — LTSとCurrentが分かれて提供されていることを確認。