Firecrawl APIをセルフホストする方法：Docker導入と料金比較

結論：この規模ならFirecrawl APIはCloudのほうが安い

ソースへのアクセス、インフラの管理権限、または必須のネットワーク境界に、スタックを所有するだけの価値がある場合はFirecrawlをセルフホストします。公開URLをクリーンなコンテンツへ変換することだけが目的ならCloudを選ぶべきです。 Firecrawlもセルフホストガイドで同じ結論を示しています。Cloudは本番投入までの最短かつ公式サポートのある経路ですが、セルフホストでは周辺の仕組みすべてを自チームで運用します。

セルフホストの金額は予算であり、処理能力を保証するものではありません。Firecrawlは検証済みの最小ホスト構成を公表しておらず、この検証でも、想定したマシンがどちらの件数を処理できるかは確認できませんでした。割増コストを受け入れる正当な理由は管理権限です。費用削減を理由にするなら、自社のページ、同時実行数、失敗率で実証する必要があります。

Firecrawl APIをセルフホストして得られるもの

管理下のインフラでFirecrawlのコアエンジンを動かせますが、その周囲にあるすべての依存サービスを運用する責任も引き受けます。 Cloudがスタッフのそろった業務用キッチンだとすれば、セルフホストで受け取るのはキッチンの設計図です。設計図は確認でき、変更もできる有用なものですが、調理スタッフ、消防検査、冷蔵設備の点検、夜間シフトまでは付いてきません。

固定した標準スタックは、コアのscrape、crawl、map、searchルートに対応しています。FetchとPlaywrightによる処理も含まれます。一方で、PostgreSQL、Redis、RabbitMQなどのサービスに依存しており、readinessエンドポイントだけでは処理経路全体の動作を確認できません。

この境界は重要です。{"status":"ok"} が証明するのは、単一のHTTPエンドポイントが応答したことだけです。ページ取得の通信がホストの外へ出て、レンダリングされ、ワーカーを通り、Markdownとして返るところまでは保証しません。実際のスクレイプ成功が、最低限必要な証拠です。

FirecrawlをDockerで導入：ガイドと同じリリースに固定する

動き続ける main ブランチではなく、Firecrawl v2.11.162 を使います。 このタグは2026年7月30日に作成され、コミット 7666c1f9ae8720a6bba271e0f60b6a217f8a5210 を指しています。バージョンを固定すれば、コード、Composeファイル、セットアップ手順を同じ時点にそろえられます。

公式の前提条件は、Git、Docker EngineまたはDocker Desktop、Docker Compose v2、curl、空いているポート3002、そして複数サービスをビルドして実行できる十分なホスト容量です。Firecrawlは検証済みの最小マシンスペックを公表していません。

git clone https://github.com/firecrawl/firecrawl.git
cd firecrawl
git checkout v2.11.162
git rev-parse HEAD

db_password="$(openssl rand -hex 32)"
printf 'USE_DB_AUTHENTICATION=false\nPOSTGRES_USER=postgres\nPOSTGRES_PASSWORD=%s\nPOSTGRES_DB=postgres\n' \
  "$db_password" > .env

docker compose up --build -d
docker compose ps --all

curl --fail --silent --show-error --max-time 5 \
  http://localhost:3002/v0/health/readiness

curl --fail-with-body --silent --show-error --max-time 75 \
  -X POST http://localhost:3002/v2/scrape \
  -H 'Content-Type: application/json' \
  -d '{"url":"https://example.com","formats":["markdown"],"timeout":60000}'

スクレイプが合格するのは、レスポンスに success: true と返却されたMarkdownがあり、メタデータの statusCode: 200 も確認できた場合だけです。メタデータの詳細は対象サイトによって変わります。readinessが通ってもスクレイプが失敗するなら、緑色のハートビートでは通らなかった経路を調べるため、APIとPlaywrightのログを確認します。

別のエンジニアへ渡せる検証記録を保存する

