v2.11.162 を固定し、http://localhost:3002 で API を起動して、Markdown を含む POST /v2/scrape の正常なレスポンスを確認します。
セルフホスティングまたは Firecrawl Cloud を選択
次の場合は Firecrawl をセルフホストしてください
- ソースコードやインフラを自分で管理したい場合。 このガイドでは、API とその関連サービスをお使いのマシンで実行します。
- スタックの運用に慣れている場合。 アップグレード、セキュリティ、ストレージ、監視、復旧はお客様の責任となります。
- Firecrawl を自社環境で検証したい場合。 まずここでベースラインを動作させ、その後 本番環境に移行する前に で必要な管理策を設計してください。
セルフホスティングで必要となること
- アップグレード、シークレット、ストレージ、監視、復旧、インシデント対応はすべてご自身で担います。
- スクレイピングでは、対象 Web サイトへのアウトバウンドリクエストが引き続き送信されます。任意のプロキシ、解析、AI プロバイダーを追加すると、データフローも増えます。
- このガイドでは、最初の実行を意図的にシンプルにしています。まず 1 回のスクレイピングを動作させ、その後は一度に 1 つの設定を変更してください。
- コマンドは
v2.11.162に固定されています。別のリリースでは、異なる Compose コントラクトが使用される場合があります。
Docker Compose で Firecrawl をセルフホストする
まずは以下のデフォルトで始める
- リリース: Firecrawl
v2.11.162。 まずコードと構成を固定します。対象リリースのdocker-compose.yamlとセルフホスティングに関する注意事項を確認してからアップグレードしてください。 - API 認証: このローカル実行では無効。 サポート対象の完全な ID 管理とデータベース設計を用意できる場合にのみ追加してください。環境変数 1 つだけでは不十分です。
- キュー: PostgreSQL。 任意の FoundationDB バックエンドを意図して運用する場合を除き、そのまま使用してください。
- キュー管理 UI: 無効。 強力な
BULL_AUTH_KEYとネットワーク制御を設定できる場合にのみ有効にしてください。 - AI および高度なスクレイピングプロバイダー: 未構成。 必要な機能で求められる場合にプロバイダーを追加してください。
前提条件
- Git
- Docker Engine または Docker Desktop
docker composeとして実行する Docker Compose v2- 確認リクエストに使用する
curl
3002 が使用可能であり、Docker が複数のサービスをビルド・実行できる十分なリソースを備えていることを確認してください。Firecrawl は、このスタックに必要な最小ホスト要件を検証・公開していません。
検証済みのリリースをクローンする
v2.11.162 で検証されています。コード、コマンド、構成の整合性を保つため、該当するリリースをチェックアウトしてください。
docker-compose.yaml とセルフホスティングに関する注意事項を確認してください。
評価環境のデプロイを設定する
.env ファイルを作成します。
.envはコミットしないでください。バンドルされているpg_cronの構成がそのデータベースを対象としているため、v2.11.162ではPOSTGRES_DB=postgresのままにしてください。Composeはこれらの値をAPIサービスとPostgreSQLサービスの両方に渡します。
apps/api/.env.exampleはAPI開発用であり、Composeファイルとしてそのまま使用するものではありません。
初回の実行ではデータベース認証が無効になるため、リクエストに
APIキーやAuthorizationヘッダーは必要ありません。NUQ_BACKENDとBULL_AUTH_KEYは未設定のままにしてください。キュー管理UIを起動せずにPostgreSQLキューを使用します。初回のスクレイピングでは、構成要素を減らせます。
Firecrawl をビルドして起動する
docker compose ps --all では、API と関連サービスが実行中で、1 回限りの初期化サービスが完了していることを確認できます。サービスがまだ起動中の場合は、スタックが立ち上がるまで少し待ってください。
API に到達できることを確認する
機能スモークテストを実行する
セルフホスト環境での機能サポート
より広範な製品比較については、Open Source vs Cloud を参照してください。リリース固有の構成については、固定バージョンの
docker-compose.yaml を参照してください。
本番環境に移行する前に
- サービスの置き換え後もデータを保持する必要がある場合は、 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 コンテナが起動しない
- ソースのリビジョンが異なる場合は、
v2.11.162をチェックアウトするか、そのリリースの構成を使用してください。 - ビルドまたはコンテナのリソースが不足している場合は、Docker の CPU、メモリ、またはディスク容量を増やしてください。
- PostgreSQL が失敗する場合は、
.envの構文を確認し、POSTGRES_DB=postgresを維持したうえで、ユーザー名とパスワードの値が一致していることを確認してください。
Redis への接続に関する問題
redis://redis:6379 のままにしてください。localhost は Redis サービスではなく、そのコンテナ自身を指します。
REDIS_URL または REDIS_RATE_LIMIT_URL を追加した場合は、オーバーライドを削除してデフォルト設定に戻すか、Compose ネットワーク内から名前解決できるアドレスを使用してください。
API エンドポイントが応答しない
3002 が応答しない場合は、API コンテナとそのログを確認してください。
3002 を使用している場合は、そのプロセスを停止するか、公開ポートを適宜変更してください。初回起動時は、API コンテナが実行中になったことを確認してから再試行してください。
/v0/health/readiness が成功しても /v2/scrape が失敗する場合は、到達可能性エンドポイントではこれらの依存関係を検証しないため、API と Playwright のログを確認してください。
スクレイピングリクエストがタイムアウトする
https://example.com にアクセスできること、および API と Playwright サービスが稼働していることを確認してください。API が独自のタイムアウトレスポンスを返せるよう、curl の --max-time はリクエストボディの timeout より長く設定してください。
