Stirling PDF Self-Hosting Guide 2026: Docker, OCR, Security and Real-World Workflows

By AiCybr Editorial · Published August 10, 2026

Stirling PDF is a strong self-hosted choice when you want a browser-based toolbox for editing, converting, OCRing, signing, redacting and automating PDFs without sending the documents to a third-party web service. For most homelabs, the standard Docker image with login enabled, persistent /configs, and a reverse proxy or private-network access is the sensible starting point.

The important distinction is that Stirling PDF is a document-processing application, not a document-management system. It is excellent for transforming files. It is not a replacement for software such as Paperless-ngx when your real requirement is long-term document ingestion, indexing, tagging and archival search.

Quick recommendation

What Stirling PDF actually does

Stirling PDF’s repository currently describes the project as open-core. The self-hostable core provides a broad PDF-processing platform that can run as a desktop application, browser-based service or self-hosted server, while some additional capabilities live in separately licensed proprietary components. The current project documentation lists more than 50 PDF tools covering operations such as merging, splitting, editing, redaction, conversion, OCR, compression and signing.

The self-hosted model is useful because the processing backend runs on infrastructure you control. That can be materially different from uploading tax forms, contracts, identity documents or internal reports to a random online PDF converter.

Self-hosting does not, however, make a deployment automatically secure. If you expose the service directly to the public internet with weak authentication or poor reverse-proxy configuration, you have simply moved the trust boundary to your own server.

Recommended deployment architecture

For a typical home server, NAS-adjacent Docker host or small VPS, a simple deployment looks like this:

Browser
   |
HTTPS / private overlay network
   |
Reverse proxy or private access layer
   |
Stirling PDF container
   |
Persistent /configs
Optional OCR language data
Optional logs / pipeline data

The application documentation currently recommends Docker for server deployments and provides three image families:

• Standard (latest): the normal recommended image for most users.
• Fat (latest-fat): includes additional fonts and tools for broader conversion support.
• Ultra-Lite (latest-ultra-lite): a smaller build intended for constrained systems and basic operations.

For a normal x86-64 or ARM home server with enough storage, start with the standard image rather than optimizing prematurely for the smallest possible container.

Basic Docker Compose deployment

A minimal persistent deployment can look like this:

services:
  stirling-pdf:
    image: stirlingtools/stirling-pdf:latest
    container_name: stirling-pdf
    ports:
      - '8080:8080'
    volumes:
      - ./stirling-data:/configs
    restart: unless-stopped

Then start it with:

docker compose up -d

The important part is not the port number. It is the persistent /configs mount. Current Stirling PDF documentation describes /configs as the location for settings and database data used by the application.

If you recreate a container without persisting the configuration data you care about, you can lose application state even though Docker itself appears healthy.

Authentication: do not casually disable it

Current Stirling PDF Docker documentation says login is enabled by default for the normal Docker image. A new installation creates an initial admin account using the documented default credentials and requires the password to be changed.

That default matters operationally: change the initial password immediately and do not assume that running a container on a home network means nobody else can reach it.

Stirling PDF supports disabling authentication with SECURITY_ENABLELOGIN=false, but that is best reserved for tightly controlled situations such as a service bound only to localhost behind another authentication layer.

For most users, leaving the application’s own login enabled is the safer default.

If you expose it beyond localhost

At minimum:

1. use HTTPS;
2. keep login enabled;
3. use a strong unique administrator password;
4. restrict network reachability where practical;
5. keep the container and host updated;
6. back up persistent configuration before major upgrades;
7. do not expose management interfaces or Docker sockets to the container.

Stirling PDF’s production deployment guide also demonstrates conventional reverse-proxy hardening, including HTTPS and restrictive response headers such as X-Frame-Options: SAMEORIGIN. Treat those examples as a baseline to adapt to your own proxy and embedding requirements rather than as a substitute for reviewing the full deployment.

Private-network access is often better than public exposure