未加工の証跡がターミナルセッション終了後も残って、初めてセットアップは検証済みといえます。 以下のスクリプトは固定済みリポジトリから実行し、ホスト仕様、正確なリリース、ビルド時間、コンテナ状態、readiness出力、10件の未加工スクレイプレスポンス、サマリー、リソーススナップショット1件、再起動時の出力、再起動後に成功した2回目のスクレイプを、タイムスタンプ付きディレクトリへ保存します。

10番目のURLには予約済みの .invalid ドメインを使うため、実在サイトの障害に依存せず、意図的な失敗を試験データへ含められます。残る9件は固定した公開ページです。このスクリプトはリクエストJSONの作成と結果フィールドの読み取りに使うため、実行前に jq をインストールしてください。

#!/usr/bin/env bash
set -euo pipefail

base_url="${FIRECRAWL_BASE_URL:-http://localhost:3002}"
stamp="$(date -u +%Y%m%dT%H%M%SZ)"
out="firecrawl-verification-${stamp}"
mkdir -p "$out/responses"

actual_release="$(git describe --tags --exact-match)"
[[ "$actual_release" == "v2.11.162" ]] || {
  printf 'Expected v2.11.162, found %s\n' "$actual_release" >&2
  exit 1
}

{
  printf 'checked_at_utc=%s\n' "$(date -u +%FT%TZ)"
  printf 'release=%s\n' "$actual_release"
  printf 'commit=%s\n' "$(git rev-parse HEAD)"
  printf 'cpus=%s\n' "$(getconf _NPROCESSORS_ONLN)"
  awk '/MemTotal/ {printf "memory_kib=%s\n", $2}' /proc/meminfo
  uname -a
  docker version
  docker compose version
} > "$out/host.txt" 2>&1

setup_start="$(date +%s)"
docker compose up --build -d > "$out/compose-up.log" 2>&1
printf '%s\n' "$(( $(date +%s) - setup_start ))" > "$out/setup-seconds.txt"
docker compose ps --all --format json > "$out/containers-before.json"
curl --fail --silent --show-error --max-time 5 \
  "$base_url/v0/health/readiness" > "$out/readiness.json"

targets=(
  https://example.com
  https://example.org
  https://example.net
  https://httpbin.org/html
  https://www.iana.org/help/example-domains
  https://www.rfc-editor.org/rfc/rfc9110
  https://www.w3.org/TR/PNG/iso_8859-1.txt
  https://docs.python.org/3/
  https://www.firecrawl.dev/
  https://fixture-failure.invalid/
)

printf 'index\turl\tcurl_exit\tsuccess\tstatus_code\n' > "$out/summary.tsv"
i=0
for target in "${targets[@]}"; do
  i=$((i + 1))
  response="$out/responses/$(printf '%02d' "$i").json"
  payload="$(jq -n --arg url "$target" \
    '{url:$url,formats:["markdown"],timeout:60000}')"
  if curl --silent --show-error --max-time 75 -X POST \
    "$base_url/v2/scrape" -H 'Content-Type: application/json' \
    -d "$payload" > "$response"; then curl_exit=0; else curl_exit=$?; fi
  success="$(jq -r '.success // false' "$response" 2>/dev/null || printf false)"
  status="$(jq -r '.data.metadata.statusCode // .error // "none"' \
    "$response" 2>/dev/null || printf unreadable)"
  printf '%s\t%s\t%s\t%s\t%s\n' \
    "$i" "$target" "$curl_exit" "$success" "$status" >> "$out/summary.tsv"
done

docker stats --no-stream --format json > "$out/container-stats.json"
docker compose restart > "$out/restart.log" 2>&1
for attempt in $(seq 1 60); do
  if curl --fail --silent --max-time 5 "$base_url/v0/health/readiness" \
    > "$out/readiness-after-restart.json"; then break; fi
  sleep 2
done
docker compose ps --all --format json > "$out/containers-after.json"
jq -n '{url:"https://example.com",formats:["markdown"],timeout:60000}' | \
  curl --fail-with-body --silent --show-error --max-time 75 \
    -X POST "$base_url/v2/scrape" -H 'Content-Type: application/json' -d @- \
    > "$out/restart-scrape.json"

jq -e -s 'all(.[]; .success == true and .data.metadata.statusCode == 200)' \
  "$out/responses/01.json" "$out/restart-scrape.json" >/dev/null
