Firecrawl Docker 셀프 호스팅: 설치·검증·비용 가이드

Firecrawl Docker 셀프 호스팅, 이 규모에서는 Cloud가 더 저렴합니다

소스 접근권, 인프라 통제권 또는 필수 네트워크 경계가 스택 운영 부담보다 중요할 때 Firecrawl을 셀프 호스팅하십시오. 목적이 공개 URL을 깔끔한 콘텐츠로 바꾸는 것뿐이라면 Cloud가 적합합니다. Firecrawl도 셀프 호스팅 가이드에서 같은 결론을 제시합니다. Cloud는 프로덕션으로 가는 가장 빠른 공식 지원 경로이며, 셀프 호스팅을 선택하면 팀이 시스템 운영을 책임져야 합니다.

셀프 호스팅 수치는 예산일 뿐, 처리량 보장이 아닙니다. Firecrawl은 검증된 최소 호스트 사양을 공개하지 않으며, 이 실행에서는 해당 머신이 두 처리량 중 어느 쪽을 감당하는지도 테스트하지 못했습니다. 추가 비용을 감수할 타당한 이유는 통제권입니다. 비용 절감 여부는 실제 페이지, 동시 처리량, 실패율을 기준으로 입증해야 합니다.

Firecrawl 자체 호스팅으로 실제 얻는 것

통제하는 인프라 위에서 핵심 Firecrawl 엔진을 사용할 수 있지만, 주변의 모든 의존성을 운영하는 일도 함께 떠안게 됩니다. Cloud가 인력을 갖춘 상업용 주방이라면 셀프 호스팅은 주방 설계도를 받는 것과 같습니다. 설계도는 유용하고, 내부를 살펴볼 수 있으며, 필요에 맞게 바꿀 수 있습니다. 하지만 요리사, 소방 점검, 냉장 설비 확인, 야간 근무 인력까지 제공하지는 않습니다.

버전을 고정한 기본 스택은 핵심 scrape, crawl, map, search 라우트를 지원합니다. Fetch와 Playwright 처리도 포함됩니다. 이 스택은 PostgreSQL, Redis, RabbitMQ 같은 서비스에도 의존하며, readiness 엔드포인트는 전체 처리 경로가 정상인지 검증하지 않습니다.

이 경계는 중요합니다. {"status":"ok"}는 HTTP 엔드포인트 하나가 응답했다는 뜻일 뿐입니다. 페이지 요청이 호스트 밖으로 나가 렌더링되고, 워커를 거쳐 Markdown으로 돌아오는 과정까지 입증하지는 못합니다. 실제 스크래핑 성공이 최소한의 유효한 증거입니다.

가이드 기준 릴리스로 Firecrawl 설치하기

계속 바뀌는 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개, 재시작 출력, 재시작 뒤 성공한 두 번째 스크래핑이 저장됩니다.

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 비교에서 더 넓은 공급자 시장을 확인할 수 있습니다. 대체 스크래퍼 선정은 별도의 구매 결정입니다.

Firecrawl 셀프 호스팅의 효과가 가장 큰 팀

이미 플랫폼 조직이 있고 통제 요구 사항이 분명한 팀에 가장 적합합니다. 소규모 처리량에서는 페이지당 비용이 낮다는 이유만으로 충분하지 않습니다.

적합하지 않은 경우도 분명합니다. 안정적인 스크래핑 엔드포인트 하나가 필요한 2인 제품 팀이라면 불필요한 운영 프로젝트를 구매하는 셈입니다. Agent, Browser, Interact, 스크린샷, 페이지 액션 또는 관리형 고급 스크래핑에 의존하는 팀도 기능 경계의 잘못된 쪽에서 시작하게 됩니다.

30일 비용 계산: 통제권에도 분명한 청구서가 따릅니다

명시적이고 보수적인 가정을 적용하면 기본 페이지 1,000개와 10,000개 모두 관리형 Firecrawl이 더 저렴합니다. 셀프 호스팅 예산은 vCPU 8개, RAM 16 GiB, SSD 320 GiB인 월 $96의 DigitalOcean Basic Droplet에 100 GiB 영구 Volume $10, 주간 백업 비용 $19.20을 더했습니다. DigitalOcean이 2026년 9월 22일에 제시한 가격입니다.

