Docling mit Docker betreiben (docling-serve)

• Docker nutzen, wenn App, Pipeline oder Team Docling über HTTP (/v1/convert/source) brauchen, reproduzierbare Deployments oder Isolation vom Host-Python.
• Kein Docker für einmalige lokale Umwandlung — pip install docling plus docling convert file.pdf --to md ist schneller (siehe Installationsübersicht).
• Images sind groß (4–11 GB): Basis/CPU ca. 4,4 GB, CUDA 12.8 ca. 11,4 GB. Einmal ziehen, überall wiederverwenden.

Alle Images liegen auf quay.io/docling-project/… und ghcr.io/docling-project/… für linux/amd64 (Basis/CPU zusätzlich arm64). docker durch podman ersetzen, falls das die eigene Runtime ist. Tag-Regel: Basis/CPU-Images nutzen latest und main; CUDA-Images haben bewusst kein latest (CUDA veraltet mit PyTorch). CUDA-Images immer explizit pinnen, z. B. quay.io/docling-project/docling-serve-cu130:v1.18.0. Ein ROCm-Image existiert, wird aber nicht veröffentlicht (lokal bauen); schlanke Images ohne vorab geladene Gewichte sind geplant.

CPU (häufigste): Erster Start lädt Modellgewichte in den Image-Cache — Zeit und Platte einplanen. Für Compose-Deployments siehe docs/deployment.md. CUDA-GPU (braucht nvidia-container-toolkit / --gpus):

Derselbe Server ohne Container — nützlich auf einer VM oder zum Debuggen:

Rendert /docs, ist der Server gesund. Bei belegtem Port mit -p 5002:5001 mappen und :5002 in den URLs nutzen.

• API-Basis: http://127.0.0.1:5001
• Interaktive API-Docs (Swagger): http://127.0.0.1:5001/docs
• Playground-UI: http://127.0.0.1:5001/ui (nur mit DOCLING_SERVE_ENABLE_UI=1 / --enable-ui)
• Stabiler Umwandlungs-Endpunkt: POST /v1/convert/source (v1-API — bei altem Code die v1-Migrationshinweise lesen).

Die Antwort enthält Markdown / JSON / HTML je nach Request-Optionen. Alle Laufzeitoptionen in docs/usage.md und der REST-Referenz der docling-serve-Docs erkunden.

curl -X 'POST' \
  'http://localhost:5001/v1/convert/source' \
  -H 'accept: application/json' \
  -H 'Content-Type: application/json' \
  -d '{
    "sources": [{"kind": "http", "url": "https://arxiv.org/pdf/2501.17887"}]
  }'

• Per Env-Variablen konfigurieren (siehe .env.example und docs/configuration.md), z. B. DOCLING_SERVE_ENABLE_UI=1.
• Cache-Volume mounten, damit Modellgewichte Neustarts überleben; Speicherlimits für große PDFs setzen (siehe Speicher voll).
• Auth / TLS / Rate-Limits in einem Reverse-Proxy für Produktion; Startpunkt sind die Compose-Beispiele in docs/deployment.md.
• Image-Tags in Produktion pinnen (:v1.18.0, nicht :latest) — besonders CUDA-Tags.

• Server startet nicht — siehe docling-serve startet nicht: Portkonflikt, fehlendes [ui]-Extra oder falscher Entrypoint.
• /ui 404 — DOCLING_SERVE_ENABLE_UI=1 / --enable-ui vergessen.
• GPU-Image läuft auf CPU — Host braucht NVIDIA-Treiber + Container-Toolkit und --gpus all; drin mit nvidia-smi bestätigen.
• Pull von :latest eines CUDA-Images scheitert — erwartet: CUDA-Images tragen nur explizite Versionstags.
• Erster Request langsam — Gewichte werden geladen; Folgerequests nutzen den Cache.

Fortgeschrittenes Deployment dokumentiert das offizielle docling-serve-Projekt. Verifiziert mit Docling v2.129.0 · Zuletzt geprüft 2026-09-22 · Offizielle Quelle