Docling Studio 0.6.1 & 0.6.2: Two Audit-Driven Releases

A rebuilt workspace, a DDD-granular backend, and an image cut in half. But above all: a release process that puts auditability ahead of features.

When you maintain an open-source tool that claims to show you “what your RAG pipeline actually sees,” code quality can’t stay a marketing line. With 0.6.1 and 0.6.2, Docling Studio moves to a shipping model where every release clears a documented quality gate before it exists. Not a slogan — a scored verdict, published inside the repo.

These two versions read as a single move. 0.6.1 is the first release to ship at the end of a full 12-point audit cycle, after remediation. 0.6.2, shipped right behind it, closes the points that remained and tackles a more down-to-earth but highly visible concern for operators: Docker image size.

Here’s what changed, without the gloss.

0.6.1 — The workspace goes document-centric

The most tangible change for users is the retirement of the legacy single-page /studio editor in favor of a real per-document workspace: DocWorkspacePage. Every document now gets four dedicated tabs:

• Parse — preview, LAYERS filters, focus mode, and tree color-coding.
• Chunk — a Strategy popover for inline rechunking, with a decoupled “Generate chunks” CTA.
• Inspect — Markdown / Elements / Images.
• Compare — version comparison.

The point isn’t the tab list — it’s state isolation. Each document now keeps its own context; navigation no longer leaks bounding boxes or analysis context from one document to the next. For anyone inspecting several documents in parallel, that’s the end of a quiet source of confusion.

History with paired snapshots

Every analysis run and every rechunk now writes a frozen (analysis, chunks) snapshot. The History drawer lists them and lets you switch the active analysis on the fly, without losing intermediates. In practice: you can explore several chunking strategies and roll back without recomputing or overwriting anything.

A backend that owns its DDD granularity

