VeneraX: a maintained fork of the Venera comic reader with WebDAV sync

What the fork changes, in the maintainer's own list

VeneraX is a fork of Venera, and the project documentation is explicit that it is maintained and enhanced for the maintainer's own needs, that the original project is venera-app/venera, and that the maintenance is AI driven with the development and upkeep carried out with tooling rather than by hand.

The feature list is a checked list, and it is worth reading as a list of gaps the upstream leaves. WebDAV backup and sync is optimised. Windows and Android APKs check for updates automatically. Continuous chapters read seamlessly. Local, follow and favourite handling is improved. There is a new task feature that supports background tasks and a view for them, and a change to how chapter reading state is recorded.

There is a night reading mode, background download on Android, background follow checks and comic import and export on Android, and a tray minimisation on Windows. There is a simple image quality enhancement feature, and a set of UI and interaction adjustments.

The list also has reading-later support, a configurable automatic cleanup of history, multi-device syncing of the WebDAV configuration information by scanning a code, long-press reordering of the main screen's custom function area, and multi-library management. A WebDAV comic library is marked experimental. The application lock gained a PIN code, a password and a gesture-based access. And there is a custom collections feature that merges multi-part and multi-volume comics into a single reading item, across sources.

That last one is the most interesting for a library that has grown organically, because it addresses a problem no reader app solves well, and the fact that it works across sources suggests the fork's author is dealing with a real, messy collection rather than a curated one.

The project is GPL-3.0 licensed, the primary language is Dart, the default branch is master, and the recent releases are v2.3.6 from 2026-10-09, v2.3.5 from 2026-10-08 and v2.3.4 from 2026-09-25, with the last push to the repository on 2026-10-19. The Flutter version in use is 3.44.3.

The AI translation pipeline, and what stays on the device

The translation feature is the one that needs the most careful reading, because it is the only part of the application that can send anything anywhere, and the project documentation is unusually precise about the boundary.

The feature is marked experimental: reading-time AI translation, where both the images and the OCR are processed on the machine, and only the recognised text is sent to an LLM configured by the user yourself. The provider support includes templates and model pulling for newcomers and advanced customisation, and there are three resource profiles, an economy one, a balanced one and a fast one. It also supports translating a whole chapter ahead of time, smart text removal and embedded text in restricted regions.

The privacy section restates the same boundary from the other direction. All the software's functions run on the user's own device, the project operates no server, collects no user data including reading content, extension lists and browsing history, and integrates no statistics, crash analysis or telemetry component. The optional AI translation is off by default, no provider, endpoint or key is preloaded, and after you enable it the recognised text goes only to the third-party model service you configured, with the maintainer neither touching nor controlling those requests or data. The optional offline translation engine downloads openly published model files with permissive licences from a repository you can configure, such as HuggingFace or a mirror.

That is a well-drafted position, and it is the one a self-hosted tool can actually honour. The distinction between the OCR running locally and the text being sent out is the one that matters, because the image is the copyrighted work and the recognised text is the part you asked to be translated.

The network reading capability is implemented in the form of a JavaScript extension API compatible with the original, so users can write or import extension scripts, and the project states plainly that the legality and accuracy of those extensions are the user's own responsibility, that requests go directly from the user's device to the target site, and that the software only provides local parsing, layout and display.

Building it yourself, and the part that trips every fork up

The build instructions are in the project documentation, and the local path is the standard Flutter one.

First install Flutter, then clone the repository and run flutter pub get, then build per platform:

flutter build apk        # Android
flutter build windows    # Windows
flutter build linux      # Linux
flutter build macos      # macOS

Android needs a signing key first, and the keytool invocation is given:

keytool -genkey -v -keystore venera.jks -keyalg RSA -keysize 2048 -validity 10000 -alias venera
base64 -w0 venera.jks    # macOS 用 base64 -i venera.jks

For a GitHub Actions build, the fork needs the workflows enabled, and a single run of the Build ALL workflow with a platform selection of windows, linux, macos, ios or android produces an artefact to download. Windows, Linux, macOS and iOS build without configuration but the artefacts are unsigned, so the iOS package is an unsigned ipa that has to be signed and sideloaded, and the macOS package is an unsigned and unnotarised dmg that has to be opened with a right click.

Android cannot be built without a key, so four secrets are added under the repository settings: ANDROID_KEYSTORE_BASE64 with the base64 output, ANDROID_KEYSTORE_PASSWORD, ANDROID_KEY_ALIAS and ANDROID_KEY_PASSWORD. A local build writes the same four values into android/key.properties, which is not committed.

Then there is the step that every fork gets wrong, and the documentation walks through it. If you distribute the build, you must change the two constants at the top of lib/pages/settings/about.dart:

const kUpdateRepoOwner = 'Kyosee';
const kUpdateRepoName = 'VeneraX';

