Plexus: a crowdsourced map of which Android apps work without Google Play Services

A compatibility question with no authoritative answer

The project states its purpose in one line, in capitals and italics: remove the fear of Android app compatibility on de-Googled devices. The repository description says the same thing more plainly, and the homepage of the website is where the data can be browsed.

The problem it addresses is a specific and very real one. Google Play Services are essential components on most Android devices, they let you access your Google account seamlessly, and they provide Google-specific features for apps that depend on them. But when you flash custom ROMs without Google Play Services, or opt for alternatives like microG, certain apps may encounter issues, either not functioning at all or experiencing limitations in specific features.

That last clause is the hard part. The failure is not binary. An app might launch, might show its interface, and might fail at exactly one thing, like push notifications or location, and a simple works or does not work verdict cannot express that. So Plexus provides detailed insights into app compatibility whether you are using ROMs without Google Play Services, like LineageOS, or ROMs with microG, such as CalyxOS, and it helps you identify which apps work, which do not work, and which have limited features.

The last line of the Overview section is the model in one sentence: all the information is crowdsourced by the community, for the community. The repository topics name the ROMs in question, calyxos, grapheneos, lineageos and microg, alongside foss and phone, and the primary language is Elixir.

The last push was on 2026-07-14, the default branch is main, and the repository has no GitHub releases.

Two repositories, and only one of them takes contributions

The contributing section is short but it is the key to understanding the project, because Plexus is two codebases and the split determines where a contribution should go.

New pull requests related to the API or website can be submitted to the techlore/Plexus repository. To submit data, you use the Plexus app, which lives in a separate repository at techlore/Plexus-app, and the app is what you download to view and contribute data.

So the Elixir code in the main repository is the API and the website, and the Android app is a separate project that feeds it. That division exists for a practical reason. A compatibility rating is only meaningful if it comes from someone who actually has the app running on the ROM in question, and a person with a de-Googled phone is the one who can produce that rating, so the collection tool has to be an app on the phone. The website then serves everyone else, including people still deciding which ROM to flash.

The issue tracker follows the same split, with an explicit note that the issue tracker is for the API and website only, and that any issues related to the app should be reported in the Plexus-app repository. The README also states that the team encourages searching for existing issues before opening a new one, and that any duplicates will be closed.

The two are connected by an API whose documentation is published as a Swagger UI at the site, which means the app and the site are decoupled at the code level and joined at the HTTP level. That is a clean arrangement for a project whose data has to be submitted from a phone and consumed from a browser, and it also means the app can be updated independently of the API.

What a rating actually means, and where the Help page comes in

The README does not define the rating scale, and the reason is that the definitions live elsewhere. For that, the Help page instructs the reader to visit the Help page to familiarize yourself with all the indicators and to know how to submit ratings, and the FAQs page is where answers to common questions live.

That indirection is a real usability cost for anyone deciding whether to trust the data, and it is worth naming rather than glossing over. The Overview promises to tell you which apps work, do not work, or have limited features, but the criteria for the third category, limited features, and the scale used to express it are only in the wiki. A reader who has not read the Help page will see ratings without knowing what they are measuring.

It is also where the two ROM families come from, and that distinction is not cosmetic. The Overview names LineageOS as a ROM without Google Play Services and CalyxOS as one with microG, and the repository topics add GrapheneOS to the list of de-Googled ROMs. An app that runs fine on a ROM with microG, which implements a substantial part of the Play Services API, might still be broken on a ROM with nothing at all, and a rating from one does not transfer to the other. A compatibility database that flattened those into a single verdict would be less useful than one that keeps them apart.

The Help page is also where the submission procedure is described, and that is the other half of a crowdsourced dataset. The value of the whole project depends on people who already have the app installed on the ROM filling in the rating, and the project has an explicit invitation to view and contribute data through the app.

An Elixir service with Postgres, a release build and a Fly deployment

The repository is a conventional Elixir Phoenix-style service, and the infrastructure files describe it accurately.

The compose file brings up a single Postgres service, postgres:17.5, named plexus-postgres, with a restart policy of unless-stopped, a postgres user and password pair, the port mapped from 5434 on the host to 5432 in the container, and a named volume for the data directory. A single database with a named volume is the whole storage story, which is what you would expect for a relational dataset of app and rating records.