16 GiB는 공식 최소 사양이 아닙니다. 버전을 고정한 Compose 파일에서 API 서비스의 상한이 8 GiB, Playwright의 상한이 4 GiB이고 데이터베이스, 캐시, 큐, 기타 프로세스에도 여유가 필요하다는 점을 반영한 예산 가정입니다. 호스트 사양은 워크로드 테스트를 거쳐야만 정할 수 있습니다.

더 큰 비용 항목은 운영자 시간입니다. 이 워크시트는 첫 30일 동안 설정 4시간과 유지 관리 2시간, 시간당 완전원가 $100를 가정합니다. 이는 시장 단가가 아니라 가정입니다. 실제 수치로 바꿔 입력하십시오.

Firecrawl Cloud에서는 기본 페이지 1개를 스크래핑할 때 크레딧 1개가 차감됩니다. Free 플랜은 $0에 크레딧 1,000개를 제공합니다. 월 단위 결제에서 페이지 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 자체와 경쟁하지 않으면서 모호한 설치 상태를 증거로 바꿔주기 때문입니다. 한 번의 실시간 검색 스냅샷에서 연관 검색어 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는 지원하는 클라우드 대상 하나, 버전 고정 인프라 코드, 알림, 복구 훈련으로 구성됩니다. 문제는 책임 소재입니다. 재사용 가능한 모듈이 고객의 보안이나 규정 준수 상태를 인증할 수는 없습니다.

한계와 솔직한 결론

운영 업무를 측정하기도 전에 $19를 아끼겠다는 이유로 Firecrawl을 셀프 호스팅하지 마십시오. 기본 구성은 API 인증을 끄고, TLS를 제공하지 않으며, PostgreSQL, Redis, RabbitMQ의 영구 스토리지를 추가하지 않고, 고가용성도 지원하지 않습니다. 이를 신뢰할 수 없는 네트워크에 노출하면 평가 편의를 위한 설정이 보안 실수로 바뀝니다.

기본 스택이 Cloud와 기능 면에서 완전히 같다고 가정해서도 안 됩니다. LLM 포맷에는 제공자가 필요합니다. Fire-engine은 별도입니다. 기본 경로에서는 스크린샷과 액션을 사용할 수 없습니다. Agent, Browser, Interact, 대시보드, 엔터프라이즈 제어는 Cloud 기능으로 남거나 별도로 검증된 서비스가 필요합니다.

Compose 제한값이나 이 워크시트만 보고 프로덕션 규모를 정하지 마십시오. 메모리 상한은 권장 호스트 사양이 아닙니다. 고정 픽스처를 실행하고 실제 워크로드를 대표하는 페이지를 추가해 동시 처리량과 실패 유형을 측정한 뒤, 백업 복원과 업그레이드 롤백도 테스트해야 합니다.

진행해야 할 가장 강력한 이유는 Cloud가 충족할 수 없는 팀의 통제 요구 사항입니다. 가장 약한 이유는 "무료"라는 단어입니다.

월요일에 바로 할 일

엔지니어 한 명에게 폐기 가능한 비공개 호스트에서 2시간의 평가 시간을 주십시오. v2.11.162를 고정하고, 공식 단일 스크래핑을 실행한 다음, 저장형 검증 스크립트를 돌리고, 재시작 뒤 스크래핑이 통과하지 않으면 중단합니다. 이어서 워크시트의 운영자 단가 $100를 실제 완전원가로 바꾸고 통제 요구 사항을 한 문장으로 적습니다. 그 문장이 모호하면 Cloud를 사용하십시오. 구체적이라면 처리량을 늘리기 전에 프로덕션 제어를 설계하십시오.

통제 요구 사항에 맞춰 버전을 고정하고 관측 가능하게 구성한 배포가 필요하다면 AI 프로덕션 시스템을 확인하십시오.