BuildNot yet confirmed elsewhere1 publisher2 min readPublished
wkhtmltopdf ships with an expiry date: bookworm and jammy, then nothing
The renderer was archived in January 2023 and last packaged in May 2023 for Debian 12 and Ubuntu 22.04. The bill arrives on your next base-image bump, disguised as three unrelated bugs.
The Engineer · Build desk

What happened
- wkhtmltopdf was archived in January 2023 and its repository is read-only.
- The last official packages, release 0.12.6.1-3, were built in May 2023 for Debian 12 (bookworm) and Ubuntu 22.04 (jammy).
- No build exists for Ubuntu noble, Debian trixie or anything newer, and none is coming.
- Three container errors, on Alpine, on libssl1.1 and on package lookup in Ubuntu 24.04 or Debian 13, all trace back to that same dead end.
Why it matters
- constraint The supported OS ladder stops two rungs down, so a routine base-image upgrade turns into renderer replacement work with no patch available.
- exposure Any pipeline rendering user-supplied HTML carries a server-side request path that will never be closed, and the blast radius is whatever the container can reach on the network.
- decision Teams choose between migrating on their own calendar or discovering the migration during an upgrade window, when the build is already red.
- cost Whoever owns the image inherits font packaging and glyph re-verification as a per-upgrade chore, not a one-off setup step.
The three failure modes in Vitalii's writeup read like three separate bugs, which is why they burn afternoons. On Alpine, the shell reports `not found` for a file `ls` can see. The kernel is refusing to load the binary's interpreter: official builds link glibc, Alpine ships musl, and `/lib64/ld-linux-x86-64.so.2` is not there [4]. A single `ldd` on the binary shows it [4]. Alpine dropped its own wkhtmltopdf package years ago and gcompat shims are a lottery with a binary this large, so the roughly 50 MB the slim base saves is the entire reason anyone is in that hole [14].
The libssl1.1 wall is a different animal, and mostly self-inflicted. The Dockerfiles in circulation fetch `wkhtmltox_0.12.6-1`, which links OpenSSL 1.1, while Debian 12 and Ubuntu 22.04 onward ship OpenSSL 3 and no longer carry libssl1.1 in the archives [5]. The final release, 0.12.6.1-3, was built against OpenSSL 3 for bookworm and jammy [6]. So the most common error is a stale version string in a copied recipe rather than the archival itself [12]. That release also ships amd64 and arm64 for both distros, which is why `dpkg --print-architecture` in the download URL is enough to cover both [7].
What no recipe fixes is the ceiling. Upstream packaging outlived the read-only repository by about four months [13], and the newest targets it ever produced are Debian 12 and Ubuntu 22.04 [11]. Those debs may keep installing on newer bases for as long as the dependency chain happens to line up, and the author's read is that every base-image bump from here is a gamble against a binary from 2023 [17].
Two recurring costs sit underneath. Fonts: the image arrives with almost none, wkhtmltopdf resolves them through fontconfig, and missing glyphs render as tofu, so any non-Latin text needs re-checking after each base change [8]. Security: CVE-2022-35583, an SSRF through rendered content, is permanently unfixed, which is why the guide says to keep untrusted HTML away from it and run the container with no metadata endpoint access and restricted egress [9].
The exits are listed by someone who sells one of them. Vitalii discloses that he founded PDFik, a hosted URL and HTML-to-PDF API [16], and still puts headless Chromium (Puppeteer or Playwright's `page.pdf()`, or Gotenberg as a ready-made sidecar) and WeasyPrint for print-CSS documents that run no JavaScript ahead of the hosted category [15]. The ordering is the useful part: the options that cost nothing come first, and the pitch is narrowed to teams whose actual lock-in is the CLI flags, which PDFik's compatibility mode accepts [16].
What to watch
- Whether anyone outside the archived project ships patched builds for trixie or noble; nothing in the source suggests one is coming.
- Whether the bookworm and jammy debs still resolve their dependencies on the next Debian or Ubuntu base you try, since that is all that keeps existing pipelines alive.
- Whether PDFik's wkhtmltopdf-compatible CLI mode actually swallows the flag sets buried in existing wrapper scripts.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence62
- Adoption41
- Hype gap+12
- Incentives78
- Confidence58
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
The wkhtmltopdf project was archived in January 2023 and its repository is read-only.
- [2]
The last official wkhtmltopdf packages were built in May 2023, release 0.12.6.1-3, whose newest targets are Debian 12 (bookworm) and Ubuntu 22.04 (jammy).
- [3]
Container users commonly hit one of three errors: 'not found' for the binary on Alpine, 'wkhtmltox : Depends: libssl1.1 but it is not installable', and 'E: Unable to locate package wkhtmltopdf' on Ubuntu 24.04 / Debian 13; all three share the same root cause.
- [4]
On Alpine the 'not found' message comes from the kernel failing to load the binary's interpreter: official wkhtmltopdf builds link glibc, Alpine ships musl, and the referenced dynamic loader /lib64/ld-linux-x86-64.so.2 does not exist; ldd on the binary shows it immediately.
- [5]
Widely-copied Dockerfiles fetch wkhtmltox_0.12.6-1 debs, which link OpenSSL 1.1, while Debian 12, Ubuntu 22.04 and later ship OpenSSL 3 and removed libssl1.1 from the archives, making the dependency unresolvable.
- [6]
The fix is the last release, 0.12.6.1-3, which was built against OpenSSL 3 for bookworm and jammy.
- [7]
Release 0.12.6.1-3 ships amd64 and arm64 builds for both bookworm and jammy, so using dpkg --print-architecture keeps one Dockerfile working on both architectures.
- [8]
The base image has almost no fonts, wkhtmltopdf resolves fonts via fontconfig, missing glyphs render as tofu, and non-Latin text should be re-checked after every base-image change.
- [9]
CVE-2022-35583, an SSRF through rendered content, is permanently unfixed; the guide advises never feeding wkhtmltopdf untrusted HTML and treating the container as hostile, with no metadata endpoint access and restricted egress.
- [10]
There is no wkhtmltopdf build for noble, trixie or anything newer, and there never will be.
- [11]
Debian 12 and Ubuntu 22.04 are the last base images with any upstream wkhtmltopdf package, so any newer Debian or Ubuntu release has no supported build.
- [12]
The libssl1.1 failure is caused by pinning the older 0.12.6-1 deb rather than by the project's archival, because the final 0.12.6.1-3 release links OpenSSL 3.
- [13]
Packaging continued roughly four months after the repository went read-only.
- [14]
Alpine dropped its wkhtmltopdf package years ago with nothing in current stable, gcompat shims are unreliable with a binary this large, and the saving being chased is about 50 MB of image size.
- [15]
The recommended replacements are headless Chromium via Puppeteer or Playwright page.pdf() or Gotenberg as a sidecar container, WeasyPrint for print-CSS documents that do not run JavaScript, and a hosted rendering API.
- [16]
The author discloses he is Vitalii, founder of PDFik, a hosted URL/HTML-to-PDF API, and says the PDFik CLI has a compatibility mode that accepts wkhtmltopdf's own command line.
- [17]
The bookworm and jammy debs may keep installing on newer bases for a while if the dependency chain happens to align, but the author's position is that every base-image bump is now a gamble against a binary from 2023 and the signal to plan migration.
ReportedInsufficientSource: Vitalii, PDFik2 sources— create a free account to open themView cited source
Sources
1 independent publisher whose own reporting we read for this story.
- dev.towkhtmltopdf in Docker in 2026: musl, libssl1.1, and the ways out
1 article · August 27, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.