A PDF utility rarely needs to be globally reachable by anonymous internet clients.

For a personal homelab, one of the cleanest designs is:

Laptop / phone
      |
Tailscale / Headscale / NetBird / VPN
      |
Home server
      |
Stirling PDF

That avoids opening a public inbound service just so you can merge or OCR a document away from home.

If you do use a public reverse proxy, treat Stirling PDF as any other authenticated web application: HTTPS, access controls, sensible headers, patching and monitoring all still matter.

OCR: what you actually need

Stirling PDF uses Tesseract for optical character recognition. OCR runs on the server backend, not purely inside the desktop client’s local-only mode.

That means scanned-document workflows depend on the server having the appropriate OCR components and language data available.

Current documentation says the default Docker image includes several common language packs and allows additional Tesseract .traineddata files to be mounted into the container.

A dedicated OCR data mount can look like:

volumes:
  - ./stirling-data/tessdata:/usr/share/tessdata

The application exposes OCR modes including automatic handling of pages that already contain text, forced OCR and stricter behavior when an existing text layer is detected.

Advanced preprocessing options can include deskewing and image cleanup when OCRmyPDF support is available.

OCR limitations to understand

Do not confuse OCR with document understanding.

According to Stirling PDF’s current OCR documentation, Tesseract recognizes text but does not reconstruct table structure or mathematical formulas as semantic objects. Handwriting, decorative fonts, tiny text and low-quality scans can also reduce accuracy.

So a scanned bank statement may become searchable, but OCR does not guarantee a perfect spreadsheet-like reconstruction of every table.

Standard vs Fat vs Ultra-Lite

The image choice is mostly about capability versus footprint.

Do not choose Ultra-Lite merely because your server is a mini PC. A modern low-power server can often run the normal container comfortably; the important question is whether you need the features omitted from the smaller build.

Persistent data and backup design

The easiest backup mistake is to save only finished PDFs while forgetting the application state required to reproduce the deployment.

For a Docker installation, separate three categories:

1. Application configuration

Persist and back up /configs.

This contains the configuration/database state documented by the project and should be treated as part of the application backup.

2. OCR language packs and optional assets

If you installed custom Tesseract data, fonts or related resources, keep a copy of those files or make the setup reproducible through configuration management.

3. Your actual documents

Stirling PDF is generally a transformation tool. Your authoritative documents should live in your normal storage/backup system rather than relying on a temporary processing workflow.

If a PDF matters, it should already be covered by your normal backup policy before you edit, redact, compress or OCR it.

A safer upgrade pattern

For important deployments:

1. back up /configs and any custom OCR assets;
2. note the currently working image tag/version;
3. pull the new image;
4. recreate the container;
5. test login and a representative conversion/OCR workflow;
6. keep the prior version available for rollback until validation is complete.

Using latest is convenient, but production-like homelabs may prefer pinning a known-good release so an automated container refresh does not silently introduce a breaking change.

Stirling PDF vs Paperless-ngx

These projects overlap around scanned documents, but they solve different primary problems.

A useful homelab pattern is to use both:

• Stirling PDF for repairing, combining, rotating, redacting, converting or manually OCRing files;
• Paperless-ngx for ingesting and organizing the finished documents.

That avoids trying to force a transformation utility into becoming your permanent records database.

Desktop app vs self-hosted server

Stirling PDF also offers desktop applications for Windows, macOS and Linux.

The desktop option is attractive when only one workstation needs basic PDF operations and you do not want another always-on service.

The self-hosted server becomes more useful when:

• several devices need the same PDF toolbox;
• you want browser access from phones/tablets;
• OCR or server-side tooling is required;
• you want one internal API for automated jobs;
• you already operate Docker infrastructure.

The desktop app does not eliminate the need for a server in every scenario. Current OCR documentation explicitly says OCR requires a server backend with Tesseract; the desktop client cannot perform that OCR workflow in local-only mode.

Automation and API use

