Komga's own Docker/JAR documentation says this is the reason to increase the Java maximum above its usual ~1 GB default.
Large libraries or workloads that exceed the default heap ceiling.Hardwarevereisten voor Komga: RAM, JVM, opslag en bibliothe scanbeurten
Leer welke vereisten Komga stelt aan RAM, Java, opslag en scans, hoe JVM-geheugen werkt en welke ZimaOS-hardware geschikt is voor strip- en mangabibliotheken.
Komga requirements at a glance
Komga does not publish a conventional CPU/RAM minimum. It runs on the JVM, and the official Docker/JAR documentation says the Java process is usually limited to about 1 GB maximum memory by default. That is a process limit, not a statement that Komga always consumes 1 GB or that 1 GB is the official hardware minimum.
- CPU
- No numerical CPU minimum is published. Komga can run on low-power systems, but scans, image analysis and large-library maintenance benefit from stronger CPU/storage performance.
- RAM
- No formal system-RAM minimum is published. The official Docker/JAR docs say the Java process usually has a default maximum around 1 GB; increase it if OutOfMemoryException appears.
- Java
- For JAR deployments, Komga currently requires Java 17+. The Docker image packages the required runtime.
- Database
- Keep the Komga database/config on a local filesystem. The official FAQ explicitly treats a non-local database filesystem as a problem.
- GPU
- Komga does not require a dedicated GPU. Its core workload is library indexing, metadata/image processing and serving pages.
- Best Zima starting point
- ZimaBoard 2 832 is a strong starting point for Komga. Its 8 GB RAM gives comfortable headroom above the usual ~1 GB Java maximum while leaving space for ZimaOS and other services.
From official requirements to the right setup
Komga sizing should separate JVM reservation behavior from real workload pressure.
-
Official requirements
Do not interpret the operating system's JVM reserved-memory figure as Komga's real working-set requirement. Komga's FAQ explicitly warns that JVM reservation behavior can make memory appear much larger than actual application use.
-
Confirm your needs
Use the official Java process limit as an operational clue: Docker/JAR deployments usually cap the process around 1 GB by default, and OutOfMemoryException is the signal to raise that ceiling.
-
Leave room to grow
Keep the database/config path on a local filesystem and map the library separately. Library moves or rescans can take time depending on collection size and storage performance.
-
Run it on ZimaOS
Install Komga from the ZimaOS App Store, complete an initial scan and reader test, then watch JVM errors, queued tasks and storage latency before increasing memory or moving to a larger server.
Check every playback client
- Size of comic/manga/ebook library
- Initial scan and rescan frequency
- Number and size of CBZ/CBR/EPUB/PDF files
- JVM maximum memory setting
- Presence of OutOfMemoryException in logs
- Local config/database path
- Library path performance
- Other ZimaOS containers sharing RAM and storage
Official minimum requirements
Komga's current documentation does not publish a numerical host CPU or RAM minimum. The most useful official memory figure is the default Java process maximum, usually around 1 GB.
Treat the ~1 GB figure as a JVM ceiling used by the packaged runtime, not as proof of actual memory consumption. Increase it only when real workloads produce OutOfMemoryException or sustained resource pressure.
| Requirement | Official minimum | What this supports |
|---|---|---|
| Host CPU | No numerical minimum published | Komga does not define a specific core count or clock speed in current official docs. |
| Host RAM | No formal system minimum published | Do not confuse JVM reservation with real application use. |
| Default Java max memory | Usually about 1 GB | Official Docker/JAR docs say the Java process is usually limited to this maximum by default. |
| When to increase memory | When OutOfMemoryException appears | Komga documents JAVA_TOOL_OPTIONS / -Xmx for raising the maximum. |
| Java for JAR installs | Java 17+ | Container users normally receive the required runtime inside the image. |
| Database location | Local filesystem | Komga's FAQ explicitly links to a local-filesystem requirement/check for the database. |
When to upgrade your hardware
Upgrade Komga when the JVM hits its configured ceiling, scans become unacceptably slow or the surrounding server stack needs more headroom.
The logs show OutOfMemoryException
Library maintenance keeps a long task queue
Komga shares the box with a larger media stack
Komga exposes pending activities in the UI. Large scans, analyses and library moves can be storage- and CPU-sensitive even if idle memory looks modest.
Large comic/manga archives or frequent imports.Java heap, filesystem cache, ZimaOS and other applications all need memory. Extra RAM is often justified by Plex/Jellyfin, downloaders, backups and indexers running beside Komga.
Multi-service home servers.Plan hardware growth with confidence
Scale Komga by controlling JVM memory and storage locality before buying unnecessary compute.
Keep the database local
Komga's FAQ includes a specific local-filesystem check for its database. Config/database reliability is more important than putting every file on the fastest storage.
Keep `/config` on reliable local storage; the bulk library can use larger HDD storage.Raise Java memory only when the workload proves it is needed
The official docs provide `JAVA_TOOL_OPTIONS=-Xmx...` or `-Xmx...` for increasing the ceiling after OutOfMemoryException.
8 GB host RAM already leaves substantial room for a 1 GB Komga heap plus ZimaOS; 16 GB is useful for larger multi-app stacks.Do not size from reserved JVM memory alone
Komga explains that the JVM may reserve a large portion of host memory without actually using it and can release memory when the OS needs it.
Use logs, OOM events and real task performance rather than a single OS memory-reservation number.Add multi-drive capacity when the library drives the upgrade
Comics and manga can consume substantial storage even though Komga itself is lightweight.
Move to ZimaCube 2 when integrated bays and archive growth matter more than application compute.Can it run on ZimaOS?
Komga is currently available in the ZimaOS App Store and fits a browser-accessed self-hosted library workflow.
Install Komga from the ZimaOS App Store
Map a persistent config path and the comic/manga library paths, then complete the initial claim and scan workflow.
Open Komga in the ZimaOS App StoreKeep config/database local
Komga's database should remain on a local filesystem. Put bulk library data on the storage layout that best fits capacity and access needs.
Read Komga FAQAdjust Java memory only after observing real errors
The official Docker guide exposes `JAVA_TOOL_OPTIONS=-Xmx...`; use it when the default maximum is genuinely insufficient instead of pre-allocating large amounts of RAM.
Read Komga Docker memory guidanceChoose Zima hardware for your Komga library
Komga's JVM makes memory accounting look more dramatic than it often is. Choose hardware from library scale, heap errors, storage growth and co-hosted services.
Is Komga primarily a reading server, or part of a larger multi-drive media stack?
The default Java ceiling is small relative to current ZimaBoard memory.
- Personal Komga serverZimaBoard 2 832
- Larger library plus more containersZimaBoard 2 1664
Integrated multi-drive capacity and broader application headroom become the reason to move up.
- Large multi-drive comics archiveZimaCube 2 Standard
- Heavier all-in-one server and 10GbE storage workflowZimaCube 2 Pro
The usual ~1 GB Java maximum is not a Komga host-RAM minimum or real-use benchmark. JVM reservation, library scale, file analysis and other containers can change observed memory behavior.
| Zima hardware | Best for | Example workload | Core configuration | Recommended boundary | Next step |
|---|---|---|---|---|---|
| ZimaBoard 2 832 | A personal Komga comic or manga library. | Normal scans, browser reading and light co-hosted services. |
|
If the Java process actually throws OOM errors or the server hosts many other apps, increase memory headroom rather than assuming the reserved JVM figure is real usage. | Get Now |
| ZimaBoard 2 1664 | A larger Komga library with additional ZimaOS applications. | More scanning, automation and co-hosted services on the same compact server. |
|
16 GB is for whole-server headroom; Komga does not publish a 16 GB requirement. | Get Now |
| ZimaCube 2 Standard | A large multi-drive Komga archive. | Large collections where integrated HDD/SSD capacity is the main upgrade reason. |
|
The Core i3 is not required by Komga itself. | Get Now |
| ZimaCube 2 Pro | A broader self-hosted media/storage environment containing Komga. | Komga plus backups, downloaders, media apps and fast local data movement. |
|
10GbE is valuable for storage workflows, not ordinary comic page delivery. | 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
These answers clarify Komga's JVM behavior so reserved memory is not mistaken for a hardware minimum.
How much RAM does Komga need?
Komga does not publish a formal host-RAM minimum. Its official Docker and JAR documentation says the Java process is usually limited to about 1 GB maximum memory by default.
Does Komga always use 1 GB RAM?
No. The ~1 GB figure is a maximum process limit, not constant consumption. Komga's FAQ also warns that JVM-reserved memory shown by the OS is not the same as actual application use.
When should I increase Komga memory?
The official guidance is to raise the Java maximum if you encounter OutOfMemoryException in the logs.
Can ZimaBoard 2 832 run Komga?
Yes. Its 8 GB RAM provides substantial host headroom relative to Komga's usual ~1 GB Java maximum, while also leaving memory for ZimaOS and other lightweight services.
Does Komga need Java?
JAR deployments currently require Java 17+. Docker users receive the runtime as part of the image.
Should Komga's database be on a NAS/network share?
Komga's official FAQ specifically treats the database as needing a local filesystem. Keep config/database local and mount the bulk library separately.
Does Komga need a GPU?
No dedicated GPU is required for normal Komga operation.
When should I choose ZimaCube 2 for Komga?
Choose it for integrated multi-drive archive capacity, more co-hosted services or faster local storage workflows, not because Komga itself requires a Core-class CPU.
What sources and further reading informed this Komga hardware guide?
Komga's official Docker and JAR installation pages are the primary memory sources because they document the usual ~1 GB Java maximum and how to raise it after OutOfMemoryException. The FAQ explains why JVM memory reservations should not be interpreted as real application use and confirms the importance of a local database filesystem. The project repository and ZimaOS App Store confirm the current application and deployment context. No current official page publishes a numerical host CPU or RAM minimum.
