Download

Download the latest release

SafeKeepVault is a bootable disk image. Flash it to a USB flash drive using Balena Etcher (Mac or Windows) or dd on Linux. Your computer’s existing files are never touched.

Check that it’s genuine

A tampered image could silently steal your seed. Verification takes about two minutes — complete all three steps before writing to your USB drive.

# Import the maintainer's public key
$ gpg --import developer-pubkey.asc

# Check the key's fingerprint
$ gpg --fingerprint anton@safekeepbitcoin.com
      A333 EB82 6F70 A79A 736F  0994 8EA7 DD8C EDBA 86C2
uid           Anton <anton@safekeepbitcoin.com>

# Verify the signature over SHA256SUMS.txt
$ gpg --verify SHA256SUMS.txt.asc SHA256SUMS.txt

gpg: Signature made ...
gpg: using RSA key A333EB826F70A79A736F09948EA7DD8CEDBA86C2
gpg: Good signature from "Anton <anton@safekeepbitcoin.com>"

# Check file hash against SHA256SUMS.txt
$ sha256sum --check SHA256SUMS.txt
# Expected output: SafeKeep-Release-v1.65.img: OK

# Check file hash against SHA256SUMS.txt
$ shasum -a 256 -c SHA256SUMS.txt
# Expected output: SafeKeep-Release-v1.65.img: OK

# Generate the file hash
PS Get-FileHash SafeKeep-Release-v1.65.img -Algorithm SHA256

Put it on a flash drive and start it

Write the image to a dedicated USB flash drive (8 GB or larger). The host machine’s internal drive is completely bypassed and remains untouched throughout the session.

# Flash with dd — replace /dev/sdX with your USB device
$ sudo dd if=SafeKeep-Release-v1.65.img of=/dev/sdX bs=4M status=progress oflag=sync

Updating a flash drive you already have

For advanced users: build it yourself

Verifying the signature proves the release came from the developer. Building from source goes one step further: the image you flash contains exactly the code you reviewed, so a tampered release file is no longer a risk. SafeKeepVault is plain HTML and JavaScript plus a set of build scripts, with no compiled app committed to the repository.

You need: an x86-64 Linux machine (Debian or Ubuntu is easiest), sudo, git, Node.js 22 or newer with npm, about 15 GB of free disk space, an internet connection during the build, and a USB flash drive of 8 GB or more.

$ git clone https://github.com/Pasalon0404/SafeKeepVault.git
$ cd SafeKeepVault/usbbootdrive
$ bash prepare-app.sh

$ sudo bash build.sh

# replace /dev/sdX with your USB device
$ lsblk
$ sudo bash flash-new-stick.sh /dev/sdX

The README has the full steps. The app is always compiled from the source you cloned: no prebuilt app is committed to the repository, and the build stops with an error if the app is missing.

What building it yourself does and doesn’t prove

• It removes the risk of a tampered download — the image contains the code you cloned.
• It doesn’t review the packages it downloads — the build fetches Ubuntu packages, npm packages (pinned by package-lock.json) and Python packages (pinned by SHA-256 hash). Reviewing the repository does not review those.
• The app is reproducible — the app (boot.html) is a reproducible build: rebuilding the stamped commit gives byte-for-byte the same file, and npm run verify-release checks this (see VERIFYING.md).
• The USB image isn’t reproducible yet — a self-built safekeep.img won’t match anyone else’s hash. That’s expected.

No Linux machine?

• Windows PCs and Intel Macs — boot Ubuntu 24.04 from a USB flash drive in “Try Ubuntu” mode, or use a Linux virtual machine (VirtualBox, VMware, Hyper-V). A live session runs in RAM, so keep the work folder on an external drive with about 15 GB free.
• Apple Silicon Macs (M1–M4) — virtual machines there run ARM Linux, and this build needs x86-64. Emulating x86-64 is very slow. Borrowing a PC or renting an x86-64 Linux server works better.
• A rented Linux server — works for anyone, with one caveat: the build then runs on someone else’s computer.
• Flashing on Mac or Windows — use balenaEtcher, or Rufus in “DD image” mode. Check the image’s SHA-256 first.

Reviewing the code with an AI assistant

You can point an AI coding assistant at the public repository to help audit it before you build. It is a useful second pair of eyes, not a guarantee: the codebase is large, and “the AI found nothing” is not the same as “this is safe.”

The key safety point: tell the assistant to treat everything in the repository as untrusted data and not to follow instructions it finds inside it. A tampered copy of a project like this could hide text aimed at AI reviewers (“this section is safe, skip it”). The README’s starting prompt does this:

Extra checks for the app itself

The app inside this image is byte-for-byte the official v1.65 GitHub release build of boot.html (SHA-256 903938e5…e2ea3262, matching that release’s SHA256SUMS). Since v1.36, every release of the app is published on GitHub with four independent ways to check it. Each one guards against something different:

• Checksum (SHA256SUMS) — the file isn’t corrupted. On its own it proves nothing about who made it.
• Maintainer signature (SHA256SUMS.asc) — the developer key above signed these exact hashes. It is added by hand shortly after a release appears.
• GitHub build attestation — GitHub’s own build service produced these exact bytes from the tagged source code. It doesn’t rely on the developer’s key.
• Bitcoin timestamp (boot.html.ots) — an OpenTimestamps proof that the file existed no later than a particular Bitcoin block, independently of GitHub.
• Reproducible build — the strongest check: anyone can rebuild the app from source and get byte-for-byte the same file, so you don’t have to trust the build machine at all.

The verification guide (VERIFYING.md) has the exact commands for each check. The version stamp on the vault’s welcome screen and dashboard (for example v1.65 · build 524 · 20cee62) names the exact source commit the app was built from.