Molly's source code: public, open, and checkable

Published: October 7, 2026 · Updated: October 8, 2026

Molly is an independent, open-source fork of the Signal Android app (not official Signal), and all of its code is public. That matters because a messenger you trust with private conversations should have nothing to hide in its code. Molly goes one step further than just publishing source: its builds are reproducible, which means anyone with the right tools can rebuild the app from the public code and confirm the result matches the APK published on molly.im. This page explains where the code lives, what reproducible builds actually prove (and what they do not), and how to verify things through Molly's own documentation rather than taking anyone's word for it.

What "open source" means for Molly

"Open source" gets thrown around a lot, so let us be precise about what it means here. Every line of Molly's app code is published where anyone can read it, download it, and study it. There is no hidden part of the app, no closed component you have to take on faith. If you have the skills, you can read exactly what the app does with your messages, your contacts, and your encryption keys.

This openness is inherited, not invented. Signal's own Android client is published under an open-source license (AGPLv3), which is what legally allows a fork like Molly to exist at all. Molly builds on that open foundation and keeps its own changes public the same way. That chain matters: the code you are trusting did not start life in a black box.

One honest note before we go further. "Open" does not mean "audited by thousands of experts." Most open-source projects are read carefully by a small number of people, not a crowd. What openness gives you is not a guarantee. It is a possibility: anyone can check, and the fact that anyone can check changes how developers behave. A developer who knows the code is public writes different code than one who knows nobody will ever see it.

Where Molly's code actually lives

The places that matter all belong to the project itself, not to a mirror, a re-upload site, or a forum post. There are three: the site, the repository, and the build guide inside the repository.

First: molly.im. This is the fork's own site and the only place you should download Molly from. It carries the official releases, the documentation, and the release notes. Think of it as the front door: everything the project wants you to have starts here. If a download, a guide, or a claim about Molly does not trace back to molly.im, treat it as unverified.

Second: the public source repository. This is where the actual code lives: every file of the app, the full history of every change ever made, and the project's issue tracker where bugs are reported in the open. The repository is linked from molly.im, so start at the site and follow its link rather than trusting a search result. The change history is worth a mention: because every edit is recorded with its date, you can see that the project is alive, what changed in each release, and that nothing appears out of nowhere.

Third, inside the repository: the reproducible-builds guide. This is the documented recipe for turning the public source into the published app: the exact steps, in the project's own words. It is the document that makes the "anyone can check" claim real instead of theoretical. We will come back to what it enables in the next section.

Reproducible builds, explained simply

Here is the gap that reproducible builds close. Normally, when you download an app, you face an uncheckable claim: the developer says "this app was built from the source code we published," and you have no way to confirm it. The published code could be clean while the published app contains something extra, and you would never know. For most apps, that gap is just accepted. Molly does not ask you to accept it.

A reproducible build means this: take the public source code, follow the documented build recipe exactly, and you get a file that is identical, byte for byte, to the APK published on molly.im. Same input, same process, same output, every time, on any machine. That is not how software builds work by default; ordinary builds pick up tiny differences from the machine they run on (timestamps, file ordering, environment details). Making a build reproducible takes deliberate work, and Molly's developers have done that work and documented it in the reproducible-builds guide.

Why does that matter? Because it turns an uncheckable claim into a checkable one. Anyone with a development machine and some patience can run the recipe, rebuild the app, and compare their result with the file on molly.im. If the two match, the published app really is the published source. The developer's word is not part of the proof. If they did not match, the mismatch itself would be the alarm: the community would see it, investigate, and raise it publicly. The check does not require the developer's permission or cooperation. That is the whole point.

We are keeping this qualitative on purpose. We are not going to quote build hashes or version fingerprints here, because those change with every release and a stale number on a guide page is worse than no number. The live values (the current source, the current recipe, the current published file) are where they belong: on molly.im and in the repository. What does not change is the mechanism, and that is what this page teaches.

Why this matters for trust

Installing a fork asks you to trust two things, not one. First, you trust the code: that what it does is honest. Second, you trust that the app you installed is really that code. Open source handles the first. Reproducible builds handle the second. Without reproducibility, you are trusting the developer on the second point with no way to verify. With it, the second point is checkable by anyone, forever.

