# Patch Bundle Registry: one catalog for ReVanced, Morphe and Reseam patch sources

> A searchable index of community patch bundles for Android app managers, with a read-only REST and GraphQL API, compatibility lookups by package name and version, historical releases, and honest per-patch-list status labels. The binaries stay with their publishers, and the registry only stores metadata.

**Jman-Github/Patch-Bundle-Registry** — Patch bundle registry for ReVanced, Morphe, and Reseam, with searchable patches, app compatibility, historical releases, prereleases, and changelogs retrievable through a REST and GraphQL API plus a user friendly frontend.

- Repository: https://github.com/Jman-Github/Patch-Bundle-Registry
- Website: https://patch-bundles.jmancentral.com
- Stars: 713 · Forks: 43
- Language: Python
- License: Unlicense
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/jman-github-patch-bundle-registry

## The catalog indexes metadata, not binaries

The Patch Bundle Registry brings ReVanced, Morphe, and Reseam patch sources together in one searchable catalog. The project description lists the capabilities: searchable patches, app compatibility, historical releases, prereleases, and changelogs retrievable through a REST and GraphQL API plus a user friendly frontend.

The single most important architectural fact is stated plainly in the data section. The registry stores metadata, and bundle binaries remain hosted by their publishers.

That distinction shapes everything else. The catalog knows that a source published a bundle, what version it was, what patches it contains, what apps it claims compatibility with, and what its changelog said. It does not mirror the artefacts. So a bundle URL copied from a card points at the publisher's own hosting, and if the publisher removes a download, the saved asset URL may stop working. The registry is a directory, not a distribution point.

The audience is developers and tinkerers who use more than one of the three managers, or who follow a source that publishes across several of them. The homepage is patch-bundles.jmancentral.com, and the readme links a browsable catalog, an API docs page, an API reference document, and an issue tracker for suggesting a source.

The project is a Python primary language repository with a JavaScript component, and it is released under the Unlicense, with one exception that is worth knowing about: the adapted website files use GPL-3.0-only, with the attribution recorded in docs/source-attribution.md.

## Compatibility is looked up by package name and version fragment

The compatibility mechanism is the part of the catalog that saves the most time, and it accepts three increasingly precise forms of query.

You can use the package filter with an app's package name, such as com.google.android.youtube, or an app-version fragment such as 19.16, or an exact combination like com.google.android.youtube@19.16.39.

That progression is the whole design. A package name narrows it to one app, a version fragment narrows it to a range of builds, and the exact combination pins a single build. So the same filter answers three different questions: which bundles touch this app at all, which of them cover my build, and which one covers exactly this build.

The rest of the filtering is by release attributes. You choose a release using the source, version, bundle format, and release filters, and there is a dedicated Apps browser that shows app names, package names, icons, and compatible bundles across matching releases.

App names and icons are the part with an interesting provenance. They come from cached F-Droid and IzzyOnDroid JSON indexes, then regional Google Play listings, and unlisted apps fall back to using their package names. So the catalogue can show you a friendly name and an icon for an app that is not in any store index, by way of the Play listing for that region, and when nothing is available it degrades to the package identifier rather than showing a blank.

The practical consequence for a user is that the compatibility data is assembled from public sources and can be incomplete, which is why the catalog also tells you the status of each patch list.

## Verified, unverified, stale and missing are the four honest answers

Most catalogs of this kind would just show you a patch list. This one tells you how much to trust it, and that is the feature that makes the catalog usable rather than merely searchable.

Patch lists display their status: verified, unverified, stale, or missing. A verified list was extracted from its matching bundle. An unverified or stale list may still help you explore patches, but may not describe the selected release accurately.

The distinction is a direct consequence of the metadata-only architecture. A patch list can be extracted from the bundle artefact itself, which is what verified means, or it can be reconstructed from the publisher's published patch index, which is what unverified means, and that reconstruction may correspond to a different release than the one you are looking at, which is what stale captures. Missing covers the case where the list could not be recovered at all.

The readme is candid about the cause. Older patch lists may remain missing when their artifacts cannot be extracted, and a recorded release can have a missing patch list. Historical coverage depends on available upstream releases and successful metadata extraction.