Those two constants decide the update check, the update package download, the changelog and the repository link on the about page. If you leave them alone there are two consequences, and the documentation is specific about both. The application checks the maintainer's repository on startup, because the check for updates on startup is on by default, so your own version is never detected. And on Windows, a user who presses update immediately will have the maintainer's build installed over yours, which is the same as saying your version has been replaced with the maintainer's.

Tag-based releases, the signature continuity check, and the AltStore manifests

The release automation is described in enough detail to be useful to a fork, and one of the steps is a trap for anybody releasing from a fork.

Pushing a v* tag triggers a build for all platforms and creates a Release, and there are three things a fork has to handle first. The release notes files release-notes/<tag>.en.md and release-notes/<tag>.zh-CN.md must exist and be non-empty. The tag must equal the version in pubspec.yaml prefixed with v, ignoring anything after a plus sign. And the Android build step called Verify Android signature continuity compares the APK signature against the previous Release, which a fork without a Release history cannot satisfy, so that step fails, and because the Release depends on all platform builds succeeding, a single failure produces no artefacts at all. The documentation therefore says to delete that step before the first release.

That last point is a good illustration of how a well-run pipeline becomes a fork's first obstacle. The check exists to stop a maintainer from shipping an APK signed with a different key over an existing installation, which would break every user who had the old one, and it is a check that a fork has to remove rather than satisfy.

There are two other jobs mentioned. The Update_AltStore_* tasks commit the AltStore manifests back to master automatically, and they can be deleted if you do not want them, and the repository does carry altstore-source.json and altstore-source-beta.json. A private repository may not get the ubuntu-22.04-arm runner and the job will sit queued, and Build_Linux_ARM64 can be removed.

The migration guidance is short and worth repeating if you are coming from the original Venera: when you migrate, specify an independent directory for the WebDAV sync rather than sharing one with the original project, and back up the old data before migrating.

Where VeneraX is the wrong tool

The first limit is the bus factor, and the project states it rather than hiding it. The legal terms say the project is used for personal study and research, that the development and maintenance are AI driven, that it is a non-profit open source project, that the maintainer does not carry out commercial operations or authorise anyone to distribute it for a fee, and that the project may suspend, change or end development and release at any time without further notice.

For a personal reading app that is a reasonable arrangement, and for a reader who has spent years curating a library it is a real one. The releases come thick and fast, with three versions in October 2026, but a project that says in writing that it may stop is a project whose roadmap you cannot plan around.

The second is that the AI-driven development claim cuts both ways. It explains how a single maintainer can ship frequent updates across a feature list that long, and it also means the review of a change is a matter of tooling rather than a second pair of eyes. There is no community issue tracker culture to fall back on, and the legal terms are explicit that the maintainer does not handle issues or support requests that concern third-party site content, extension configuration, the availability of specific works or copyright attribution.

The third is the extension model. The network reading capability is a JavaScript extension API, which is flexible and is also the part most likely to break, because the extensions talk to sites that change their markup without notice, and the project does not guarantee compatibility with any third-party site, extension or service. A reader whose sources are stable will be fine, and a reader whose sources are a moving target will be doing maintenance on their own extensions.

The fourth is the translation feature's dependency chain. The optional offline engine downloads models from a public repository, which is a convenient arrangement and also a supply chain consideration, and the online path depends on a third-party model service whose terms, availability and pricing you do not control, and the maintenance terms say exactly that: the project does not guarantee that any function remains available.

And the fifth is the fork boundary itself. A modified version should be published under a distinguishable name and state in a visible place that it is a modified version, and the terms say that only the build artefacts from this repository's own Release page are published by the project, and that any package obtained through another channel is the responsibility of whoever provided it. That is a sensible legal position for a fork, and it is also a reminder that the artefacts you find on third-party mirrors are not the maintainer's.

Editorial conclusion

VeneraX is worth watching if you already use Venera, because the fork's value is concentrated in the parts the upstream leaves alone, with WebDAV backup and sync, a configuration transfer that does not need a server, and a translation pipeline that keeps image processing and OCR on the device and sends only recognised text to a model service you choose. It is the wrong tool if you want a community-backed reader, and the wrong tool if you want a turnkey build. Before you install or fork it, check three things: that you are comfortable with a single-maintainer project, since the legal terms state that the project may suspend, change or end development and release at any time without notice, and the recent releases are close together at v2.3.4, v2.3.5 and v2.3.6 in September and October 2026; that your build is signed by the same key as the published release, because a self-signed Android package cannot be installed over the published one and uninstalling clears the application data, which is why the project tells you to export a backup first; and that if you distribute a build of your own you change the two update constants in lib/pages/settings/about.dart, because otherwise the application checks for and installs the maintainer's releases over yours.

Frequently asked questions

Official sources

1. Kyosee/VeneraX on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases