Open-source PDF processing, honestly reviewed. What 75,000 GitHub stars don’t tell you.

TL;DR

What it is: Open-core, self-hosted PDF platform with 50+ tools — merge, split, OCR, redact, sign, convert, and automate PDFs without touching an external service [README].
Who it’s for: Privacy-conscious developers, IT teams, and document-heavy businesses (legal, healthcare, finance) who need to process sensitive files without routing them through Adobe or a random online tool [website][2].
Cost savings: Adobe Acrobat Pro runs $14.99–$23.99/mo per user. Stirling-PDF self-hosted runs on a $5–10/mo VPS with no per-document pricing [website].
Key strength: The most complete open-source PDF toolkit available. 50+ operations, a real REST API, OCR, automation pipelines, and an AI agent mode — all running entirely on your own hardware [README][2].
Key weakness: The license is open-core (not MIT), SSO and enterprise features are gated behind a paid tier, and the project had a documented privacy controversy in 2025 involving analytics cookies and a tracking pixel that many self-hosters considered a trust violation [4].

What is Stirling-PDF

Stirling-PDF is a self-hosted web application that handles PDF manipulation end-to-end. You run it in a Docker container on your server or locally on your desktop, point your browser at port 8080, and you have a full PDF toolkit that never sends your documents anywhere [README].

The GitHub README describes it plainly: “#1 PDF Application on GitHub that lets you edit PDFs on any device anywhere.” With 75,459 stars as of this review, that claim is hard to argue with [merged profile]. The website adds: “Edit, sign, redact, convert, and automate PDFs without sending documents to external services” — which is exactly the pitch that resonates with anyone who’s watched a lawsuit-sensitive contract disappear into smallpdf.com [README].

What makes Stirling-PDF more than a merge-and-split wrapper is three things. First, breadth: 50+ individual PDF operations, from OCR and watermarking to form flattening and metadata scrubbing, all accessible through both the UI and a REST API [README][2]. Second, automation: you can chain operations into no-code pipelines directly in the UI, or call the API from n8n, Zapier, or any script — one self-hoster built an entire document ingestion pipeline feeding Paperless-ngx via the Stirling-PDF API [2]. Third, privacy architecture: documents exist only in server memory during processing, with no persistent storage and no external calls, which is the right design for sensitive documents [1].

The company behind it claims 55,000 enterprise deployments and usage by 75% of Fortune 500 companies — numbers Scarf Analytics provides, though you should take them with the usual skepticism applied to analytics-derived user counts [website].

Why People Choose It

The consensus across reviews is straightforward: people are tired of feeding their documents to online PDF tools.

The PhD student who wrote about Stirling-PDF on Medium [3] captures the frustration precisely: one minute you’re merging two documents, the next you’ve touched three half-broken online tools, dealt with a mysteriously rotated page, and hit a paywall on the final step. Stirling-PDF solves this by running entirely inside your own infrastructure. No accounts, no upload limits, no “sign up for unlimited merges.”

Akash Rajpurohit found it while building an automated document workflow [2]. He needed a privacy-respecting alternative that could handle password-protected PDFs before they landed in Paperless-ngx. The Stirling-PDF API made it a drop-in component in his n8n automation chain. This is a pattern that appears across self-hosting communities: Stirling-PDF gets discovered not as a standalone tool but as a reliable PDF processing layer in larger document workflows.

Neil Brown deployed it on a Raspberry Pi 4 and emphasizes the privacy design: files are processed in server memory only during task execution, with no residual storage [1]. That’s the right architecture for anyone handling anything sensitive — legal documents, health records, financial statements.

The trust, however, is not unconditional.

The Tracking Controversy (Read This Before Deploying)

This is the thing the GitHub star count doesn’t show you.

In 2025, users in the self-hosting community discovered that Stirling-PDF had analytics cookies and a tracking pixel enabled by default [4]. This triggered a significant backlash. The concern wasn’t just the tracking itself — it was that a tool explicitly marketed on privacy grounds was phoning home without clear disclosure. One XDA Developers writer called it out directly: “Why does a tool I run locally on my server need to ask for cookie permission?” [4]

The developers subsequently made the tracking opt-in rather than opt-out. But for a meaningful slice of the privacy-focused self-hosting audience, the original behavior broke trust irreparably. At least one writer switched to an alternative (BentoPDF) specifically because of this incident [4].

The practical implication: Stirling-PDF is still technically private in its document handling, but if you care deeply about zero telemetry, verify the current default configuration before deploying. The fix is documented, but you should check it rather than assume [4].

Features

Based on the README and deployment articles:

Core PDF operations:

Merge, split, reorganize, compress, rotate [README]
Convert to/from PDF (images, Office formats, HTML) [README]
OCR with Tesseract — full tessdata support [2]
Redaction, watermarking, stamping, metadata scrubbing [1][2]
Password protection, decryption, digital signatures [2]
Form filling and flattening [README]
Page extraction and reordering [3]

Automation:

No-code workflow pipelines in the UI [README]
REST API for nearly all 50+ tools — usable from n8n, scripts, or any HTTP client [README][2]
Batch processing support [2]
Docker-native for integration into larger self-hosted stacks (Paperless-ngx, n8n) [2]

AI and intelligence:

AI Agent mode with local LLM support — summarize, redact, transform documents with zero data leaving your server [website]
OCR as a standalone pipeline step [2]

Enterprise (paid tier):

SSO (Single Sign-On) [README][website]
Audit logging [website]
Advanced on-prem deployment options [website]

UI and access:

Web interface available in 40+ languages [README]
Desktop app mode [README]
Mobile-friendly — one reviewer specifically calls out usability on mobile [2]

What’s missing from the community edition: SSO and audit logs are commercial-gated, which matters if you’re deploying this for a team rather than a personal homelab [website]. For a solo operator or small office, the free tier covers everything practical.

Pricing: SaaS vs Self-Hosted Math

Stirling-PDF self-hosted:

License cost: $0 for the community edition [README]
Infrastructure: $5–20/mo on any VPS (Hetzner, Contabo, DigitalOcean)
Enterprise tier: contact sales — pricing not publicly listed [website]

Adobe Acrobat for comparison:

Acrobat Standard: ~$12.99/mo (annual)
Acrobat Pro: ~$19.99/mo (annual)
For teams: $14.99–$23.99/user/month, climbs fast with headcount

Smallpdf:

Pro: ~$12/mo per user
Team: ~$23/user/month

iLovePDF:

Premium: ~$4–7/mo, with file size and batch limits on lower tiers

Concrete math:

A legal team of five people paying $19.99/mo each for Adobe Acrobat Pro spends $99.95/mo — $1,199/year — for PDF processing. Self-hosting Stirling-PDF on a $10/mo VPS (with ample capacity for a five-person team) costs $120/year with no per-user or per-operation pricing. That’s roughly $1,080/year saved, not counting the fact that Stirling-PDF handles operations Adobe doesn’t offer cleanly, like batch metadata scrubbing or automated OCR pipelines.

For a solo founder currently paying $12/mo for Smallpdf, the math is simpler: $5/mo VPS replaces $12/mo SaaS. The crossover payback on setup time is under two months.

The caveat: if you need the enterprise tier with SSO and audit logs, pricing is opaque. Budget a conversation with their sales team rather than a predictable monthly line item [website].

Deployment Reality Check

The quickest path to a running instance is one Docker command [README]:

docker run -p 8080:8080 docker.stirlingpdf.com/stirlingtools/stirling-pdf

Then open http://localhost:8080. That’s genuinely it for local use.

For a production self-hosted instance with authentication, Neil Brown’s setup is more representative [1]:

Podman or Docker + Compose
Environment variables for locale, file size limits, and login
Volume mounts for user-specific files (signatures, configurations)
A reverse proxy (nginx or Caddy) for HTTPS
Systemd or screen/tmux to keep the container running after SSH disconnects

Brown flags one genuine annoyance: containers stopping after SSH session ends [1]. This isn’t a Stirling-PDF bug — it’s a common container lifecycle issue — but it caught him by surprise, and he acknowledges neither his suggested workarounds (tmux or systemd lingering) feel clean.

Akash Rajpurohit’s setup adds OCR tessdata volumes and integrates with an existing n8n stack [2]. His takeaway: the API makes automation “a breeze,” and the whole deployment took a reasonable afternoon.

What you realistically need:

Linux VPS with at least 2GB RAM (4GB if you’re running OCR or AI agent features)
Docker and docker-compose
A domain and reverse proxy if you want HTTPS
Roughly 30–60 minutes for a technical user; 2–4 hours for someone new to self-hosting

What can go sideways:

The tracking controversy from 2025 — verify your default telemetry settings post-install [4]
OCR requires tessdata volumes to be correctly mounted; easy to misconfigure [2]
The AI agent mode requires a local LLM (e.g., Ollama) — Stirling-PDF doesn’t ship one [website]
SSO requires the paid enterprise tier; don’t plan your team deployment around it unless you’ve confirmed pricing [website]

Pros and Cons

Pros

