BentoPDF: PDF-Werkzeuge im Browser, selbst gehostet unter AGPL-3.0

BentoPDF: Verarbeitung im Browser statt auf dem Server

Das README von BentoPDF stellt das Projekt als „Privacy First PDF Toolkit“ vor. Der tragende Satz steht im ersten Absatz: Es sei keine serverseitige Verarbeitung erforderlich, die Dateien blieben dadurch privat. Konkret heißt das, dass Zusammenführung, Seitendrehung, Kompression und Konvertierung als JavaScript im Tab des Nutzers laufen, nicht in einem Backend.

Für Dokumente mit Personenbezug ist das ein anderes Risikoprofil als bei einem gehosteten Dienst, bei dem die Datei zunächst hochgeladen wird. Aus derselben Architektur folgt eine Grenze: Rechenlast und Speicher liegen auf dem Endgerät. Lange Konvertierungsketten belasten den Client, nicht die Infrastruktur des Betreibers. Wer BentoPDF für ein Team bereitstellt, verschiebt die Kosten dorthin, wo die Tastatur sitzt, und gewinnt dafür, dass kein PDF die eigene Netzwerkgrenze verlässt.

Die Repository-Metadaten weisen JavaScript als Hauptsprache aus, der Default-Branch heißt main, der letzte erfasste Push stammt vom 27. Juli 2026. Die jüngste Version trägt das Tag v2.8.7 und den Namen „CVE Fixes“, was darauf hindeutet, dass Sicherheitskorrekturen im normalen Release-Zyklus ausgeliefert werden. Welche Schwachstellen damit gemeint sind, geht aus dem Tag allein nicht hervor.

Der Werkzeugkatalog: über 50 Funktionen von Merge bis OCR

Die im README abgedruckte Liste ist in fünf Gruppen gegliedert. Unter „Organize & Manage“ stehen Merge, Split, Organize Pages, Extract Pages, Delete Pages, Rotate PDF und Rotate by Custom Degrees. Die Gruppe „Edit & Modify“ deckt Anmerkungen, Formularerstellung, Wasserzeichen und Redaction ab. Hinzu kommen Konvertierungen in beide Richtungen, also Office- und Bildformate nach PDF sowie PDF nach Text, Markdown, SVG und DOCX.

Eine vierte Gruppe bündelt Verschlüsseln, Entschlüsseln, Komprimieren und Bereinigen. Das README verweist außerdem auf einen Workflow-Builder und auf OCR. Die Dokumentationsseite unter bentopdf.com/docs/ beziffert den Umfang mit mehr als 50 Werkzeugen; das README selbst nennt keine Gesamtzahl, sondern zählt Einzelfunktionen auf.

An zwei Stellen wird die Beschreibung konkret: Beim Zusammenführen blieben Lesezeichen erhalten, und Rotate by Custom Degrees erlaube beliebige Winkel. Solche Einzelheiten sind brauchbarer als eine bloße Aufzählung, weil sie eine Erwartung definieren, die sich mit einer eigenen Testdatei prüfen lässt. Wie sich die Werkzeuge bei passwortgeschützten oder beschädigten Eingabedateien verhalten, steht im README nicht.

BentoPDF per Docker, Podman Quadlet oder statischem Hosting betreiben

Der kürzeste Weg laut README führt über ein fertiges Container-Image: docker run -p 3000:8080 ghcr.io/alam00000/bentopdf-simple:latest. Zu merken ist die Port-Zuordnung, der Container lauscht innen auf 8080 und wird außen auf 3000 gelegt. Für dauerhafte Installationen hält das README Compose-Dateien für Docker und Podman bereit und zeigt zusätzlich ein Podman-Quadlet-Beispiel für die Einbindung in systemd, was auf Linux-Servern ohne Docker-Daemon der praktikablere Weg ist.

Wer keinen Container einsetzen will, lädt ein vorgebautes Distributions-Archiv aus den Releases und stellt es hinter einen Webserver; Netlify, Vercel und GitHub Pages werden ausdrücklich genannt. Der Build aus dem Quellcode läuft über npm install, npm run build und npm run package.

Eine Bedingung zieht sich durch die Hosting-Hinweise: Die Konvertierung von Office-Dateien verlangt SharedArrayBuffer, und dafür muss die Anwendung Cross-Origin-isoliert ausgeliefert werden, also mit gesetzten COOP- und COEP-Headern in einem sicheren Kontext. Bei einem statischen Hoster ohne Kontrolle über die Response-Header fällt genau dieser Teil der Funktionen weg, obwohl die Oberfläche tadellos lädt.

bentopdf-simple gegen bentopdf: Branding, Kompression, abgeschaltete Werkzeuge

BentoPDF kennt zwei Build-Varianten. bentopdf-simple ist der Self-Hosting-Build und laut README funktionsgleich mit dem kommerziellen Build, blendet aber Marketingelemente wie Hero-Bereich, FAQ, Testimonials und Footer aus. Der Build bentopdf enthält die vollständige Marketing-Site, so wie sie auf bentopdf.com läuft und von kommerziellen Lizenznehmern genutzt wird.

Für eigenes Branding setzt man beim Build Umgebungsvariablen: VITE_BRAND_NAME, VITE_BRAND_LOGO und VITE_FOOTER_TEXT. Weil diese Werte zur Build-Zeit eingebettet werden, ist für jede Änderung an Name oder Logo ein neuer Build nötig; eine zur Laufzeit gesetzte Variable bewirkt nichts. Das README beschreibt ferner Kompressionsmodi mit den Werten gzip, brotli, original und all sowie ein separates Flag für die Auslieferung der WASM-Dateien über jsDelivr.

Vorgesehen sind außerdem das selektive Abschalten einzelner Werkzeuge und das Deaktivieren des GitHub-Stern-Zählers. Für eine interne Instanz, die nur drehen und zusammenführen soll, ist das der Weg, die Oberfläche auf das Nötige zu reduzieren, statt sie neu zu bauen.

PyMuPDF, Ghostscript, CoherentPDF und Tesseract als WASM-Bausteine

Aufschlussreich ist, wie BentoPDF an Funktionen gelangt, die sich in JavaScript nicht sinnvoll nachbauen lassen. Das Projekt bündelt die entsprechenden Bibliotheken laut README nicht im Quellcode, sondern konfiguriert CDN-Adressen vor, über die WASM-Module zur Laufzeit von jsDelivr geladen werden. PyMuPDF übernimmt PDF nach Text, Markdown, SVG und DOCX sowie Bildextraktion, Tabellenerkennung, EPUB-, MOBI- und XPS-Konvertierung, Kompression und Deskew. Ghostscript wird für PDF/A und Font to Outline eingesetzt, CoherentPDF für Merge, Split nach Lesezeichen, Inhaltsverzeichnisse, PDF nach JSON und Anhänge.

Alle drei Bibliotheken stehen unter AGPL-3.0. Das README hebt hervor, dass nur URLs vorkonfiguriert sind. Für die eigene Lizenzprüfung macht das einen Unterschied: Der Code im Repository ist von diesen Abhängigkeiten getrennt, der laufende Betrieb ist es nicht.

OCR läuft über Tesseract, mit getrennt konfigurierbaren Adressen für Worker, Core, Sprachdaten und Schriftarten. Eine technische Bedingung wird bei Self-Hosting gern übersehen: WASM-Dateien müssen von derselben Origin bedient werden wie die Anwendung, weil die Web Worker importScripts() verwenden. Ein abweichendes Asset-Verzeichnis auf einem zweiten Host bricht die betroffenen Werkzeuge.

Air-Gapped-Setup mit prepare-airgap.sh

Für Netze ohne Internetzugang hält das README ein Skript namens prepare-airgap.sh bereit. Es lädt die benötigten Pakete herunter, baut daraus ein Docker-Image und exportiert ein Bündel zusammen mit einem Setup-Skript; manuelle Schritte sind ebenfalls beschrieben. Genau hier zeigt sich, wie stark der Standardbetrieb auf externe Adressen angewiesen ist, denn ohne diesen zusätzlichen Aufbau bleiben alle PyMuPDF-, Ghostscript- und CoherentPDF-Funktionen ohne Funktion.

Für eine Behörde oder ein Unternehmen mit strengen Vorgaben ist das der eigentliche Prüfpunkt: nicht ob die Oberfläche startet, sondern ob nach dem Air-Gap-Build OCR und PDF/A mit einer realen Datei aus dem eigenen Bestand das tun, was sie sollen. Zur Größe des entstehenden Bündels macht das README keine Angabe.

Ebenfalls im README enthalten ist ein Abschnitt zu Sicherheitsfunktionen sowie der Hinweis, dass für digitale Signaturen ein CORS-Proxy erforderlich ist. Wer Signaturen einsetzen will, betreibt damit wieder eine zusätzliche Serverkomponente, was dem Datenschutzgedanken des Projekts teilweise zuwiderläuft und in die eigene Risikobewertung gehört.

AGPL-3.0 oder 79 Dollar: was die Lizenz für den eigenen Betrieb bedeutet

BentoPDF ist dual lizenziert. Die kostenlose Variante steht unter AGPL-3.0 und ist laut README für Open-Source-Projekte mit öffentlichem Quellcode gedacht. Wer das Werkzeug in ein proprietäres Produkt einbaut oder eine angepasste Fassung über ein Netzwerk anbietet, löst die AGPL-Pflicht aus, den Quellcode der modifizierten Version bereitzustellen. Die kommerzielle Lizenz kostet 79 Dollar einmalig, gilt für unbegrenzte Geräte und Nutzer, schließt lebenslange Updates ein und entbindet von diesen Pflichten.

Wichtig für die Praxis: Auch eine nur im Firmennetz erreichbare Instanz ist ein Netzwerkeinsatz im Sinne der AGPL. Änderungen über VITE_BRAND_NAME fallen nicht ins Gewicht, Eingriffe in die Verarbeitungslogik sehr wohl. Die Reichweite im konkreten Fall hängt von der eigenen Nutzung ab und ist keine Frage, die ein README beantwortet.

Als Gegenentwurf taugt der Vergleich mit server-seitigen Self-Hosting-Werkzeugen derselben Kategorie, zu denen Stirling-PDF gehört. Dort wird die Datei hochgeladen, der Server rechnet, und die Last wandert in die Infrastruktur statt in den Browser. Bei sehr großen Dateien und Stapelverarbeitung ist das der überlegene Ansatz, bei vertraulichen Dokumenten der falsche.

Redaktionelles Fazit

BentoPDF passt zu Teams, die PDF-Workflows selbst betreiben und dafür CORS-Header, WASM-Hosting und die AGPL-Pflichten selbst tragen wollen. Wer eine fertige Instanz ohne Offenlegung eigener Änderungen braucht, landet bei der 79-Dollar-Lizenz, und wer sehr große Dateien in Stapeln verarbeitet, ist mit einem server-seitigen Werkzeug besser bedient. Prüfen Sie zuerst mit prepare-airgap.sh, ob die von Ihnen benötigten PyMuPDF-, Ghostscript- und CoherentPDF-Funktionen ohne jsDelivr überhaupt starten.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository
4. Release notes