Verify your install

Last updated: April 25, 2026

PocketVault's privacy claims rest on two things: the public source code at github.com/amitm20692/pocketvault.finance, and the binary you actually install. This page lets you prove they match — that the binary in the Play Store / App Store was built from the public code, with no developer-side or CI-side modifications snuck in.

The recipe below produces a byte-identical APK to the one we published for the same release tag. If your hashes match ours, the binary you installed is exactly what we say it is. If they don't, please tell us immediately — that's the kind of mismatch that should never happen, and we treat it as a critical issue.

What you need

  • Docker (any recent version; tested with 24.x and 25.x)
  • Git
  • ~6 GB free disk space (Android NDK is large)
  • A few minutes to wait — first build typically takes 10-20 minutes inside the container

The recipe

All commands below are pasted as-is. Replace v1.4.2 with whichever release tag you want to verify (the one matching the version installed on your device — check Settings → About inside the app).

1. Clone the source at the exact release tag

git clone --depth 1 --branch v1.4.2 https://github.com/amitm20692/pocketvault.finance.git
cd pocketvault.finance

2. Build the pinned container

This Dockerfile pins every component that affects the build output: Flutter SDK 3.41.9, Temurin JDK 17, Android NDK 28.2.13676358, Android SDK platform 36, build-tools 36.0.0. The Flutter SDK download is verified against a known SHA-256 inside the container, so you'd know if upstream were ever swapped under us. 

docker build -f .docs/release/Dockerfile.builder -t pocketvault-builder .

3. Build PocketVault inside the container

This is the exact command our CI runs. The --flavor production flag is required — without it Gradle reports "failed to produce an .apk file" because the production scheme has no actions outside the flavor. 

docker run --rm -v "$PWD:/src" -w /src/app pocketvault-builder \
  flutter build apk --release --flavor production --target-platform android-arm64

4. Hash your local build

sha256sum app/build/app/outputs/flutter-apk/app-production-release.apk

5. Download our published manifest and compare

curl -sL https://github.com/amitm20692/pocketvault.finance/releases/download/v1.4.2/sha256.txt
# Or to compare automatically:
curl -sL https://github.com/amitm20692/pocketvault.finance/releases/download/v1.4.2/sha256.txt | \
  grep app-production-release.apk | sha256sum -c -

A line that ends with OK means the hashes match — the binary you'd install from the store is byte-identical to what your machine just built from the public source. That is the proof.

Things to know before you start

Signing differs by design

Store builds are signed with a private key we don't (and can't) ship. Reproducible-build verification compares the unsigned portion of the APK — the contents and layout of the binary, not the signature. The signature is what proves the published artefact came from us specifically; the hash you compute proves the contents came from the public source.

Some plugins ship pre-built native libraries

A handful of Flutter plugins (e.g. SQLCipher, MediaPipe components) ship pre-built native libraries from upstream. Those are not rebuilt inside our container — they come from upstream and we link them in. You can verify each one against its upstream by checking pubspec.lock against the published packages on pub.dev.

If your hashes don't match

First, double-check that:

  • You're at the same git tag as the manifest's Tag: line (run git describe --tags)
  • The Dockerfile you used is the one from the same tag (rebuild the container if you swapped tags)
  • You hashed the same file the manifest names (it's the unsigned APK, not the signed one)

If all of that checks out and the hashes still differ, email us with your hashes and the tag. A real mismatch is a critical privacy issue and we treat it as such.

Why this exists

Most users will never run this verification themselves — that's fine. The point is that anyone can, and that means anyone with the time and skill to question our privacy claims has a path to verify them without taking our word for anything. The Signal team's reproducible-builds work is the reference; we are following the same pattern for the same reason.

Combined with the truth matrix in our privacy policy — which lists every place data could ever leave your device — and the build-time CI check that fails any release containing analytics SDK endpoints, the privacy claim is independently verifiable end-to-end. You don't need to trust us. You can check.