A claim about where the primary copy lives
Local-first means the working library operates on the device, without requiring a provider account or a server-side copy for ordinary use. Network features may exist, but they are optional rather than load-bearing.
It is a statement about architecture, not about virtue. It tells you which failures are possible and which are not — and it introduces some of its own.
What it removes from the threat model
Without a required account there is no credential to be phished, no server-side library to be breached, and no provider able to be compelled to produce content it never held.
Those are real reductions, and they are the reason the model is worth choosing. They also arrive together with a corresponding transfer of responsibility.
What it makes worse
If the live library is only on the device, then losing the device loses the library. There is no account to sign into from a replacement phone and no provider-side copy to restore from.
This is the trade, stated plainly: fewer remote risks, more consequential local loss. It is only a good trade if you deliberately create and protect an encrypted backup, which is precisely the step people skip because the storage is already encrypted.
Local-first is not anonymity
Keeping data on the device says nothing about whether your activity is observable. The platform still knows the app is installed, the network still sees traffic from any optional feature you enable, and the device itself remains a target.
Conflating local-first with anonymous leads people to skip precautions that still apply.
Verify the claim rather than accepting it
- Check whether account creation is required to use a local vault at all.
- Identify every network feature and confirm each is genuinely optional.
- Map exports and backups to destinations you control.
- Plan recovery for device loss, factory reset, uninstall, and key invalidation.
- Observe whether the app makes network calls when no optional feature is enabled.
Misreadings worth avoiding
- Equating local-first with anonymous or untraceable.
- Assuming no network means no device-level risk.
- Skipping backups because the local storage is encrypted.
- Treating an optional cloud backup as if it were the same architecture.
A fictional example
Eli starts with a non-sensitive test: “Check whether account creation is required for local use.” Next, Eli follows the second check: “Identify every network feature and whether it is optional.” This fictional scenario demonstrates the decision process; it is not a report of product testing.
Common mistakes
- Equating local-first with anonymous
- Assuming no network means no device risk
- Skipping backups because storage is encrypted
What this workflow does not change
- Equating local-first with anonymous
- Assuming no network means no device risk
- Skipping backups because storage is encrypted
Questions people ask
Does NullVault require an account for local vaults?
The Android value proposition says no account is required to create and use local vaults.
Can local-first use cloud storage?
Yes, for a user-directed encrypted backup or export, provided the boundary is explained clearly.