Your team already knows the drill: someone needs to merge a closing package, redact a client name, or OCR a scan. They hit a random "free PDF" site, upload the file, and hope it vanishes from someone else's logs. For HR packets, legal discovery, or anything with a privacy officer's name on it, that's not a workflow — it's a liability with a download button.
BentoPDF (repo name bentopdf, ~16k GitHub stars) takes a different angle than most self-hosted PDF servers: the work happens in the browser. You host a static web app (or run their Docker image), users open it on your domain, and processing runs client-side with WebAssembly — merge, split, redact, sign, compress, Office conversions, OCR, the lot. The PDF bytes are not uploaded to your backend for manipulation because there isn't a PDF backend. You're serving the toolkit, not ingesting the documents.
What it actually does
BentoPDF is a full workshop in one tab — 50+ tools grouped the way Acrobat power users think:
- Organize: merge (with bookmarks), split, reorder, rotate, booklet layout, attachments, compare two PDFs side by side
- Edit: annotate, redact, edit existing text in-place, fillable forms (including XFA), watermarks, Bates numbering, deskew scans
- Convert to PDF: images, Office (DOCX/XLSX/PPTX), OpenDocument, Markdown, email (EML/MSG), EPUB, CBZ, Visio, and more
- Convert from PDF: images, text, JSON, CSV/Excel table extraction, SVG, greyscale, OCR for searchable scans
- Secure: encrypt/decrypt, permissions, compress, repair, sign (draw, type, or upload)
There's also a visual workflow builder — chain steps (merge → compress → watermark) without writing scripts. Handy when the same boring packet goes out every Friday.
Heavy lifting uses WASM modules (PyMuPDF, Ghostscript, CoherentPDF, etc.) loaded at runtime. Out of the box those often pull from jsDelivr CDN so features work immediately; for air-gapped or compliance-heavy deploys you can self-host the WASM bundles per their docs.
BentoPDF vs Stirling-PDF (we've covered both angles)
We wrote about Stirling-PDF earlier — server-side Java, Tesseract OCR on the box, REST API for n8n. That's the right pick when you want centralized automation and you're fine with files hitting a container during processing.
BentoPDF wins when your threat model is "the file must never leave the user's session" — even your own server shouldn't see document bytes, only the static assets. Trade-off: big jobs run on the user's CPU/RAM, not a beefy VPS. No built-in server API for batch merges; workflows are browser-first. Some teams run both: BentoPDF for ad-hoc human edits, Stirling for scheduled API jobs.
Why self-host if it's client-side anyway?
You could use the public bentopdf.com site and still get local processing — so why bother?
Supply chain control. You decide which build, which version, and whether WASM comes from your CDN or an internal mirror. No surprise script changes on a third-party domain.
Internal-only access. Put it behind VPN or SSO on pdf.yourcompany.ca so contractors and staff aren't trained to visit random PDF sites.
Branding and tool policy. Simple Mode strips marketing chrome; you can disable specific tools via config if legal only wants merge/redact/sign.
Canadian hosting still matters for where the app is served from and what telemetry (if any) your build includes — even when document content stays in the browser.
Licensing — read this before you ship
BentoPDF is dual-licensed: AGPL-3.0 for open deployments where you can live with AGPL obligations, or a one-time commercial license for closed/proprietary rollouts. Several processing libraries (PyMuPDF, Ghostscript, CPDF) are AGPL and are wired via CDN/WASM — fine for many internal tools, but your counsel should bless it if you're embedding BentoPDF in a customer-facing product.
What running it takes
Easiest path: Docker with the simple self-hosted image (full toolset, no marketing landing page):
docker run -d -p 8080:8080 --name bentopdf \
ghcr.io/alam00000/bentopdf-simple:latestOr use the repo's docker-compose.yml — same image, port 8080, optional DISABLE_IPV6=true if your network is IPv4-only.
The container is mostly a static file server (nginx-style); it is not Stirling-level RAM hungry on the server. Plan resources for concurrent users' laptops instead: OCR and Office conversion in-browser will spike client CPU. For air-gapped sites, follow their WASM configuration guide so browsers aren't calling public CDNs.
TLS via your reverse proxy; add auth (Authelia, OAuth2 proxy, VPN) if the instance is on the public internet — otherwise anyone who finds the URL gets the same tools your legal team uses.
Who it's for (and who should skip it)
Good fit: firms that want "no upload" PDF tooling on an internal URL, privacy-conscious teams tired of SaaS PDF sites, orgs that need redaction/signing without Adobe seat licenses, homelabbers who want a prettier alternative to bookmarking five different utilities.
Maybe skip it: if you need headless batch PDF via REST on the server — stick with Stirling-PDF or a scriptable toolchain. If users run ancient browsers without solid WASM support, test before you roll out. If AGPL is a non-starter for your product surface, budget the commercial license or pick a different stack.
Hosting the app in Canada
We deploy lightweight static and Docker front-ends on Canadian VPS hosting — TLS, backups of your compose config, and network rules so internal PDF tools aren't indexed by Google. BentoPDF won't tax the server like OCR-heavy server-side apps, but getting auth and WASM mirrors right is where projects actually succeed or fail.
Tell us internal vs public, air-gapped or CDN WASM, and how many staff will hit it — we'll put the container on a sensible box and document the update path.