printf 'Saved verification record: %s\n' "$out"

最初のスクレイプと再起動後のスクレイプが両方とも成功するまでは、この記録を根拠に成功を公表してはいけません。失敗したレスポンスもすべて残します。失敗はDNS、外向き通信、アンチボット動作、対象サイトの状態、スタック自体についての証拠です。削除すれば記録の価値が下がります。

標準スタックで対応できる範囲を把握する

セルフホスト版Firecrawlに含まれるのはコアのルートであり、Firecrawl製品の全機能ではありません。 設定項目が存在するという理由ではなく、計測で必要性が判明した場合にだけサービスを追加します。

このデプロイ判断以外にもCloudでの検索・取得手段を比較したい場合は、AI検索APIの比較で幅広いベンダーを取り上げています。代替スクレイパーの選定は別の購入判断です。

セルフホストの恩恵が大きいチーム

最も適しているのは、すでにプラットフォーム機能を持ち、管理権限が必要なチームです。 小規模な処理量では、ページ単価の低さだけでは十分な理由になりません。

不向きなケースも明確です。信頼できるスクレイプエンドポイントが1つ欲しいだけの2人のプロダクトチームにとって、セルフホストは不要だった運用プロジェクトを買うことになります。Agent、Browser、Interact、スクリーンショット、ページ操作、マネージドの高度なスクレイピングに依存するチームも、機能境界の選択を誤っています。

Firecrawlの料金を30日間で比較：管理権限にもコストがかかる

基本ページ1,000件と10,000件では、明示した保守的な前提のもとで、マネージド版Firecrawlのほうが安価です。 セルフホストの予算は、8 vCPU、16 GiB RAM、320 GiB SSDのDigitalOcean Basic Dropletを月額$96、100 GiBの永続Volumeを$10、週次バックアップの予算を$19.20として計算しています。DigitalOceanがこれらの価格を掲載していたのは2026年9月22日です。

16 GiBは公式の最小要件ではありません。固定したComposeファイルではAPIサービスの上限が8 GiB、Playwrightが4 GiBである一方、データベース、キャッシュ、キューなどのプロセスにも余裕が必要であることを踏まえた予算上の仮定です。ホストを適切にサイジングできるのは、ワークロードテストだけです。

より大きな費目は運用担当者の時間です。この試算では、最初の30日間にセットアップ4時間、保守2時間を使い、人件費を1時間当たり$100と仮定しています。これは仮定であり、市場相場ではありません。自社の数値に置き換えてください。

Firecrawl Cloudでは、基本ページのスクレイプ1件につき1クレジットを消費します。Freeプランには1,000クレジットが$0で含まれます。月単位の支払いで10,000ページを処理する場合、Hobbyは5,000クレジットで$19、追加のHobbyクレジット5,000件は$5の追加分を5回購入するため、合計$44です。Hobbyの年払いなら実質月額は$41まで下がりますが、年間契約が必要です。

このモデルには、税金、任意のLLMプロバイダー、プロキシ料金、Fire-engine、高可用性、超過転送、法務レビュー、インシデント対応を含めていません。また、セルフホスト機に未実証の処理能力を計上していません。セットアップ4時間分を除いた翌月以降の試算でも、セルフホストは$325.20となり、どちらの処理量でもCloudを上回ります。

セルフホストでは絶対に節約できない、という結論ではありません。ベンチマークで処理能力を証明し、十分な処理量によって固定インフラ費と運用時間を成功ページ全体へ分散できて、初めて節約が始まります。10,000ページの場合、この試算で初月に生じる$681.20の差額を、管理権限の要件で正当化できなければなりません。

この差を事業機会に変える3つの製品

最も有望なのは検証パックです。Firecrawl自体と競合せず、曖昧なセットアップを証拠に変えられるからです。 1回のライブ検索スナップショットでは、関連検索が8件、People Also Askの質問が9件返りました。関連検索のうち5件はDocker、Docker Compose、無料利用、Cloudとの比較、APIキーに関するもので、質問にはFirecrawlが高価か、安全かという問いが明示的に含まれています。

1. セルフホストの準備状況・検証パック