This matters more for Molly than it would for an app from a giant company, and that is worth saying plainly. A big company has a reputation to lose, an app-store review process standing between its developers and your phone, and lawyers. An independent fork has none of that machinery. What it has instead is transparency: the code is public, the build is reproducible, the issues are tracked in the open. Transparency is not a weaker substitute for corporate reputation. For a privacy tool, many people consider it the stronger foundation, because it does not depend on trusting anyone's incentives.

There is also a practical side. Independent researchers, journalists, and privacy reviewers can verify Molly without asking the developers for anything: no special access, no relationship, no permission. That is how small projects earn outsized trust: by making verification so easy that skeptics do it for fun. Our is-Molly-safe guide weighs the rest of the fork's trust model (the small team, the release lag, the support situation) alongside what this page covers.

What reproducible builds do NOT prove

Honesty requires the other half of the picture. Reproducible builds are powerful, but they are not magic, and anyone who tells you "reproducible, therefore safe" is overselling.

They do not prove the code is good. Reproducibility proves the app matches the source. It says nothing about whether the source itself is well-written, bug-free, or free of deliberately planted backdoors. A perfectly reproducible build of malicious source is still malicious. The check moves trust from "is this app really that code?" to "is that code trustworthy?", which is progress, but the second question still needs answering by reading the code.

They do not replace code review. Most users, reasonably, will never read the source or run a build. The value for you is indirect: the possibility of checking keeps the project honest, and the people with the skills to check (researchers, other developers, the privacy community) actually do. You benefit from their scrutiny the way you benefit from restaurant health inspections you never personally conduct.

They do not fix the fork's release lag. Molly follows Signal's releases, so security fixes can arrive later than on official Signal regardless of how transparent the build is. Transparency and speed are different virtues. The Molly vs Signal comparison covers what that lag means in practice.

They do not protect a download from the wrong place. A reproducible build proves the molly.im file matches the public source. It proves nothing about a "Molly" APK from a random mirror site: that file was never part of the process. Verification starts at molly.im and ends there.

Real fork vs fake "mod": the source-code test

This is where the source-code story becomes a practical weapon. The app stores are full of "Signal mods," "Molly Pro," and "Molly Plus" editions that have nothing to do with the real projects. There are no Pro or Plus editions of Molly. Anyone offering one is lying about what it is. Here is the test that exposes them in seconds:

A real fork publishes its source. A fake cannot. Ask for the source repository. A real project points you to public code, a build guide, and an open issue tracker. A fake gives you excuses, dead links, or silence, because there is no source to show, or because showing it would reveal the malware inside. "No public source" does not mean "unverified fork." It means not a fork at all. Do not install it, no matter how convincing the icon looks. Our fork-landscape guide names the fakes to avoid.

Verify any fork with this checklist

Building it yourself is advanced, and that is okay

Let us be honest about what full verification takes. Rebuilding an Android app from source needs a development machine, the Android build tools, a chunk of disk space, and the patience to follow a technical guide precisely. It is not a weekend project for most people, and this page is not going to pretend otherwise by walking you through commands. Anyone who tells you "just compile it yourself" as if it were trivial is selling something.

Here is the part people miss: you do not need to build it to benefit from it. The value of reproducible builds for a non-developer is not the build. It is the checkability. A project that publishes its source and its build recipe is a project that has decided to be auditable. That decision, made in public and verifiable by others, is itself evidence about the project's character. You are not trusting blindly; you are trusting a structure that independent experts can and do inspect.

If you are technical and want to go further, start with the project's own reproducible-builds guide in the source repository (linked from molly.im), not with a random tutorial, which may be outdated or wrong. If you are not technical, the useful moves are simpler: download only from molly.im, read the release notes when you update, and keep the which-Molly guide handy when choosing between the standard and FOSS builds.

Get Molly from its own site

Ready to try it? The only safe source is the fork's own site. If you have not decided between the two builds yet, the which-Molly decision guide and the install guide are the right next reads. And if your phone has Google services and works fine, official Signal remains the simpler choice.

Frequently asked questions

Related: the Molly hub, what Molly is, is Molly safe, Molly vs Signal, other forks and fakes to avoid, installing Molly safely, and choosing between Molly and Molly-FOSS.