Firecrawl のセルフホスティング

ソースコードやインフラを管理する必要がある場合は、Docker Compose を使用して Firecrawl をセルフホストします。このガイドではリリース v2.11.162 を固定し、http://localhost:3002 で API を起動して、Markdown を含む POST /v2/scrape の正常なレスポンスを確認します。

• ソースコードやインフラを自分で管理したい場合。 このガイドでは、API とその関連サービスをお使いのマシンで実行します。
• スタックの運用に慣れている場合。 アップグレード、セキュリティ、ストレージ、監視、復旧はお客様の責任となります。
• Firecrawl を自社環境で検証したい場合。 まずここでベースラインを動作させ、その後 本番環境に移行する前に で必要な管理策を設計してください。

インフラを運用せずにスクレイピングを始めたい場合は、Firecrawl Cloud を選択してください。機能の違いについては、Open Source vs Cloud を参照してください。

推奨事項: ソースコードへのアクセスやインフラの管理が運用負荷に見合う場合は、セルフホストを選択してください。本番環境への最短のサポート対象パスを求める場合は、Firecrawl Cloud から始めてください。

• アップグレード、シークレット、ストレージ、監視、復旧、インシデント対応はすべてご自身で担います。
• スクレイピングでは、対象 Web サイトへのアウトバウンドリクエストが引き続き送信されます。任意のプロキシ、解析、AI プロバイダーを追加すると、データフローも増えます。
• このガイドでは、最初の実行を意図的にシンプルにしています。まず 1 回のスクレイピングを動作させ、その後は一度に 1 つの設定を変更してください。
• コマンドは v2.11.162 に固定されています。別のリリースでは、異なる Compose コントラクトが使用される場合があります。

• リリース: Firecrawl v2.11.162。 まずコードと構成を固定します。対象リリースの docker-compose.yaml とセルフホスティングに関する注意事項を確認してからアップグレードしてください。
• API 認証: このローカル実行では無効。 サポート対象の完全な ID 管理とデータベース設計を用意できる場合にのみ追加してください。環境変数 1 つだけでは不十分です。
• キュー: PostgreSQL。 任意の FoundationDB バックエンドを意図して運用する場合を除き、そのまま使用してください。
• キュー管理 UI: 無効。 強力な BULL_AUTH_KEY とネットワーク制御を設定できる場合にのみ有効にしてください。
• AI および高度なスクレイピングプロバイダー: 未構成。 必要な機能で求められる場合にプロバイダーを追加してください。

最初の実行はシンプルに保ちましょう。まず 1 件のスクレイピングを動作させ、その後ユースケースに必要なものを追加してください。

開始前に、以下をインストールしてください。

• Git
• Docker Engine または Docker Desktop
• docker compose として実行する Docker Compose v2
• 確認リクエストに使用する curl

ポート 3002 が使用可能であり、Docker が複数のサービスをビルド・実行できる十分なリソースを備えていることを確認してください。Firecrawl は、このスタックに必要な最小ホスト要件を検証・公開していません。

このガイドは Firecrawl v2.11.162 で検証されています。コード、コマンド、構成の整合性を保つため、該当するリリースをチェックアウトしてください。

git clone https://github.com/firecrawl/firecrawl.gitcd firecrawlgit checkout v2.11.162

別のリリースを使用する場合は、これらの値を再利用する前に、そのリリースの docker-compose.yaml とセルフホスティングに関する注意事項を確認してください。

リポジトリのルートに、動作に必要な最小限の .env ファイルを作成します。

cat > .env <<'EOF'USE_DB_AUTHENTICATION=falsePOSTGRES_USER=postgresPOSTGRES_PASSWORD=replace-with-at-least-32-random-charactersPOSTGRES_DB=postgresEOF

スタックを起動する前にPostgreSQLのパスワードを変更し、.envはコミットしないでください。バンドルされているpg_cronの構成がそのデータベースを対象としているため、v2.11.162ではPOSTGRES_DB=postgresのままにしてください。Composeはこれらの値をAPIサービスとPostgreSQLサービスの両方に渡します。

NUQ_BACKENDとBULL_AUTH_KEYは未設定のままにしてください。キュー管理UIを起動せずにPostgreSQLキューを使用します。初回のスクレイピングでは、構成要素を減らせます。

チェックアウトしたソースをビルドし、すべてのサービスをバックグラウンドで起動します。

docker compose up --build -ddocker compose ps --all

このベースラインでは、未設定の任意変数に関する警告が表示されるのは想定どおりです。docker compose ps --all では、API と関連サービスが実行中で、1 回限りの初期化サービスが完了していることを確認できます。サービスがまだ起動中の場合は、スタックが立ち上がるまで少し待ってください。

まず、API が HTTP リクエストに応答できることを確認します。

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

想定されるレスポンス：

{"status":"ok"}

次に、重要なパスである実際のスクレイピングを1回テストします。リクエストのタイムアウトはミリ秒単位です。curl'sのクライアントタイムアウトは秒単位で、少し長めに設定されています：

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,  "data": {    "markdown": "...",    "metadata": {      "statusCode": 200    }  }}