エンジニアリング責任者向けのローカルCLIとレポートです。リリース、ホスト、Composeの状態、実際のスクレイプ経路、想定どおりの失敗、再起動後の動作、本番化に足りない要素を確認し、レビュー用の署名付きアーカイブを生成します。

需要のシグナルは明確です。Googleの関連検索には Firecrawl self-host Docker、Firecrawl self-host docker compose、Firecrawl self-host API key が含まれています。販売可能な最小構成は、単一コマンド、固定試験データ、HTMLレポート、秘匿化コントロールです。難点は環境差です。レポートで証明できるのは実際に動いた内容であり、すべての対象サイトや将来のリリースで同じ動作を保証することはできません。

2. Cloudとセルフホストの費用プランナー

成功ページ数、オプション、同時実行数、運用担当者の単価、復旧目標、必要機能を入力するデプロイ計算ツールです。Cloudのクレジットとインフラ・人件費を、すべての前提とともに並べて表示します。

検索スナップショットには Firecrawl self-hosted vs cloud があり、People Also Askには Is Firecrawl expensive? と Is there a free version of Firecrawl available? があります。実際の価格基準も明確です。Cloudの1,000クレジットは$0、月単位のHobbyは5,000クレジットで$19、Hobbyの追加1,000クレジットごとに$5です。MVPは、バージョン管理した料金表と試算表のエクスポートです。難点はセルフホストの処理能力です。購入者自身のベンチマークがなければ、架空の損益分岐点ではなく範囲を示す必要があります。

3. 本番環境の堅牢化ブループリント

評価を通過し、次に認証、TLS、データ永続化、バックアップ、復元テスト、監視、シークレット、外向き通信の制御が必要になったチーム向けの、方針を明確にしたインフラモジュールです。

需要のシグナルは、People Also Askの Is Firecrawl safe to use? と関連検索の Firecrawl self-host API key の両方に表れています。Firecrawl自身のガイドに不足している本番環境の判断事項がすべて列挙されているため、価値は実装と証跡にあります。責任範囲が記載されていないかのように見せることではありません。MVPは、サポート対象のクラウド1つ、バージョン固定したInfrastructure as Code、アラート、復旧訓練です。難点は責任です。再利用可能なモジュールでも、顧客のセキュリティやコンプライアンス態勢を認証することはできません。

限界と率直な結論

$19を節約するためだけに、運用作業を測定する前からFirecrawlをセルフホストしてはいけません。 基準構成ではAPI認証を無効にし、TLSもなく、PostgreSQL、Redis、RabbitMQの永続ストレージも追加されておらず、高可用性でもありません。信頼できないネットワークに公開すれば、評価用の近道がセキュリティ上の過ちになります。

標準スタックがCloudと同じ機能を備えると思い込んではいけません。LLM形式にはプロバイダーが必要です。Fire-engineは別サービスです。標準経路ではスクリーンショットとページ操作を利用できません。Agent、Browser、Interact、ダッシュボード、エンタープライズ管理は引き続きCloudの機能であり、使うには別途検証済みのサービスが必要です。

Composeの上限値やこの試算だけで本番環境をサイジングしてはいけません。メモリ上限は推奨ホスト構成ではありません。固定試験データを実行し、自社ワークロードを代表するページを追加し、同時実行数と失敗の種類を測定したうえで、バックアップからの復元とアップグレードのロールバックをテストします。

進めるべき最も強い理由は、Cloudでは満たせない管理要件がチームにあることです。最も弱い理由は「無料」という言葉です。

月曜日に実行すること

使い捨ての非公開ホストを用意し、1人のエンジニアに2時間の評価枠を渡します。 v2.11.162 に固定して、公式手順どおりに単一のスクレイプを実行し、保存用の検証スクリプトを動かします。再起動後のスクレイプが失敗したら、そこで中止します。次に、試算の運用単価$100を自社の人件費へ置き換え、必要な管理要件を1文で記します。その1文が曖昧ならCloudを選び、具体的なら処理量を増やす前に本番環境の統制を設計します。

管理要件に合わせ、バージョン固定と可観測性を備えたデプロイが必要なら、AI本番システムをご覧ください。