Stirling PDF: A Self-Hosted PDF Toolbox with an Open-Core Business Model
Stirling PDF is an open-source PDF platform with 50+ tools to edit, merge, sign, redact, convert, and OCR files, self-hosted so documents never leave your servers.
At a glance
- What is it?
- Stirling PDF is an open-source PDF platform that runs as a desktop app, in the browser, or on your own server. This review covers its 50+ tools, the automation pipeline, and the trade-offs of its open-core licensing.
- Who is it for?
- Adopt Stirling PDF if you need a self-hosted PDF toolset that keeps documents off external services and offers a no-code pipeline for batch work. Skip it if you require a fully open-source solution with no paid tiers, because the open-core license means some enterprise features are not free.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Java, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem: PDF Editing Without Sending Files to Third Parties
Most online PDF tools ask you to upload a document to their servers. That is a privacy problem for contracts, medical records, or any file with confidential data. Stirling PDF solves this by letting you run the entire toolset on your own machine or server. The README positions it as a platform for editing, signing, redacting, converting, and automating PDFs without external services. It targets individuals who want a desktop app, teams that need a shared browser UI, and organizations that want a private API for integration. If you have ever hesitated before uploading a PDF to a random website, this project directly addresses that hesitation.
How It Works: A Self-Hosted Server with a Web UI and REST API
Stirling PDF is a Java application that runs as a server. You access it through a browser interface, or you can use the REST API for programmatic control. The architecture is straightforward: the server receives a PDF, applies the requested operation, and returns the result. The README lists 50+ tools covering merge, split, sign, redact, convert, OCR, and compress. The automation feature is a no-code pipeline builder in the UI, which can chain operations without writing code. For developers, the API exposes nearly all tools, so you can integrate PDF processing into existing systems. The entire stack is designed to be deployed on your own infrastructure, which is the core differentiator from cloud-only services.
Getting It Running: Docker, Desktop, and Kubernetes Options
The quick start is a single Docker command: docker run -p 8080:8080 docker.stirlingpdf.com/stirlingtools/stirling-pdf. After pulling the image, you open http://localhost:8080 and you have a working PDF platform. The README mentions a desktop client and Kubernetes deployment, but the exact installation steps are in the documentation guide. The project uses Task as a unified command runner for development; running task dev starts the editor, and task lists the common commands. For a user who just wants to process PDFs locally, Docker is the fastest path. For a team that needs shared access, you can host the same image on a server and expose it internally.
The Automation Pipeline: No-Code Workflows for Batch Processing
One of the most distinctive features is the no-code workflow builder. You can chain PDF operations in the UI without writing a single line of code. This is useful for repetitive tasks like converting a batch of files to a standard format, adding watermarks, or redacting sensitive fields. The README claims the APIs can process millions of PDFs, which suggests the automation is designed for scale. However, the documentation for the pipeline is not in the README; you would need to check the docs site or the API reference. The existence of this feature moves Stirling PDF beyond a simple tool collection and into workflow automation territory, which is rare in open-source PDF projects.
A Real Limitation: Open-Core Means Not Everything Is Free
The README states Stirling PDF is open-core. That means the core tools are open source, but some features are reserved for paid plans. The Server Plan and Enterprise offerings are mentioned, and they include SSO, auditing, and flexible on-prem deployments. If your organization needs those enterprise features, you will have to pay. The license file is referenced but not detailed in the README, so you cannot tell exactly which features are free without inspecting the repository. This is a genuine trade-off: you get a powerful open-source base, but the most advanced administrative controls are not in the community edition. For a small team that just needs PDF tools, that is fine. For a large enterprise with compliance requirements, the paid tier becomes a factor.
Alternative Approaches: Cloud Services vs. Other Self-Hosted Tools
The obvious alternative is a cloud service like IlovePDF or Adobe Acrobat Online. Those services are easy to use but require uploading files, which Stirling PDF avoids. Another alternative is a desktop-only tool like PDFsam or LibreOffice Draw, which are fully offline but lack the automation and API capabilities. The key difference is that Stirling PDF offers a server model with a UI and API, which neither desktop tools nor cloud services combine. If you need a self-hosted API, Stirling PDF is one of the few options that provide it out of the box. If you only need occasional edits, a desktop tool may be simpler and have no server overhead.
Maintenance and Upgrade Cost: Frequent Releases and Bug Fixes
The release history shows active maintenance. Version 2.14.3, pushed on 2026-08-06, includes many bug fixes. The previous release, 2.14.2, was a hotfix for certain PostgreSQL environments, which indicates the project supports PostgreSQL as a backend but also that database-specific issues can arise. The 2.14.1 release added a third-party license page, which is a good sign for compliance. Upgrading involves pulling a new Docker image and restarting the container. The cost is low for a single instance, but if you have a custom workflow pipeline, you need to test it after each upgrade to ensure nothing breaks. The project's use of Task for development suggests a structured build process, which helps maintainability. The open-core model means you should track which features are in the free version as the project evolves.
Editorial conclusion
Adopt Stirling PDF if you need a self-hosted PDF toolset that keeps documents off external services and offers a no-code pipeline for batch work. Skip it if you require a fully open-source solution with no paid tiers, because the open-core license means some enterprise features are not free. Before deploying, verify which tools you rely on are in the community edition and check the API docs for the exact endpoints you plan to automate. Test the Docker image on your target hardware to confirm performance for large PDFs, and review the license file to understand what the paid Server Plan covers.
Community notes