これにより、API、スクレイピングパイプライン、スクレイピングエンジンの一つの経路、外部へのアクセスをまとめて確認できます。メタデータの詳細は、対象からのレスポンスによって異なる場合があります。

これらの成功フィールドが返れば、Firecrawl はお客様のインフラ上でエンドツーエンドで動作しています。このベースラインを保持し、次に追加する機能を選択してください。

最初のスクレイピングは動作します。機能があるから追加するのではなく、必要になった時点で追加してください。

より広範な製品比較については、Open Source vs Cloud を参照してください。リリース固有の構成については、固定バージョンの docker-compose.yaml を参照してください。

Compose を使えば、まずは動作させるところまで到達できます。本番環境では、API を信頼されたネットワークの外部に公開する前に、いくつかの明確な判断が必要です。

• サービスの置き換え後もデータを保持する必要がある場合は、 PostgreSQL、Redis、RabbitMQ 用の永続ストレージを追加し、バックアップと復元の手順を定義してテストしてください。提供されている Compose ファイルには、これらのボリュームは含まれていません。
• ユーザーや信頼できないネットワークから API にアクセスできる場合は、 サポート対象の認証方式、ネットワークアクセス制御、リバースプロキシまたは Ingress での TLS を導入してください。この認証されていないベースラインをインターネット上に公開しないでください。
• 可用性や容量に関する要件がある場合は、 稼働率の目標、監視、リソースのサイジング、スケーリングのトリガー、アップグレードおよびロールバックの手順を設定してください。Compose の制限値は、検証済みの最小要件ではありません。
• データのロケーションやコンプライアンスが重要な場合は、 有効化する前に、対象 Web サイトへのリクエストと、任意の AI、プロキシ、解析プロバイダーをすべて対応付けてください。
• シークレットを一元管理する必要がある場合は、 データベースのパスワードを .env からプラットフォームのシークレット管理システムへ移行してください。

これらはインフラストラクチャに関する判断です。単一の .env 設定だけで、スタックが本番環境対応になるわけではありません。

• まだ評価中ですか？ API は信頼されたネットワーク内で運用し、完了したら docker compose down を実行してください。
• オープンソース機能を追加しますか？ セルフホスト環境での機能サポート で必要なプロバイダーまたはサービスを確認し、その構成を単独でテストしてください。
• Firecrawl のコードを変更しますか？ 開発環境については、コントリビューター向けセットアップ を参照してください。
• クライアントを接続しますか？ Firecrawl CLI または ローカル MCP サーバー の接続先に、検証済みの API URL を指定してください。
• Kubernetes に移行しますか？ まず SELF_HOST.md からリンクされているバージョン対応の Kubernetes または Helm リファレンスを確認し、次に上記の本番環境向けの判断をプラットフォームに合わせて明確にしてください。
• マネージドインフラストラクチャまたは Cloud 専用機能が必要ですか？ Open Source vs Cloud を確認してください。
• 本番環境に移行しますか？ API を公開する前に、本番環境に移行する前に のすべての項目を決定してください。

USE_DB_AUTHENTICATION=false でこの警告が表示される場合、想定された初回実行時の動作です。リクエストにはセルフホストのIDが使用されるため、APIキーは不要です。信頼できないネットワークからAPIにアクセスできる場合は、停止して本番環境に移行する前にの対策を追加してください。

長時間稼働するサービスが終了した場合は、コンテナの状態と直近のログを確認してください。

docker compose ps --alldocker compose logs --tail=200

• ソースのリビジョンが異なる場合は、v2.11.162 をチェックアウトするか、そのリリースの構成を使用してください。
• ビルドまたはコンテナのリソースが不足している場合は、Docker の CPU、メモリ、またはディスク容量を増やしてください。
• PostgreSQL が失敗する場合は、.env の構文を確認し、POSTGRES_DB=postgres を維持したうえで、ユーザー名とパスワードの値が一致していることを確認してください。

コンテナから Redis に接続できない場合は、Compose サービスのアドレスを redis://redis:6379 のままにしてください。localhost は Redis サービスではなく、そのコンテナ自身を指します。

docker compose ps redisdocker compose logs --tail=100 redis

REDIS_URL または REDIS_RATE_LIMIT_URL を追加した場合は、オーバーライドを削除してデフォルト設定に戻すか、Compose ネットワーク内から名前解決できるアドレスを使用してください。

ポート 3002 が応答しない場合は、API コンテナとそのログを確認してください。

docker compose ps apidocker compose logs --tail=200 api

別のプロセスがポート 3002 を使用している場合は、そのプロセスを停止するか、公開ポートを適宜変更してください。初回起動時は、API コンテナが実行中になったことを確認してから再試行してください。

/v0/health/readiness が成功しても /v2/scrape が失敗する場合は、到達可能性エンドポイントではこれらの依存関係を検証しないため、API と Playwright のログを確認してください。

docker compose logs --tail=200 api playwright-service

スクレイピングがタイムアウトする場合は、デプロイ環境から https://example.com にアクセスできること、および API と Playwright サービスが稼働していることを確認してください。API が独自のタイムアウトレスポンスを返せるよう、curl の --max-time はリクエストボディの timeout より長く設定してください。