So the catalogue is explicit about its own uncertainty rather than presenting a uniform answer. For a user choosing a patch, that is the difference between a listing you can act on and one that is decoration, and it is the reason the status label belongs in the interface rather than in a footnote.

## Copy a remote bundle URL, and pick the format your manager understands

The workflow the readme describes is short enough to be the whole user experience.

Open the catalog and find a source. Choose a bundle format your manager supports. Click Copy remote bundle URL and paste it into your manager's patch source settings. For Reseam bundles, the instruction is to click the link icon and choose Registry URL (URV) or Reseam Manager JSON.

The formats are named explicitly. ReVanced formats appear as ReVanced v21 and ReVanced v22, and Morphe bundles appear as Morphe. ReVanced v21 and Reseam bundles require their respective runtime plugins when used in URV, which is a real constraint rather than a footnote, because a manager that does not have the plugin loaded cannot use those bundle formats in that mode.

The Reseam Manager JSON choice returns the publisher's complete patches.json index with its patch IDs, release history and release notes, whereas the Registry URL choice keeps the existing import format. That is a difference in what you get, not in how you install it, and it matters if you are scripting against the source rather than importing by hand.

The default remote URL follows new releases in the selected channel, so a manager left pointing at it keeps up with the publisher. If you want a fixed version, you select a historical bundle version and copy a URL pinned to that version, which is the mechanism that lets you test against a known state or reproduce a setup later.

## Channels, historical releases and where the data comes from

The release channels are simple and the differences are worth stating because they decide what you install.

The Latest channel gives you the newest release, including prereleases. Stable gives you the newest regular release. Dev gives you the newest prerelease. Some sources do not publish every channel, which is a property of the publishers rather than of the registry.

Sources can come from GitHub, GitLab, Codeberg, Gitea and supported self-hosted servers. That list is the interesting part, because the set of patch ecosystems has moved well past GitHub, and a registry that only knew about GitHub would miss a large share of what is out there.

On history, the readme is careful. The catalog indexes patch sources, bundle versions, patch descriptions and options, and app compatibility, with release metadata that includes stable and prerelease status, original changelogs, and public asset links.

Historical coverage is explicitly conditional. It depends on available upstream releases and on metadata extraction having succeeded, so a recorded release can have a missing patch list and a saved asset URL can stop working if the publisher removes the download. The historical API reference at docs/catalog-api.md provides paginated access to release inventories and retained patch and application metadata, and the readme notes that those historical endpoints require a deployment with that API enabled, with availability separate from the standard catalog endpoints.

That last sentence is a deployment detail that decides whether you can use the feature at all, and it is the kind of thing that is easy to miss and hard to debug.

## The API side, and the two runtimes behind it

For anyone building a manager or another integration, the catalogue exposes a read-only REST and GraphQL API for sources, bundles, patches, and app compatibility, documented at docs/catalog-api.md. You can explore requests in Swagger UI at the api-docs path, or GraphiQL at the graphiql path. You can subscribe to catalog changes over WebSockets, and there is a way to check refresh-job status while an update runs.

The implementation is split across two runtimes, and the tree explains why. There is a Python side with pyproject.toml, requirements.txt, a bundle-parser directory, a shared directory, a worker directory, a schemas directory, a scripts directory and a config directory. There is a JavaScript side with package.json, a web directory, and a node test script.

The JavaScript package.json shows the Cloudflare Workers toolchain. The worker is developed with wrangler dev against worker/wrangler.jsonc, deployed with wrangler deploy, and there are separate scripts to test the live worker and to test it against a D1 database. The dev dependency on miniflare and the graphql package at ^16.11.0 are the two things you would expect for a worker that serves a GraphQL API.

The Python side is the metadata pipeline. The tooling is pinned and conventional: black and ruff at line-length 100 targeting Python 3.11, pytest for tests, mypy with disallow_untyped_defs and warn_return_any, and jsonschema for validating the data it fetches. The requirements file lists httpx for the HTTP client and the same linting and typing tools:

```bash
httpx>=0.25.0,<1
black>=24.4.0,<25
ruff>=0.5.0,<0.6
pytest>=8.2.0,<9
mypy>=1.10.0,<2
jsonschema>=4.21.0,<5
```