The Dockerfile is a two-stage build on the official Elixir images, and it explains its own choices in comments. The first comment says it uses Ubuntu and Debian instead of Alpine to avoid DNS resolution issues in production, which is the kind of note that saves a reader an afternoon. The Elixir and OTP versions are build arguments, ELIXIR_VERSION=1.19.5 and OTP_VERSION=28.5.0.2, with the Debian base as bookworm-20260623-slim, and the images come from the hexpm/elixir tag set and the plain debian image.

The build sequence is the standard Mix release flow, and each step is commented with its reason. The builder installs build-essential and git, runs mix local.hex and mix local.rebar, sets MIX_ENV to prod, copies mix.exs and mix.lock and runs mix deps.get, and then copies the config files before compiling dependencies, with a comment explaining that this is to ensure any relevant config change will trigger the dependencies to be recompiled. It copies priv, lib and assets, runs mix assets.deploy and mix compile, then copies config/runtime.exs afterwards, with the comment that changes to runtime.exs do not require recompiling the code, and finally copies rel and runs mix release.

The deployment target is a fly.toml file, so the service is set up to run on Fly.io, and there is a .tool-versions file for the toolchain and a .formatter.exs for Elixir formatting.

What the project is not, and the honest limit of a crowdsourced answer

The strongest limitation is the one implied by the whole design, so it is worth stating plainly. Every rating in the database was submitted by a community member, on their device, with their combination of ROM version, app version and microG state. Nobody at the project verifies that a rating was filed against the right configuration, and the project is candid that the information is crowdsourced by the community, for the community.

That has a direct consequence for how the data should be used. It is a strong signal when many people agree, and it is a weak signal when one person has filed a rating for an app that has since been updated, on a ROM build that has since changed, with a different microG implementation. It is a body of reports, not a test matrix.

The second limitation is coverage. A compatibility database is only as useful as its long tail. The popular apps will have many ratings because many people care about them, and the obscure app you are worried about will have one rating from a stranger, or none at all. Absence of a rating is not evidence of breakage, and the Overview's promise to help you identify which apps work is strongest for the apps the community has already looked at.

The third is that the project answers a question about one axis only. Whether an app runs without Google Play Services says nothing about whether it is worth running, whether it phones home through other channels, or whether it works on your specific hardware. It is a compatibility filter, and a useful one, but a narrow one. A reader who treats a green rating as an endorsement of the app has read more into the rating than it carries.

For a user who has already decided to de-google their phone, the value of Plexus is that it moves the trial and error from the install screen to a browser search, which for an app that takes 200MB and needs a login is a meaningful saving.

Where the project is heading, and who built it

The Future Plans and Goals section has a single item on it: support for recommended alternatives similar to alternativeto.net. That is a specific and readable statement of direction, and it also describes the obvious next step for a compatibility database.

The reasoning is straightforward. If the answer to will this app work is often no, then the useful follow-up question is what should I use instead, and a graph of applications with their alternatives, plus the compatibility data already collected, is exactly the shape of a recommendation engine. The project is small enough that this is a plausible thing to add rather than a rewrite, and the repository topics, which include foss, suggest the audience for such a thing is the same audience that is already filing ratings.

The credits section names the people behind the work. tomkonidas is credited with developing the API and the Plexus website. Henry, at henry-fisher, is credited with going forward with the project and designing and modifying some of the icons. Then the contributors, and then a line thanking everyone who has and continues to contribute data to make the project better than ever.

The privacy policy is committed to the repository as PRIVACY.md rather than being a web page, which is the right place for it in a project that collects device-reported data. The project is licensed under the terms of the GPL v3.0 license, with the file linked from the README. The repository also carries a CODE_OF_CONDUCT.md, a Dockerfile, a compose.yml, a fly.toml, and the usual Phoenix directories, config, lib, priv, rel and test, plus a test directory at the top level and an assets directory for the front end.

Editorial conclusion

Plexus fits someone switching to a de-Googled ROM who has a specific app in mind and wants to know whether it will run before installing it, and it does not fit someone who needs a definitive compatibility statement, because every rating in the dataset comes from a community member testing on their own device. Before relying on it, check the Help page for what the indicators and rating levels mean, and look for a rating for your exact ROM and app rather than a general one, because the project separates ROMs without Google Play Services such as LineageOS from ROMs with microG such as CalyxOS and the answers differ between them.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. Project website
4. README
5. techlore/plexus on GitHub