If you’re a homelab purist like me, you probably care a lot about self-hosting being actually self-hosted. That means no surprise external fetches, no hidden dependencies on third-party CDNs, and no weird packaging choices that undermine the whole point of running software on your own machine.

That said, I get it: other people’s priorities may be different. Some users care more about convenience or commercial support. But if you care about clean self-hosting, StirlingPDF is the better choice.

BentoPDF’s default Docker build depends on runtime CDN fetches

This is the biggest problem.

BentoPDF’s default Docker build downloads assets at runtime from a CDN instead of shipping a fully self-contained image. In my opinion, that is a fundamental self-hosting anti-pattern.

Why?

Privacy

A self-hosted app should not be phoning home to fetch basic runtime assets. If it does, then your deployment is no longer fully isolated. Even if the transferred files are “just assets,” the external request still reveals that your instance exists and that it is being used, your IP address, perhaps even more than that depending on the rest of your setup and your ISPs and the CDNs tracking capabilities.

Performance

Runtime CDN fetching makes startup slower and adds unnecessary failure points:

• first-run delays
• dependency on external availability
• more brittle deployments
• poor behavior in restricted or offline environments

A container should be ready to run. It should not need to reach out to the internet just to become functional.

Security

Every external dependency is another trust boundary. If your app fetches critical assets at runtime, then:

• the build is less reproducible
• the runtime path is harder to audit
• the supply chain becomes less controlled

For a self-hosted tool, that is a serious compromise. Just think about all the recent supply chain attacks we've had and then imagine how much worse it could get.

Why BentoPDF does this

The reason appears to be licensing, according to the answer to this discussion.

According to the project’s own discussion, BentoPDF loads some modules from a CDN because of commercial dual-licensing and AGPL distribution concerns. In other words, the commercial version is not allowed to distribute the AGPL-licensed assets directly, so the project offloads them to runtime fetching instead.

That may solve a business problem, but it creates a worse experience for self-hosters:

• the AGPL self-hosted build is artificially limited
• the “real” assets are not bundled normally
• the whole distribution model becomes more about legal separation than user freedom

So yes, this looks like BentoPDF is trying to stay on the right side of the AGPL while still making the self-hosted build less complete than it should be.

The air-gap fix exists, but it is clunky

BentoPDF does provide a script for self-hosted or air-gapped installs:

But it is not a particularly elegant solution. The script feels awkwardly assembled:

• it generates another script by echoing it to a file, instead of just copying it
• it carries around loose files instead of producing a container image or at least a self-contained ZIP/TAR
• it is not the default path for the AGPL version, which is hard to justify

If the project truly cared about self-hosting, the air-gapped flow would be the primary path, not a side quest.

The self-hosted version still pushes the commercial product

This part is honestly where I stopped trying to improve BentoPDF and instead just started looking for alternatives.

The self-hosted version includes explicit links to the commercial BentoPDF offering. The issue is not that self-hosted software has marketing -- that is normal. The issue is that a page intended for self-hosting still links directly to the commercial version, which can also be read as a deliberate SEO boost for the paid product.

That distinction matters. It is one thing to mention a commercial tier. It is another to build links into the self-hosted distribution in a way that helps the commercial page rank better.

This Dockerfile comment is where I read about it.

And the README reinforces how the project is presented publicly.

StirlingPDF

StirlingPDF is another option if your goal is to host the software yourself without weird CDN dependencies or licensing gymnastics.

It is available as an open-source, self-hostable PDF platform designed to run on your own infrastructure, and its messaging is much more aligned with actual self-hosting expectations.

In practice, that means:

• no awkward runtime asset fetching for basic functionality
• a clearer self-hosting story
• fewer compromises that get in the way of the user

By default it unfortunately seems to collect telemetry in a self-hosted installation. Many people have argued the pros and cons for this, but the good news is it's super easy to disable it.

Overall it's a more fully-featured PDF editor and not just a collection of tools like BentoPDF. That has upsides, like the ones mentioned above in addition to easier editing of PDFs across multiple tools. But it also has downsides, clocking in at 1GB of disk space for the Docker image and 4GB of RAM as a recommendation. If you're short on those, you can also give the ultralite version a chance, specifically built for those with less capable hardware.

I’m not saying BentoPDF has no value

To be fair, BentoPDF clearly has people who like it. There are users who care more about feature velocity, client-side processing, or smaller deployments. And if that is your priority, you may feel differently.

But if you care about self-hosting in the strict sense -- privacy, reproducibility, portability, and no unnecessary third-party dependencies -- then BentoPDF’s CDN behavior is a deal-breaker.

Conclusion

BentoPDF’s default Docker setup depends on runtime CDN fetches, its self-hosted packaging is clunky, and its self-hosted distribution still nudges users toward the commercial product.

That is exactly the kind of thing I try to avoid in a homelab.

So yes: I switched from BentoPDF to StirlingPDF, and you probably should too.

References

• BentoPDF Dockerfile: https://github.com/alam00000/bentopdf/blob/main/Dockerfile#L68
• BentoPDF air-gap script: https://github.com/alam00000/bentopdf/blob/main/scripts/prepare-airgap.sh
• BentoPDF discussion on CDN/licensing: https://github.com/alam00000/bentopdf/discussions/449
• BentoPDF README: https://github.com/alam00000/bentopdf/blob/main/README.md
• StirlingPDF GitHub: https://github.com/Stirling-Tools/Stirling-PDF