Firecrawl Self-Hosted

📅 Juni 2026 · Letztes Update: 07.06.2026

1. Warum Firecrawl selbst hosten?

Firecrawl ist eine Web-Scraping-Engine, die Webseiten crawled, sauberes Markdown extrahiert und strukturierte Daten für KI-Anwendungen liefert. Die Cloud-Version (api.firecrawl.dev) ist komfortabel — aber sie kostet pro Request und schickt alle Daten über externe Server.

Für Projekte mit hohem Crawling-Volumen oder Datenschutz-Anforderungen lohnt sich das Self-Hosting:

• Keine API-Kosten: Nur Server-Kosten, kein Pay-per-Request
• Datensouveränität: Alle gecrawlten Inhalte bleiben auf eigener Hardware
• Keine Rate-Limits: Crawling-Geschwindigkeit selbst bestimmt
• Agent-Integration: Direkter API-Zugriff aus eigenen KI-Agenten ohne Authentifizierung
• DSGVO-konform: Keine Datenweitergabe an Dritte

2. Anforderungen

• Docker: Alle Services laufen containerisiert
• RAM: ca. 2–3 GB für den gesamten Stack (Playwright ist der größte Verbraucher)
• Disk: ~5 GB für Images + Daten
• Netzwerk: Ausgehender Internet-Zugang zum Crawlen
• Optional: OpenAI-API-Key für KI-gestützte Extraktion (JSON-Format, /extract-Endpoint)

3. Architektur & Services

Der Self-Hosted-Stack besteht aus fünf Docker-Containern, die über ein internes Bridge-Netzwerk kommunizieren:

4. Setup: Docker Compose

4.1 Repository klonen

git clone https://github.com/firecrawl/firecrawl.git
cd firecrawl

4.2 .env konfigurieren

Die minimale Konfiguration für den Self-Hosted-Betrieb:

# ===== Required =====
PORT=3002
HOST=0.0.0.0

# ===== AI Features (optional) =====
# OPENAI_API_KEY=...       # Für JSON-Extraktion
# OPENAI_BASE_URL=...      # OpenAI-kompatible API

# ===== Queue Admin UI =====
BULL_AUTH_KEY=dein-sicheres-passwort

# ===== PostgreSQL =====
POSTGRES_USER=postgres
POSTGRES_PASSWORD=dein-db-passwort
POSTGRES_DB=postgres

# ===== Performance =====
CRAWL_CONCURRENT_REQUESTS=10
NUM_WORKERS_PER_QUEUE=8
BROWSER_POOL_SIZE=5

4.3 docker-compose.yaml (Kernstruktur)

Die offizielle Compose-Datei definiert die fünf Services. Die wichtigsten Ausschnitte:

# docker-compose.yaml (Auszug)
services:
  api:
    build: apps/api
    restart: unless-stopped
    ports:
      - "${PORT:-3002}:${INTERNAL_PORT:-3002}"
    environment:
      REDIS_URL: redis://redis:6379
      REDIS_RATE_LIMIT_URL: redis://redis:6379
      PLAYWRIGHT_MICROSERVICE_URL: http://playwright-service:3000/scrape
      NUQ_RABBITMQ_URL: amqp://rabbitmq:5672
      ENV: local
    depends_on:
      - redis
      - playwright-service
      rabbitmq:
        condition: service_healthy
    cpus: 4.0
    mem_limit: 8G

  playwright-service:
    build: apps/playwright-service-ts
    restart: unless-stopped
    cpus: 2.0
    mem_limit: 4G

  redis:
    image: redis:alpine
    restart: unless-stopped

  rabbitmq:
    image: rabbitmq:3-management
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "rabbitmq-diagnostics", "-q", "check_running"]
      interval: 5s

  nuq-postgres:
    build: apps/nuq-postgres
    restart: unless-stopped

4.4 Build & Start

# Images bauen (beim ersten Mal, dauert einige Minuten)
docker compose build

# Stack starten
docker compose up -d

# Prüfen ob alles läuft
docker compose ps
# Erwartet: 5 Container mit Status "Up"

4.5 Test ob die API funktioniert

# Einfacher Scrape-Test
curl -s http://localhost:3002/v1/scrape \
  -H 'Content-Type: application/json' \
  -d '{"url": "https://example.com"}' | python3 -m json.tool

# Crawl-Test (folgt allen Links auf einer Seite)
curl -X POST http://localhost:3002/v1/crawl \
  -H 'Content-Type: application/json' \
  -d '{"url": "https://firecrawl.dev"}'

5. API & Integration

5.1 Wichtigste Endpoints