So the split is a Python ingestion and extraction pipeline feeding a JavaScript worker that serves the API and the site. The Python code fetches and parses bundle metadata; the worker serves it.

## Where the catalogue is the wrong tool

There are situations where this registry is more than you need, and one where it will disappoint you.

The first is a single source and a single manager. If you follow one ReVanced source and use one manager, the work this catalogue saves you is one bookmark and one URL you already had. The value here is in the index across sources, formats and versions, and that value only appears when you have several.

The second is when you need the artefact itself. The registry stores metadata and the binaries remain with their publishers, so a bundle URL points outward and a publisher who removes a download leaves a dead link behind. If your workflow depends on having the artefact archived, this is the wrong model, and an archive of the artefacts themselves would be a different project.

The third is data freshness and coverage. Historical coverage depends on available upstream releases and successful metadata extraction, and older patch lists may remain missing when their artifacts cannot be extracted. The compatibility data is assembled from cached F-Droid and IzzyOnDroid indexes plus regional Google Play listings, so it inherits their gaps. For an app that is not in those indexes and is not listed in a Play region, you are down to the package name as the display name.

The fourth is the historical API. Those endpoints require a deployment with that API enabled, so availability is separate from the standard catalog endpoints. If you are evaluating against the public deployment, do not plan around the history endpoints until you have confirmed they are on.

And the fifth is the practical reality of a patch catalogue built on other people's bundles. The registry cannot vouch for a patch, only for what it managed to extract. The status labels are the honest boundary, and a verified label means the list was extracted from the matching bundle, not that the patches inside are safe.

## Conclusion

Adopt the Patch Bundle Registry if you run several patch managers and want one place to search bundles, check whether a patch supports your app version, and copy a remote bundle URL without tracking each source by hand. Skip it if you have one source and one manager, because the value is in the cross source index. Verify first that your app version appears in the compatibility data, since a patch list can be missing, stale or unverified, and check the status label on the patch list before you rely on it to describe a specific release.

## FAQ

### What is the Patch Bundle Registry?

It is a searchable catalog that brings ReVanced, Morphe and Reseam patch sources together, with app compatibility checks, historical releases, prereleases and changelogs, exposed through a read-only REST and GraphQL API and a web frontend.

### How do I check whether a patch bundle supports my app version?

Use the package filter with an app's package name such as com.google.android.youtube, an app-version fragment such as 19.16, or an exact combination like com.google.android.youtube@19.16.39. You can also browse the Apps view to see compatible bundles across matching releases.

### What do the verified, unverified, stale and missing patch list statuses mean?

A verified list was extracted from its matching bundle, while an unverified or stale list may still help you explore patches but may not describe the selected release accurately. Missing means no list could be recovered, which happens when the artifacts cannot be extracted.

### How do I add a bundle from the registry to my patch manager?

Find the source in the catalog, choose a bundle format your manager supports, then click Copy remote bundle URL and paste it into your manager's patch source settings. For Reseam bundles you pick Registry URL (URV) or Reseam Manager JSON instead, and ReVanced v21 and Reseam bundles need their runtime plugins when used in URV.

### Which release channels does the registry expose?

Latest gives the newest release including prereleases, Stable gives the newest regular release, and Dev gives the newest prerelease. Not every source publishes every channel, and historical bundle versions can be selected to copy a URL pinned to that version.

### Does the registry host the patch bundles themselves?

No. The registry stores metadata, and bundle binaries remain hosted by their publishers, so a saved asset URL may stop working if a publisher removes the download. The project is released under the Unlicense, with the adapted website files under GPL-3.0-only.

## Sources

- [Issues](https://github.com/Jman-Github/Patch-Bundle-Registry/issues)
- [Jman-Github/Patch-Bundle-Registry on GitHub](https://github.com/Jman-Github/Patch-Bundle-Registry)
- [License: Unlicense](https://github.com/Jman-Github/Patch-Bundle-Registry/blob/bundles/LICENSE)
- [Project website](https://patch-bundles.jmancentral.com)
- [README](https://github.com/Jman-Github/Patch-Bundle-Registry/blob/bundles/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jman-github-patch-bundle-registry