VeneraNext: a cross-platform comic reader with local, WebDAV and JS extension sources
VeneraNext 是一个跨平台漫画阅读器,支持本地漫画、WebDAV 漫画源、第三方网络漫画源,支持 Android、iOS、Windows、Linux、macOS 平台。
At a glance
- What is it?
- VeneraNext is a Flutter comic reader for Android, iOS, Windows, Linux and macOS that reads local files, WebDAV directories and JavaScript extension sources. Its main bet is waterfall cross-chapter reading, and its main constraint is that the repository ships no sources at all.
- Who is it for?
- Adopt VeneraNext if you already have a comic library on disk, a NAS or WebDAV share, and you want one reader across desktop and mobile with waterfall cross-chapter scrolling. Do not adopt it if you expect the app to hand you sources: the repository states it does not provide, bundle, host or recommend any comic source, and source-site problems are out of scope for its issue tracker.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly Dart, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 19, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap VeneraNext fills between a file browser and a hosted reader
Most comic readers force a choice. Either they are local-only viewers that treat a folder of JPEGs as a flat list, or they are online readers that assume a server owns your library. VeneraNext sits in between. It is a Flutter application, built from Dart, that reads a local comic library, a WebDAV directory tree, downloaded chapters, and third-party network sources through a JavaScript extension API, all inside the same reader.
The intended user is someone with an existing collection. The README describes local import for single directories, batch directories, CBZ, ZIP, 7Z, CB7, PDF and image-based EPUB. It also describes a WebDAV comic library aimed at NAS, Nextcloud, ownCloud and similar servers. If your comics already live somewhere, this reader is designed to reach them rather than to replace them.
The project is a fork of venera, and the README is explicit that this branch is positioned for personal daily use, with the stated goal of reducing interruptions to reading. That framing matters: the feature list is organised around long serialised works rather than around catalogue management.
One boundary is stated in the README with unusual bluntness. The repository maintains the reader only. It does not provide, bundle, host or recommend any comic source, and the README asks users not to report source-site content, title availability or source-plugin problems to this repository. Whether that is a strength or a friction point depends entirely on whether you already know where your content comes from.
Waterfall reading, dual-page splitting and how the reader actually behaves
The default reading mode is waterfall, top to bottom. The README says the reader preloads the next chapter when you approach the end of the current one, so a long series reads as one continuous strip. Progress tracking records chapter, page and chapter group, and the README states that waterfall cross-chapter reading updates progress to the chapter you are actually in.
Gallery mode is the traditional paged reader, with selectable left-right or up-down direction. Continuous mode scrolls within the current chapter and does not cross chapter boundaries. That three-way split is a real design decision, not a settings dump: it lets you keep chapter edges when you want them and drop them when you do not.
Dual-page splitting is the feature worth understanding before you judge the reader. It applies only to vertical continuous and waterfall modes. It takes a wide two-page scan and rearranges it into two stacked vertical images, without changing the page count of the chapter. If the resulting order is wrong, a separate option swaps the split order. This is the mechanism that makes right-to-left and left-to-right double-page spreads readable in a scrolling layout, and it is a conversion applied at display time rather than a change to your files.
Chapter ordering is handled with a segmented control on the detail page, and the README says the direction is saved as a global preference. That is a small thing that removes a repeated adjustment every time you open a title.
Image preloading is adjustable. The README warns against setting it high on devices with little memory or that heat up under load, which is the honest version of that setting: it trades memory and thermals for fewer stalls on slow networks.
Installing VeneraNext and importing your first comic
There is no build-from-source instruction in the README for end users. Installation means downloading a build from the Releases page for your platform. On Windows, the README recommends winget and gives the package ID, which also covers upgrades.
winget install --id CyrilPeng.VeneraNext --exact
winget upgrade --id CyrilPeng.VeneraNext --exactAfter installation, the winget package is what you upgrade, not a manually downloaded file. The README notes that the winget public source can lag behind a new release while Microsoft reviews it, and that `winget source update` refreshes the local index. The portable zip build is not managed by winget and must be replaced by hand.
For Android, the README lists three APK variants: a universal build, an arm64-v8a build for 64-bit devices, and an armeabi-v7a build for older 32-bit hardware. It recommends the universal APK if you are unsure. iOS is an ipa sideloaded with AltStore. Linux offers a .deb or an AppImage, and macOS a .dmg.
Once the app is running, the first real task is choosing a source. For files you already have, the path is Local then Import. The directory layout the README shows is one folder per comic with images inside, optionally with a cover file.
漫画目录/
├── cover.jpg
├── 001.jpg
└── 002.jpgPage order comes from filename sorting, and the README recommends zero-padded names such as 001.jpg, 002.jpg and 003.jpg precisely because 1.jpg, 10.jpg and 2.jpg sort inconsistently across tools. When batch importing, select the parent directory that contains multiple comic folders, not one comic's internal chapter folder. That distinction is the most common way to end up with a single title containing everything.
PDF, EPUB and archive import: what converts and what does not
PDF import is a conversion, not a viewer. The README states that PDF pages are rendered to local JPEG images at import time, that the first page becomes the cover, and that the result is a comic with no chapters. Multiple PDFs can be selected and imported in sequence with file and page progress. A batch can be cancelled safely, completed comics are kept, duplicates or same-name files are skipped, and a single failure does not abort the run.
The cost is storage and fidelity. Imported PDFs and EPUBs occupy additional local space, and the reader reads the converted images, not the original file. For a large scanned PDF that is a meaningful duplication.
Image-based EPUB extraction follows spine order, preserves title, author, cover and chapter navigation where possible, and does not recompress the original images. The README lists what is unsupported: text-based EPUB, SVG pages drawn directly, encrypted PDF, and MOBI, AZW and AZW3. Those exclusions are worth reading before you plan a bulk import, because a text-based EPUB will not degrade gracefully into something readable.
CBZ, ZIP, 7Z and CB7 serve as import, export, backup, migration and distribution formats. An archive may contain images directly or one top-level directory, and if that directory holds chapter folders the app imports them as chapters. The README is clear that large archives are extracted and copied into the local library first, which makes them suitable for download-then-read or for moving a library between devices, and unsuitable as a streaming format. Imported local comics can be exported back to CBZ.
WebDAV as a comic library, and the three separate WebDAV configurations
The WebDAV comic library is configured at Settings -> App -> WebDAV Comic Library. It treats a server directory as an online library, which is the right shape for a NAS or a hosted drive. Plain image directories need no configuration file: the comic name defaults to the folder name, chapters are subdirectories, and when no cover.* exists the app tries the root first image, then the first readable chapter's cover or first image.
The README also describes an enhanced directory form, which is a CBZ export that has been unpacked and left as a directory tree. Compressed archives themselves are not previewed online. That is a deliberate limitation: the online path reads directories, and if you want archive reading you import or download first.
The part that will trip people up is that there are three independent WebDAV configurations, not one. Data sync, CBZ archive backup and restore, and the online comic library are separate setups. Configuring one does not configure the others. The README states this directly in the quick-start steps, and it is the kind of thing worth re-reading after you have connected a server and wonder why your reading history has not appeared on your second device.
Downloaded network-source chapters land in the local comic library, which is what makes offline reading and unstable networks workable. The queue and the update-following features sit alongside favourites and reading history.
The extension API is the ceiling and the floor of this reader
Network sources come from extensions that implement a JavaScript extension API. Once an extension is added, search, categories, rankings, an explore page, favourites and downloads become available, but only to the extent that the individual extension supports them. The README says entries such as categories, rankings, comments, ratings, archival download and login appear according to what the extension actually implements.
This is the honest architecture and also the main risk. The repository ships no source list. If a search returns nothing, a chapter list is empty, or images fail to load, the README points at the extension, the source site's state, your network, or your proxy settings. None of that is a bug in the reader, and the README asks you not to file it as one. For a user who wants a reader that works out of the box against known sites, that is the wrong tool, and no amount of reader polish changes it.
If a source requires login, cookies or site verification, the README says that is handled in the corresponding source's settings or login entry, not centrally. That decentralised model keeps the reader's scope narrow and keeps the project's legal surface small, but it pushes operational work onto you.
A second, quieter limitation is the local path. Import of large archives and PDFs is a copy operation with real disk cost, and the supported document formats exclude encrypted PDFs and text-based EPUBs outright. Neither limitation is hidden, but both shape what a migration actually costs.
How VeneraNext differs from venera, Komga and plain file browsing
VeneraNext is a fork of venera, so the comparison that matters most is with its own upstream. The README frames this branch around waterfall cross-chapter reading as the default, dual-page splitting with swappable order in the vertical modes, a segmented chapter-sort control whose state persists as a global preference, per-comic reading-time statistics with a history page showing totals and a ranking, and equal weight given to local comics and remote directories. Those are the stated differentiators. If none of them matter to you, upstream venera is the more conservative choice, and the README does not claim otherwise.
Against a server-first reader such as Komga, the split is architectural. Komga is a server: it owns the library, indexes it, and clients talk to it over HTTP. VeneraNext has no server component in the README at all. It reads your files directly, or reads a WebDAV directory you already run, or pulls from extensions. That means no indexing service to keep alive and no server to secure, but also no central metadata store, no shared library state across users, and no web client. If you want a library that several people browse from a browser, this is the wrong shape.
Against simply browsing a folder, the differences are the ones that justify an application: cross-chapter preloading, dual-page handling, progress that survives across devices through WebDAV sync, and a download queue for offline reading. A file browser does none of those, and a PDF reader does one of them badly.
Maintenance, licence and what an upgrade actually costs
The repository is not archived, and its last push was on 2026-09-16. Recent releases are close together: v1.14.3 on 2026-08-25, v1.14.4 on 2026-08-28, and v1.15.0 on 2026-08-31. The project ships a CHANGELOG.md, and the README points to it for the full record, which is the right place to look before upgrading rather than release notes alone.
Upgrade cost depends on how you installed it. On Windows via winget, the same package ID upgrades in place, with the caveat that the public source can lag a release while Microsoft reviews the manifest. The portable zip is not managed and must be replaced manually. On Android, iOS, Linux and macOS the upgrade is a new artifact from Releases, and for iOS that means sideloading again through AltStore. There is nothing in the README about in-application update checking, automatic migration of the local library between versions, or rollback. If you depend on a specific version, keep the installer or archive you installed from, because the README does not document a downgrade path.
The licence is GPL-3.0, stated in the README and present as a LICENSE file at the repository root. That matters if you plan to redistribute a build, bundle it into a product, or ship a modified version: GPL-3.0 carries source-availability obligations that permissive licences do not. This is not legal advice, and the obligations depend on what you actually do with the code and the binaries. If redistribution is part of your plan, read the licence text and get proper advice.
The README also links a Gitee mirror and states the repository maintains only the reader. Contributions are covered by CONTRIBUTING.md and CONTRIBUTING.en.md, and there is a SECURITY.md for reporting.
Editorial conclusion
Adopt VeneraNext if you already have a comic library on disk, a NAS or WebDAV share, and you want one reader across desktop and mobile with waterfall cross-chapter scrolling. Do not adopt it if you expect the app to hand you sources: the repository states it does not provide, bundle, host or recommend any comic source, and source-site problems are out of scope for its issue tracker. Before committing, verify that your existing directory naming survives the filename sort, that your PDFs are not encrypted and your EPUBs are image-based rather than text-based, and that your platform build is present in Releases for the version you want. The GPL-3.0 licence is the other thing to check before you fork or redistribute a build.
Start by importing one folder of images and confirming page order, then add a WebDAV comic library at Settings -> App -> WebDAV Comic Library. If either step fails, the extension API and the sync features will not fix it.
Frequently asked questions
Does VeneraNext include any comic sources?
No. The README states that the repository maintains only the reader and does not provide, bundle, host or recommend any comic source. Sources must be configured by the user, and the README asks that source-site content or plugin problems not be reported to this repository.
How do I install VeneraNext on Windows?
The README recommends winget with the exact package ID CyrilPeng.VeneraNext, and the same ID is used for upgrades. A Windows installer .exe and a portable zip are also published in Releases, though the portable build is not managed by winget and needs manual replacement.
Which file formats can VeneraNext import as local comics?
The README lists single directories, batch directories, CBZ, ZIP, 7Z, CB7, PDF and image-based EPUB. Text-based EPUB, encrypted PDF, directly drawn SVG pages, and MOBI, AZW and AZW3 are not supported.
Can VeneraNext read comics from a NAS or WebDAV server?
Yes. The WebDAV comic library is configured at Settings -> App -> WebDAV Comic Library and reads a server directory as an online library, aimed at NAS, Nextcloud, ownCloud and similar services. Compressed archives are not previewed online; the online path reads directories.
What reading modes does VeneraNext offer?
The README describes waterfall (top to bottom), gallery (traditional paging with selectable direction) and continuous (scrolling within the current chapter without crossing chapters). Waterfall is the default and preloads the next chapter near the end of the current one.
Community notes