5.2 Agent-Integration

In meiner eigenen Umgebung wird die Firecrawl-Instanz direkt von KI-Agenten genutzt — für tägliche News-Recherche, Blog-Recherche und Web-Scraping. Da die API lokal läuft, ist keine Authentifizierung nötig:

# Direkter API-Call von einem Agenten
# Kein API-Key, kein Account — die Instanz ist im lokalen Netzwerk
response = requests.post(
    "http://localhost:3002/v1/scrape",
    json={
        "url": "https://blog.example.com/article",
        "formats": ["markdown"]
    }
)
markdown_content = response.json()["data"]["markdown"]

# Das Markdown kann direkt in LLM-Kontexte (RAG) fließen
llm_context = f"Webseiten-Inhalt:\n{markdown_content}"

5.3 Crawl-Parameter (wichtigste)

{
  "url": "https://zielseite.de",
  "limit": 50,           // Max. Seiten pro Crawl
  "maxDepth": 3,         // Kriechtiefe
  "includePaths": ["/blog/*", "/docs/*"],
  "excludePaths": ["/admin/*"],
  "scrapeOptions": {
    "formats": ["markdown"],
    "onlyMainContent": true,
    "waitFor": 2000      // ms auf JS-Rendering warten
  }
}

6. Betrieb & Lessons Learned

Was gut läuft

• Docker Compose ist narrensicher: docker compose up -d und 5 Container starten. restart: unless-stopped sorgt dafür, dass nach Server-Reboots alles automatisch wieder hochkommt.
• Markdown-Output ist Gold wert: Im Gegensatz zu rohem HTML kann das Markdown direkt in KI-Pipelines verwendet werden — ohne Nachbearbeitung.
• Playwright-Service ist isoliert: Der Browser läuft im eigenen Container mit CPU-/RAM-Limits. Wenn eine Seite den Renderer crasht, ist nur der Playwright-Container betroffen, nicht die ganze API.
• RabbitMQ-Healthcheck: Der automatische Healthcheck sorgt dafür, dass der API-Container erst startet, wenn RabbitMQ bereit ist — keine Race Conditions beim Boot.

Lessons Learned

• Build dauert beim ersten Mal: Die Container werden aus Source gebaut (nicht pre-built Images). Der erste docker compose build dauert 10–15 Minuten. Danach sind inkrementelle Builds schnell.
• RAM ist der limitierende Faktor: Der Playwright-Container braucht mit 10 concurrent Pages und JavaScript-Rendering schnell 2 GB+. Auf Servern mit <4 GB RAM die CRAWL_CONCURRENT_REQUESTS auf 3–5 reduzieren.
• PostgreSQL nicht nach außen exponieren: Die Compose-Datei exponiert PostgreSQL nicht — das ist Absicht. Für DB-Zugriff: docker exec -it fc-nuq-postgres-1 psql -U postgres nutzen.
• Log-Dateien wachsen: Die Compose-Datei hat Log-Rotation konfiguriert (max 10 MB pro File, 3 Files). Ohne das würden die Logs die Platte füllen — prüfen ob die Limits zum eigenen Crawling-Volumen passen.
• Fire-Engine fehlt: Die Self-Hosted-Version hat keinen Zugriff auf Fire-Engine (IP-Block-Umgehung). Seiten mit aggressivem Bot-Schutz können mit einfachem Fetch scheitern. Playwright hilft in vielen Fällen, aber nicht immer.

Monitoring

Das Bull Queue Dashboard (http://localhost:3002/admin/{key}/queues) ist das wichtigste Monitoring-Tool. Es zeigt:

• Aktive, wartende und fehlgeschlagene Jobs
• Durchsatz pro Queue
• Fehlerdetails pro Job

Für Server-Monitoring empfiehlt sich ein Prometheus + Grafana-Stack, der CPU-, RAM- und Disk-Metriken aller fünf Container trackt.

7. Fazit & Ausblick

Firecrawl Self-Hosted ist die ideale Lösung für alle, die eine leistungsfähige Web-Crawling-Engine unter eigener Kontrolle betreiben wollen. Der initiale Setup-Aufwand ist mit Docker Compose überschaubar, der Betrieb läuft stabil, und die Integration in KI-Agenten-Pipelines ist denkbar einfach: lokaler Endpoint, kein Auth, Markdown-Output.

Für Teams und Einzelentwickler, die regelmäßig Web-Inhalte für KI-Anwendungen benötigen, ist das Self-Hosting die klare Alternative zur Cloud-API — Kostenkontrolle, Datensouveränität und keine Limits sind die drei schlagenden Argumente.