50+ PDF operations in one tool. Most self-hosted PDF tools do 5–10 things. Stirling-PDF does merging, splitting, OCR, redaction, signing, conversion, watermarking, form handling, and more — all in a single deployment [README][2].
Real REST API. Not an afterthought — nearly every tool is API-accessible, which makes Stirling-PDF useful as a PDF processing layer in larger automation stacks [README][2].
Privacy-correct document architecture. Files stay in server memory during processing, with no external calls and no persistent storage [1]. This is the design that actually deserves the “private” label.
75,000+ GitHub stars and serious adoption. 55K enterprise deployments and Fortune 500 usage aren’t marketing noise — this is production-tested software [website][merged profile].
AI agent mode with local LLMs. Connect to Ollama and process documents with AI entirely inside your own network [website]. No data leaves the machine.
No per-document or per-user pricing. Unlike every SaaS PDF tool, you pay once for the VPS and run unlimited documents [README].
Active community and development. Kubernetes and Helm support, 40+ UI languages, desktop app, continuous feature additions [README].

Cons

The tracking controversy damaged trust. Analytics cookies and a tracking pixel enabled by default — on a privacy-focused tool — was a real trust violation for the self-hosting community, even after the fix [4]. Some users switched away permanently.
Open-core, not fully open source. The license is listed as “NOASSERTION” in the merged profile and described as “open-core” in the README [merged profile][README]. Enterprise features (SSO, audit logs) are commercial-gated. This is not the MIT freedom you get with tools like Activepieces.
Enterprise pricing is opaque. No public pricing page for the paid tier. You need to contact sales, which is a friction point if you’re trying to plan a budget [website].
No bundled LLM for AI features. The AI agent mode is real but requires a separately deployed local LLM. It won’t work out of the box [website].
SSH disconnect issue in some deployments. Not a product bug, but a real gotcha in Docker-based setups that requires additional configuration to solve [1].
The “Fortune 500” claims are hard to verify. Scarf Analytics-based numbers — Docker pull counts, not confirmed enterprise contracts [website]. Take the scale claims at face value only.

Who Should Use This / Who Shouldn’t

Use Stirling-PDF if:

You handle sensitive documents (legal, medical, financial) and can’t stomach routing them through Adobe or any online service.
You’re paying $10–$50/mo per person for a SaaS PDF tool and the math on self-hosting makes sense.
You want a PDF processing layer in an existing automation stack (n8n, Make, custom scripts) — the API is solid.
You’re a homelab or small IT team who wants one tool that covers everything PDF-related.
You’re comfortable with basic Docker deployment or have someone to do it once.

Skip it (stay on Adobe/Smallpdf) if:

You need SSO and audit logs on a budget — the community edition doesn’t have them, and enterprise pricing is unknown.
The 2025 tracking controversy is a dealbreaker and you haven’t verified the current defaults.
Your team has zero Linux experience and no one to help with the initial deployment.
You process only occasional documents and the Acrobat free tier or browser-based tools cover you.

Consider an alternative if:

You switched away after the tracking controversy and need something that was privacy-first from day one [4].
You need a simpler tool with fewer features and a cleaner trust record.

Alternatives Worth Considering

BentoPDF — The tool XDA Developers’ writer switched to after the Stirling-PDF tracking controversy [4]. Newer, cleaner UI, privacy-first design. Less mature and fewer features, but a legitimate alternative for users who want zero telemetry controversy.
LibreOffice + CLI tools (ghostscript, pdftk) — Zero-UI, fully scriptable, genuinely open source. Appropriate for developers who want to build pipelines without a web UI. Harder to hand to non-technical staff.
mupdf — Lightweight, fast, open source. Good for rendering and simple operations; not a full-featured replacement.
DocuSeal — Focused specifically on document signing and form filling. Not a general PDF toolkit, but excellent if that’s your primary use case.
Paperless-ngx — For document management and archival rather than manipulation. Often deployed alongside Stirling-PDF, not instead of it [2].

For a non-technical founder who just needs to stop paying per-user SaaS pricing, Stirling-PDF is still the most complete answer in the self-hosted space. BentoPDF is worth watching if its toolset matures. Nothing else in the open-source category matches Stirling-PDF’s operation breadth right now.

Bottom Line

Stirling-PDF is the most complete open-source PDF toolkit available, and it’s not particularly close. 50+ operations, a real API, OCR, workflow automation, AI agent mode — all running inside your own infrastructure on a $5 VPS. For any team paying per-user SaaS pricing for document processing, the economics are obvious and the privacy benefits are real.

The honest asterisk: the 2025 tracking incident matters. A tool built on the “your documents never leave your server” pitch having analytics enabled by default is a contradiction that cost it genuine trust. The fix exists, but check it. The open-core license is also worth understanding before you plan a team deployment — SSO and audit logs require the paid tier at opaque pricing.

If you go in clear-eyed about both points, Stirling-PDF is still the right answer for the vast majority of self-hosters. If deploying Docker is the blocker, that’s the kind of one-time setup that upready.dev handles for clients — you own the infrastructure, they make it run.