Loading today’s stories
Build1 distinct publisher2 min readPublished
A catalogue of 15 self-hosting anti-patterns puts nearly every failure outside the application: default heap sizing, the wrong image variant, a 60-second proxy, OCR with no language pack.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Two ceilings sit inside each other, and only one of them appears in your compose file. The recommendation for a merge-and-split homelab box is the ultra-lite image behind a hard 1 GB container limit [12]. A container-aware JVM with no `-Xmx` set claims a quarter of the RAM it can see [3], which leaves a 256 MB heap [19] inside the gigabyte you thought you were buying. That produces the failure the dev.to write-up says operators skip past, because from outside nothing looks broken: a `java.lang.OutOfMemoryError` stack trace in the log, the web UI still answering, and exactly one job dead [7].
The two-command triage is worth running before touching any configuration, because the exit code separates the host kill from the in-process heap error [10], and either `OOMKilled: true` or a `dmesg` line confirms the first [11]. Neither command says anything about the other two cases, which is the reason three unrelated problems keep arriving under one bug report.
OCR is where the batching advice turns into arithmetic. The scan-hoarder profile in the source is 40,000 pages, the full image, a real tessdata volume with the languages mounted, and batches of 50 pages or fewer [13]. That is 800 submissions [20]. Since cost tracks page count and DPI rather than file count [13], consolidating the scans into fewer PDFs beforehand buys nothing at all.
Office conversion punishes the purchase most operators reach for first. Conversions serialise through a single background LibreOffice process, so effective concurrency is one no matter how many cores you add, and the ordering the source gives is proxy timeout first, CPU later [15]. Every job also writes scratch files to disk before it returns a single byte [5], which is how a working instance fills a volume nobody sized [c5b].
Then there is the variant trap, which costs nothing in memory and still breaks the job: choose a lighter image, then call a tool that image does not contain [18]. Nothing in the heap, the proxy or the cgroup explains that one, and no ceiling you set protects you from it.
Ranked by verification strength, evidence, and original report placement.
Stirling-PDF is described as a stable application: almost every crash, hang and quietly mangled output traces to one of fifteen decisions made outside the app, such as an unbounded container, the wrong image variant, a reverse proxy that gives up after 60 seconds, or an OCR call with no language pack behind it.
A container-aware JVM with no -Xmx set claims a maximum heap of 25 percent of visible RAM.
Every Stirling-PDF job writes scratch files to disk before it returns a single byte.
Where Stirling-PDF writes its temporary files is why it fills the operator's disk.
A java.lang.OutOfMemoryError: Java heap space stack trace with the container still running means the JVM hit its own heap ceiling while the container still had free memory; the web UI usually stays reachable and only that one job fails. The source calls this the fix nobody applies, because the container looks healthy.
Follow any of these and your For You feed starts watching them — no settings page required.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Single unmeasured practitioner account on verifiable platform defaults
All claims come from one dev.to article by one author. Its load-bearing mechanisms are checkable platform behaviour (Docker sets no default container memory limit; a container-aware JVM without -Xmx targets 25 percent of visible memory) and the 1 GB to ~256 MB arithmetic follows directly. But no Stirling-PDF version or image digest is pinned, no logs, timings, docker stats output or benchmarks are shown, and the supplied body is truncated before most of the fifteen anti-patterns are explained, so the app-internal claims and the workload thresholds are assertion only.
No adoption evidence supplied
The cluster contains no release, deployment, benchmark, pricing, licensing or usage-disclosure event. The article mentions published image variants in passing but supplies no dates, versions, download or install counts, and no operator reporting outcomes after applying the fixes, so adoption cannot be measured without guessing.
Deflationary framing, mildly overreaching universals
The piece pushes against hype rather than adding it: it says the application is stable and locates failures in host configuration, and its headline arithmetic (1 GB limit becoming roughly a 256 MB heap) is correct. The overstatement is scope rather than substance: 'almost every crash, hang and quietly mangled output' is attributed to exactly fifteen external decisions, and specific thresholds (a hard 1 GB limit, 50-page OCR batches, LibreOffice as the bottleneck) are stated with confidence but no measurement, versioning or corroboration.
Audience-building developer post, no disclosed commercial tie
The single source is an individually authored post on a developer publishing platform about an open-source project. It discloses no vendor relationship, sells no product, links no paid offering and recommends only free upstream images and standard tooling, which limits commercial distortion. The residual incentive is engagement-driven format: a numbered fifteen-anti-pattern listicle with profile-segmented TL;DRs and a problem-framed headline rewards breadth and confident prescription over shown measurement.
Moderate on mechanism, low on prescriptions
Confidence is split. The memory-sizing mechanism and the four-way failure-signature triage are internally coherent, specific and consistent with well-known container and JVM behaviour, so they can be relied on with light verification. The workload-specific prescriptions, the LibreOffice serialisation claim and the completeness of the fifteen-item catalogue rest on one unpinned, unmeasured account with no second publisher and no adoption evidence, so overall confidence stays below the midpoint.
build
The 680 MB database that was really a 17 GB disk: self-hosted support platforms fail at month six1 distinct publisher
product
Docker puts Verified Publisher behind a signup form, and pull data behind a plan1 distinct publisher
build
Half of Claude's watermark ships with a reference tool. Your PDF pipeline eats it.1 distinct publisher
product
Docker pipes every agent policy decision into your SIEM, and the evidence burden lands on platform teams1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 25, 2026