The project exposes REST APIs for many tools and documents pipeline/automation functionality.

That makes Stirling PDF useful beyond interactive browser use. Examples include:

• OCR incoming scanned PDFs before archival;
• normalize page orientation;
• compress large generated reports;
• merge known document sets;
• convert files before another workflow consumes them.

For automated processing, treat the API like any other service endpoint. Do not expose an unauthenticated PDF-processing API directly to the internet unless there is a specific reason and a separate access-control layer protecting it.

Resource planning

There is no single meaningful RAM or CPU number for every Stirling PDF workload because the expensive work depends on what you ask it to do.

Simple merge/split/rotate operations can be lightweight. OCR, large conversions, high-resolution scans and parallel jobs can be substantially more demanding.

A better sizing approach is:

1. deploy the standard container;
2. run your largest realistic documents;
3. observe memory/CPU use during OCR and conversion;
4. add limits only after you understand peak behavior;
5. reduce parallelism or use the Ultra-Lite image if the host is genuinely constrained.

Do not size the server from idle usage alone.

Privacy and security boundaries

Self-hosting gives you control over where processing occurs, but it does not solve every document-security problem.

It does help with one important risk: you can keep files on infrastructure you control instead of uploading them to an unrelated online PDF service.

It does not protect documents from:

• an already-compromised browser or workstation;
• a compromised Docker host;
• weak administrator credentials;
• an exposed reverse proxy;
• insecure backups;
• accidental sharing after processing;
• flaws in the application or dependencies.

For highly sensitive documents, the host itself and the path used to access the service matter as much as the application.

Recommended setups

Personal homelab

• standard Docker image;
• login enabled;
• persistent /configs;
• private access over Tailscale/Headscale/NetBird or a VPN;
• custom OCR packs only when needed;
• normal backup of configuration and source documents.

Family or small-team internal service

• standard or Fat image depending on conversion needs;
• HTTPS reverse proxy;
• authentication enabled;
• persistent configuration and tested backups;
• resource monitoring if several users run OCR/conversion jobs concurrently.

Automation node

• server deployment rather than desktop-only mode;
• API/pipeline use;
• network access restricted to the systems that invoke it;
• pinned version where reproducibility matters;
• input/output retention handled by the surrounding workflow rather than assuming Stirling PDF is the archive.

When Stirling PDF is the wrong tool

Choose something else when:

• you primarily need permanent document archival and full-text search across thousands of records;
• you only edit PDFs occasionally on one computer and the desktop application is sufficient;
• your workflow requires professional collaborative PDF review features rather than self-hosted transformations;
• you need guaranteed preservation/compliance workflows that have not been independently validated for your requirements.

Bottom line

Stirling PDF is most compelling as a private, shared PDF-processing appliance for a homelab or small organization. Docker makes it straightforward to deploy, the server backend unlocks OCR and automation, and the range of PDF operations can replace many one-off web converters.

The sensible default is not to expose it widely. Run the standard image, persist /configs, keep login enabled, change the initial admin password, use TLS or a private overlay network, and treat your original documents and backups as a separate responsibility.

If the goal is document management rather than document transformation, pair it with software such as Paperless-ngx instead of trying to make one tool do both jobs.

Primary sources

• Stirling PDF documentation: https://docs.stirlingpdf.com/
• Docker installation guide: https://docs.stirlingpdf.com/Installation/Docker%20Install/
• Production deployment guide: https://docs.stirlingpdf.com/Production-Deployment-Guide/
• OCR documentation: https://docs.stirlingpdf.com/Functionality/OCR/
• OCR configuration: https://docs.stirlingpdf.com/Configuration/OCR/
• Login, system and security configuration: https://docs.stirlingpdf.com/Configuration/System%20and%20Security/
• Stirling PDF GitHub repository: https://github.com/Stirling-Tools/Stirling-PDF
• Paperless-ngx usage/document-management documentation: https://docs.paperless-ngx.com/usage/