On the server side, a new ChunkService exposes nine document-scoped routes under /api/documents/{id}/chunks/*. The "no UX-shaped routes" rule is now codified, and every existing /api/* route is classified in the repo's design docs. It's the kind of discipline you don't see at runtime but that determines how long a project survives.

Stores get real credentials — and sealed ones

Stores are no longer pinned to env-var-only connections. Each store row carries its own connection_uri / connection_username / connection_password, with passwords sealed at rest via Fernet (STORE_SECRET_KEY). Connection pools are now per-(uri, user) for both Neo4j and OpenSearch, and a "Test connection" button shows up in the store form. The audit's Security dimension comes back at 100/100, for what it's worth.

Ingest, flags, and the first UI tests

0.6.1 also adds a proper Ingest view (history-driven shell, pending-push badge, hierarchical document tree) and two surface flags — STUDIO_MODE_ENABLED (re-enables the legacy /studio page, kept around until its 0.7.0 rewrite) and RAG_PIPELINE_ENABLED (gates the reasoning pipeline). Both default to false in production.

Finally, the first batch of UI regression coverage lands under e2e/ui/, driven by Karate UI — not Playwright. CI runs the @critical-tagged scenarios on main.

The quality gate itself

This is the first release to ship after a full 12-point audit + remediation cycle. The initial verdict was a NO-GO: 4 critical, 11 major, score 79.12/100. After remediation, the re-audit lands on a GO: 0 critical, 3 major deferred to 0.7.0, score 90.27/100.

The per-dimension breakdown is public, and it’s honest — including where it’s merely average:

Dimension Score Clean Architecture (Hexagonal) 97/100 DDD 97/100 Clean Code 72/100 — conditional GO KISS 87.5/100 DRY 75/100 — conditional GO SOLID 100/100 Decoupling 73/100 — conditional GO Security 100/100 Tests 96/100 CI / Build 100/100 Documentation 100/100 Performance 85.7/100

On the validation side, the pipeline shipped green: 733 pytest tests on the backend, 400 vitest on the frontend, 39 Karate API e2e (12 features), Ruff + ESLint + Prettier + vue-tsc clean, a Healthy Docker Compose stack, and multi-arch images built.

0.6.2 — Audit-driven, and half the size

0.6.2 is explicitly an audit-driven release: it closes the 4 critical + 4 major items flagged by the 0.6.1 audit and the 0.6.2 release-gate audit. But its most telling highlight for operators is elsewhere.

The image is cut in half

The latest-local image drops from 6.04 GB to 3.11 GB, a -48% (-2.93 GB) cut versus 0.5.1. And a new latest-remote variant ships at 547 MB — roughly an order of magnitude smaller than 0.5.1's only published variant.

Image 0.5.1 0.6.2 Δ latest-local (Docling + models baked in) 6.04 GB 3.11 GB -2.93 GB (-48%) latest-remote (talks to docling-serve over HTTP) — 547 MB new — -91% vs 0.5.1 local

Faster pulls, less disk on the host, quicker cold starts. Where did the bytes go?

• Migration from pip to uv: a smaller resolved venv, a deterministic lockfile, and the end of "transitive bloat nobody noticed" under pip's resolver.

A big thanks to Cedric Alexander Klinkert that ship his first contribution with this feature, thanks also for his precious advices on python and product strategy!

• Explicit CPU-only torch via [tool.uv.sources]: ~3 GB of useless CUDA wheels that used to ride along in latest-local are gone.
• Reasoning made opt-in: docling-agent, mellea, and the transitive weight of their LLM SDK move out of the default image.
• **BAKE_MODELS opt-in for non-release builds**: only the release.yml build bakes the Docling checkpoint (~1.3 GB); the remote variant carries none.
• Hardened .dockerignore: a leaner build context, less layer churn on every rebuild.

A docling-serve container for remote mode

0.6.2 adds a docling-serve service under the remote compose profile, pinned to quay.io/docling-project/docling-serve-cpu:v1.21.0. Paired with CONVERSION_MODE=remote, the backend stays slim and delegates conversion to a Docling Serve container over HTTP — zero HuggingFace Hub dependency on the build or runtime path. The new huggingface-dependency-map.md documents every HF call site in the project and the single sanctioned touch point.

What breaks — and owns it

Three breaking changes to know before upgrading, all stemming from the same cleanup work:

1. Dev workflow migrated to uv. The requirements*.txt files are gone; pip install -r ... no longer works. Use uv sync (--group dev for tests, --group local for local Docling).
2. Reasoning made opt-in. Building latest-local without --build-arg WITH_REASONING=true produces an image where /api/reasoning responds 503 (graceful degrade).
3. **BAKE_MODELS default flips from true to false in both Dockerfiles. Operators who build their own local image from source and rely on the "instant first /api/convert" behaviour must now pass --build-arg BAKE_MODELS=true explicitly. The published GHCR image is unaffected**: release.yml opts in, so the documented path (pulling the image) keeps working as before.

Also worth noting on the fixes side: the remote-mode bounding-box overlay — a code path the 0.6.1 patch had missed — is now fixed for good.

Install and upgrade

Docker remains the recommended path. Images are tagged three ways for pinning flexibility:

# Remote variant (slim, delegates to docling-serve)
docker pull ghcr.io/scub-france/docling-studio:0.6.2-remote   # or 0.6-remote / latest-remote

# Local variant (Docling + models baked in)
docker pull ghcr.io/scub-france/docling-studio:0.6.2-local    # or 0.6-local / latest-local

If you’re coming from 0.6.0 or older, read the Breaking Changes section before restarting the stack — in particular:

• STORE_SECRET_KEY is required as soon as you have stores with sealed passwords (otherwise the boot fails).
• STUDIO_MODE_ENABLED and RAG_PIPELINE_ENABLED now default to false: re-enable them explicitly if you rely on them.
• The response field of POST /api/documents/{id}/chunks/push changes from jobId to pushId, and three i18n keys are renamed.
• There is no auto-migration from a 0.5.x schema: re-import into a fresh database, or hand-roll the catch-up DDL.

Why this cycle matters

The real message of these two releases isn’t any single feature. It’s the method. A 12-point audit that returns a scored GO/NO-GO verdict, reports published in the repo, breaking changes documented instead of hidden, and an image that slims down because someone looked hard at what it was carrying for nothing.

For a tool whose whole promise is transparency — seeing what your ingestion pipeline sees — applying the same auditability standard to the code that produces it isn’t a luxury. It’s the minimum for consistency.

The three remaining major items are already pointed at 0.7.0, which is set to rewrite the /studio page among other things. The next step builds in the same frame.

Links

• Release 0.6.1: github.com/scub-france/docling-Studio/releases/tag/v0.6.1
• Release 0.6.2: github.com/scub-france/docling-Studio/releases/tag/v0.6.2
• Repo: github.com/scub-france/docling-Studio

I’m CTO at SCUB, a French digital services company, and AI Ambassador for the French Ministry of Economy (“Osez l’IA”). I design production AI systems, contribute to open-source tooling around document AI, and write about the intersection of architecture and AI-assisted development. Docling Studio is built at SCUB.

Thanks for reading. If this was useful, a 👏 helps others find it. Comments and contributions welcome.