Measure representative job duration and CPU use, then adjust native process limits to available capacity.
Frequent scanned PDFs and batch conversion.Configuration matérielle requise pour Stirling-PDF : RAM, processeur, stockage et OCR, JVM et tâches de conversion
Planifiez les ressources mémoire, processeur et JVM pour Stirling-PDF, ainsi que la marge nécessaire, les conversions OCR et Office, en suivant les recommandations officielles de dimensionnement des images et les conseils pratiques sur le stockage et le matériel ZimaOS.
Stirling-PDF hardware requirements at a glance
Stirling-PDF sizing depends on image capabilities and concurrent PDF jobs. The current Docker guide suggests different memory budgets for the default, fat and ultra-lite images; OCR, Office conversion and optional AI change the workload.
- RAM
- Current Docker guide suggests 4 GB for latest, 6 GB for latest-fat (more with AI enabled), and 2 GB for latest-ultra-lite. These are image-specific suggestions, not a universal host minimum.
- CPU
- OCR, Office conversion and concurrent jobs determine CPU demand; time representative documents rather than using an idle dashboard or a user count as a CPU benchmark.
- Storage
- Official performance reference for 1–10 users: 10 GB. Add stored documents, temporary processing space, OCR languages, logs and backups according to workload.
- JVM / native tools
- Set a container memory budget that leaves room for native OCR/conversion tools as well as Java and other host services.
- Image features
- Current registry: docker.stirlingpdf.com/stirlingtools/stirling-pdf; amd64 and arm64 images. Persist /configs and /storage, plus enabled optional paths.
- Best Zima starting point
- ZimaBoard 2 832 is a candidate for occasional standard-image jobs with controlled concurrency. Choose 1664 for more memory headroom or ZimaCube 2 Pro for sustained CPU-heavy OCR/conversion.
From official requirements to the right setup
Plan the complete Stirling-PDF workload before selecting a server.
-
Official requirements
Choose the image by required tools: standard, fat or ultra-lite. Apply the suggested allocation for that variant and preserve the difference between production guidance and a universal minimum.
-
Confirm your needs
Test representative documents, page count, resolution and simultaneous jobs. A small compressed PDF can expand greatly in memory when rendered; file upload size alone is not peak memory.
-
Leave room to grow
Persist /configs and /storage, plus branding, pipeline and OCR-language paths when used. Allow temporary working space and independent backups of settings, keys, users and retained files.
-
Run it on ZimaOS
Custom install the official image in ZimaOS, map a free host port to 8080 and set an explicit container memory limit with host headroom. Keep native-tool concurrency within CPU/memory capacity and validate the selected features.
Check every playback client
- Standard/fat/ultra-lite feature choice
- Image-specific memory allocation
- Container limit and JVM/native headroom
- Largest PDF page count and resolution
- Concurrent OCR/conversion jobs
- Persistent /configs and /storage
- Temporary space and OCR language data
- Unused web port mapped to 8080
Official minimum requirements
Reviewed October 30, 2026 against the linked upstream deployment documentation. Numerical values retain their stated minimum, recommendation or example scope; select release-compatible instructions before installation.
Choose the image according to needed tools, leave host headroom beyond its suggested memory, and measure real jobs. Optional AI and large conversions have separate peaks.
| Requirement | Official minimum | What this supports |
|---|---|---|
| Suggested memory by image | Current Docker guide suggests 4 GB for latest, 6 GB for latest-fat (more with AI enabled), and 2 GB for latest-ultra-lite. These are image-specific suggestions, not a universal host minimum. | Do not confuse these suggestions with an immutable runtime minimum. |
| Default image functions | OCR, Office and other converters; 4 GB suggested | Concurrent conversion jobs may need more headroom. |
| Fat image | Bundled AI engine; 6 GB suggested, more when enabled | The AI engine is off until explicitly enabled. |
| Ultra-lite image | Core PDF tools; 2 GB suggested | No OCR, Office, HTML or ebook conversions. |
| Persistent volumes | Always mount /configs and /storage | Also persist optional pipeline, branding, log and language data when used. |
When to upgrade your hardware
Use observed Stirling-PDF workload pressure to decide when an upgrade is warranted.
OCR or Office conversions block the queue
Jobs fail or the container is OOM-killed
Temporary files or retained storage fill the disk
Inspect total/native memory and JVM heap headroom; reduce concurrency or heap share before increasing limits beyond host capacity.
Large PDFs, rendering and simultaneous jobs.Budget peak expanded working data plus stored files/logs and backup retention; a small input can require substantial working space.
PDF-to-image, compression and retained document workflows.Plan hardware growth with confidence
Address storage, memory, compute and deployment limits separately.
Keep active files and temp work on suitable storage
Use enough SSD space for peak processing and persistent settings/files.
ZimaBoard 2 with SATA/PCIe SSD.Add host memory for simultaneous jobs
Choose 16 GB when standard/fat allocation plus OS and companion services pressures the smaller host.
ZimaBoard 2 1664.Expand document and backup retention
Size stored files and pipeline results independently of the image footprint.
Additional SSD; larger storage platform only for deliberate archive growth.Increase CPU for sustained conversion
Choose stronger compute when OCR/conversion remains CPU-bound after correct process and memory settings.
ZimaCube 2 Pro.Can it run on ZimaOS?
No specific public official one-click Stirling-PDF ZimaOS app page was verified. Use Custom Install with the upstream-recommended Docker image and explicit resource/persistence settings.
Custom install Stirling-PDF in ZimaOS
Use the official registry image or documented mirror, choose the intended variant, persist /configs and /storage, map port 8080 and set a memory limit that leaves host and native-tool headroom.
Custom install Stirling-PDF in the ZimaOS app ↗Use the official Stirling-PDF deployment instructions
Keep the selected stable release, persistent paths and companion services aligned with upstream documentation.
Review Stirling-PDF official installation ↗Apply workload-specific performance guidance
Review image sizing, document job costs, JVM heap allocation and native conversion-process limits before increasing concurrency.
Review Stirling-PDF deployment details ↗Which Zima hardware fits Stirling-PDF?
Start with the lowest reasonable host for the actual workload. Product specifications were checked against the current product pages.
Which workload best matches your Stirling-PDF deployment?
Occasional PDF edits and controlled conversions
Start with explicit memory limits and modest job concurrency.
- Workload optionZimaBoard 2 832
- Workload optionZimaBoard 2 1664
Sustained OCR or multi-user conversion
Use stronger CPU with adequate native-tool memory headroom.
- Workload optionZimaCube 2 Pro
These are practical workload recommendations, not official app requirements, compatibility certification, measured capacity limits or performance guarantees. Include all co-hosted services and independent backups.
| Zima hardware | Best for | Example workload | Core configuration | Recommended boundary | Next step |
|---|---|---|---|---|---|
| ZimaBoard 2 832 | Occasional PDF processing | Standard image with controlled concurrent jobs and suitable file storage. |
|
A 4 GB container allocation must still leave OS/other-app headroom; large PDFs can exceed that job budget. | Get Now |
| ZimaBoard 2 1664 | More memory for conversion jobs | More room around standard/fat image allocations and native tools. |
|
The same four-core N150 remains, so sustained OCR can still be CPU-bound. | Get Now |
| ZimaCube 2 Pro | Sustained OCR and conversion | More CPU headroom for document processing and broader app consolidation. |
|
No job-duration guarantee; document complexity, memory settings and process limits still matter. | Get Now |
What the Press Says
Highlights from trusted reviewers worldwide.
“ZimaCube 2: Not just another NAS, tested with 25TB storage, local AI agents, 4K transcoding, and real homelab workflows.”Read full review
“The ZimaBoard 2 is a compact x86 server board that can be turned into a mini NAS, home server, media box, or self-hosting hub.”Read full review
“ZimaCube 2: A modern, high-performance NAS with plenty of room to grow—built for users who want more than basic storage.”Read full review
“Coverage focused on ZimaCube 2's open hardware foundation, no monthly fee, and self-hosting flexibility.”Read full review
Loved by the Community
Stories and reviews from people who build with Zima every day.
★★★★★
Zima Blade Little yet Powerful
Maybe I am not digital natives but I live with PCs since 12 years old in 1984 when IBM PC clone come to my home. Many years have passed and many operating system I've tried. For me Zima blade and CasaOS was a quantum leap for home PC enthusiast and server lab machine to make me stay curious and relevant for this era.
★★★★★
Very good!!
I use ZimaCube Pro as 5th Proxmox cluster node. It runs several VMs and containers, including a VM with GPU passthrough to run a self-hosted LLM. A specific LXC container runs a Samba server for NAS capabilities using four of six RAID 6 SATA HDDs with ZFS.
★★★★★
Great innovation for mini server!
It is very useful and makes a powerful mini server for many purposes, including university and college students in engineering and electronics. Thank you so much for making this server.
★★★★★
Avaliação ZimaBoard 2
Construí um servidor de uso pessoal. O desempenho está muito bom e funciona perfeitamente onde quer que eu esteja. A surpresa é não dependermos de grandes estruturas para termos nosso próprio servidor de dados. Como iniciante, estou gostando bastante do ZimaOS, pois ele é simples e eficiente.
Frequently asked questions
Answers to Stirling-PDF RAM, CPU, storage, Docker, database and ZimaOS sizing questions.
How much RAM does Stirling-PDF need?
Current Docker guide suggests 4 GB for latest, 6 GB for latest-fat (more with AI enabled), and 2 GB for latest-ultra-lite. These are image-specific suggestions, not a universal host minimum.
How many CPU cores are recommended?
OCR, Office conversion and concurrent jobs determine CPU demand; time representative documents rather than using an idle dashboard or a user count as a CPU benchmark.
Which image should I choose?
Use latest for the standard OCR and conversion tools. latest-fat adds an optional AI engine; latest-ultra-lite omits OCR, Office, HTML and ebook conversions. The current Docker guide explains the registry and persistent paths.
How much disk space should I reserve?
The 1–10-user performance reference lists 10 GB, but include temporary expansion, saved documents, language packs, logs and backups. Large rasterized PDFs can need far more working space than compressed upload size.
Does Stirling-PDF require a GPU or external SQL database?
Normal PDF processing does not require a dedicated GPU or mandatory external SQL service; /configs includes the built-in database. Optional AI/other deployment choices have their own requirements and must be sized separately.
Can ZimaBoard 2 run Stirling-PDF?
It is a practical candidate for controlled, occasional processing with an appropriate image allocation and storage. The 16 GB variant offers more memory headroom, but both share the same N150 CPU.
Why should Java heap be smaller than the container memory limit?
LibreOffice, Tesseract and other native tools consume memory outside the Java heap. Leave room for those processes within the container budget and follow the selected image release settings; allocating all memory to Java can cause native jobs to fail.
When should I choose ZimaCube 2 Pro?
Choose it for measured sustained OCR/conversion CPU pressure or wider consolidation. First validate memory limits, native-tool headroom and process concurrency so the upgrade addresses the actual bottleneck.
What sources informed this Stirling-PDF hardware guide?
This guide was reviewed against the linked project deployment documentation on October 30, 2026. Zima device choices are editorial workload guidance, separate from upstream requirements and measured performance.
