LANraragi: a Perl and Redis manga archive server for your own hardware

What LANraragi is for, and who ends up running it

The README opens with a one-line definition: an open source server for archival of comics and manga, running on Mojolicious and Redis. That is a narrower claim than it sounds. LANraragi does not download, rename or reorganise your files. It points at archives you already have and gives them a reading surface, a metadata layer, and a network endpoint.

The audience follows from that. Anyone with a folder of cbz files on a laptop can open them one by one in a comic reader. The problem appears at scale: hundreds of archives, no consistent naming, no way to search by artist, and no way to read them from a tablet or an e-reader without copying files around. LANraragi addresses the second half of that problem. It indexes what is there, extracts metadata through plugins, and serves pages out of the compressed files themselves.

The supported container list is broad and worth reading before you commit: zip, rar, targz, lzma, 7z, xz, cbz, cbr, cbw and pdf, with what the README calls barebones support for epub. If your collection is mostly epub, this is the wrong tool and the README says so by implication. If it is cbz and cbr, it is the intended case.

How the Mojolicious and Redis split actually works

Two processes do the work. Mojolicious serves the web interface and the HTTP endpoints. Redis holds the index: the archive records, their tags, categories, and the state the interface reads on each page load. The README describes the outcome of that split rather than the internals, but the repository layout confirms it, with lib/ holding the Perl application and a lrr.conf sitting at the top level.

The reading path is the part that differs from a plain file server. The README states that the server reads from within compressed files using temporary folders. Nothing is unpacked into your library directory for good. A request for a page pulls what it needs out of the archive and serves it, which is why a rar or 7z file can be read in the browser without a conversion step.

Metadata arrives through plugins. The README says plugins import metadata automatically when archives are added, and the interface exposes a plugin configuration page alongside the general one. Tags use namespaces, and the model also supports summaries, chapters and per-page overlays. That overlay feature is the one that separates it from a plain gallery: you can attach text to a specific page rather than to the archive as a whole.

Two endpoints matter for integration. The OPDS catalog lets dedicated reader software browse the library, and the README notes it now has PSE support. The Client API is the other, documented for external readers across many platforms. Between them, the web UI is optional for day-to-day reading.

Installing LANraragi with Docker and adding a first archive

The README links to a releases page and to a Homebrew formula, and the repository ships a Dockerfile under tools/build/docker/. The package.json exposes a docker-build script that builds the image as difegue/lanraragi, and the README's badge points at the published image on Docker Hub. For a NAS or server, the image is the shortest route.

Build it locally if you want to track the dev branch:

docker build -t difegue/lanraragi -f ./tools/build/docker/Dockerfile .

Running it means mounting two things: the archive directory and a volume for Redis data, so your tags survive a container restart. The README does not print a full run command, so treat the mount points as the thing to check against the documentation before you start.

If you would rather run it from source, the repository provides an installer script and a launcher. The installer is invoked through npm:

npm run lanraragi-installer
npm start

The start script runs perl ./script/launcher.pl -f ./script/lanraragi, and a development variant adds the -m and -v flags for the Mojolicious dev server. After the server is up, the first real task is pointing it at your archives and letting the plugins run. Add a folder of cbz files, and the plugin configuration page is where you check which metadata importers are enabled before you scan. The README states that metadata import is automatic on addition, so a badly configured plugin will write tags you then have to clean up. Configure first, scan second.

Where LANraragi stops being the right choice

The README is honest about the epub situation, calling the support barebones. If your library is epub-first, another tool will serve you better, and no amount of plugin configuration changes that.

The bigger limitation is that LANraragi is a viewer, not a manager. It does not move, rename or deduplicate files on disk. It can scan for duplicates within your saved archives, but that is a detection feature, not a cleanup one. Anyone expecting the server to impose order on a chaotic folder tree will be disappointed; the order has to come from tags and categories you assign, or from plugins that read your existing naming.

Redis is a hard dependency, not an optional cache. The index lives there, which is why the backup script exists and why the README lists JSON database backup as a feature for carrying tags to another instance. It also means a Redis volume you forget to mount is a library you rebuild from scratch. That is a real failure mode and the README does not document rollback or recovery beyond the backup path.

Finally, the README does not describe a mobile app. The related searches around an Android client point at a demand the project answers with OPDS and the Client API instead: you read through third-party software rather than a first-party client. That is a workable arrangement, but it is a different product shape than a phone app.

LANraragi against Komga: two answers to the same question

Komga is the comparison people reach for, and the difference is architectural rather than cosmetic. Komga is a JVM application with its own database and a REST API built around a comic and book model. LANraragi is Perl on Mojolicious with Redis behind it, and its identity is closer to an archive index than to a library management system.

The practical divergence is in how the two treat files. LANraragi deliberately reads inside compressed archives using temporary folders and leaves your directory structure alone. Its metadata model, with namespaces, categories and tankoubons, is layered on top of whatever you already have. Komga's model expects to own the library structure it presents.

If you want a server that reads your existing cbz and cbr collection in place and exposes it over OPDS, LANraragi's approach is a smaller commitment: point it at a folder, let plugins tag, read in the browser. If you want a system that manages series, volumes and reading progress as first-class objects, the Komga model fits that better. Neither is wrong. They disagree about whether the server or your filesystem is the source of truth. That disagreement is the whole decision.

Maintenance, licensing and the upgrade path

The repository is not archived, and the last push was on 2026-09-10. Releases are frequent enough to matter for planning: v.0.9.81, named Atomica, landed on 2026-07-06, three days after v.0.9.80, with v.0.9.71 before that on 2026-05-03. The cadence is uneven, which is normal for a project of this size, but it means pinning a version is more sensible than tracking latest.

The project is MIT licensed, and package.json states the same. In practical terms that permits commercial use, modification and redistribution provided the copyright notice and permission notice are included. This is not legal advice; read COPYING in the repository if the distinction matters to your situation.

The upgrade cost is dominated by the Redis index and the plugin set. The README offers a JSON backup as the way to carry tags to another instance, and package.json exposes a backup-db script that runs perl ./script/backup. Before upgrading, that is the concrete step: run the backup, then replace the image or the source tree. The README does not document a downgrade path, so a backup taken before the upgrade is the only recovery you have.

On the development side, the repository ships a test script (prove -r -l -v tests/), a Perl::Critic target, and a perltidy target. Contributing to the Perl code means meeting those, which is a lower barrier than it sounds if you already write Perl.

Editorial conclusion

Adopt LANraragi if you already keep cbz or cbr files on a NAS or home server and want a browser reader, OPDS access for external readers, and tag metadata that survives a move to another instance through the JSON backup. Do not adopt it if you expect a hosted service, a mobile app, or a library that manages files for you: the README describes an archive viewer, not a file organiser, and the interface is a web UI reached over your network. Before committing a real library, verify two things on your own instance: that the archive formats you actually hold are listed as supported in the README, and that the metadata plugins you need for your naming scheme are present in the plugin configuration page.

Frequently asked questions

Official sources

1. Difegue/LANraragi on GitHub
2. License: MIT
3. Project website
4. README
5. Releases