Local-First Apps: Why Your Journal Data Should Stay on Your Device
Most journal apps store your data on their servers. You write an entry, it gets encrypted, uploaded, and stored in a database you will never see. The company promises to keep it safe. You trust the promise because you do not have a better option.
Local-first is the better option. It is not a privacy gimmick or a niche ideology. It is a concrete architectural choice that changes what happens to your data, who controls it, and what you can do with it ten years from now.
This post explains what local-first actually means, why it matters specifically for personal journals, and how we implement it in Memex.
What local-first actually means
The term comes from a 2019 research paper by Ink & Switch that defined seven ideals for local-first software: the data is yours, it works offline, the network is optional, collaboration is possible, longevity is a design goal, privacy is the default, and the user has full ownership.
In practice, local-first means your device holds the primary copy of your data. The app works without internet. If you choose to sync or back up, that is an explicit action you control, not a default behavior the app requires.
This is different from how most apps work. In a cloud-first app, the server is the source of truth. Your device has a cache. If the server goes down, the company gets acquired, or the product shuts down, your access to your own data depends on whether someone remembers to keep the export endpoint running.
Why journals are the worst place for cloud-first
Not all data is equally sensitive. A project management board in Notion is important but not intimate. A personal journal is different. It contains the thoughts you have at 2am, the health observations you do not share with anyone, the relationship reflections you would be mortified to have leaked, the half-formed ideas that only make sense to you.
Cloud-first architecture means this data lives on someone else's infrastructure. Even with end-to-end encryption, you are trusting that the encryption is implemented correctly, that the company will not change its policies, that a future acquirer will honor the same commitments, and that no government subpoena will compel access.
These are not paranoid concerns. They are things that have happened to real companies with real user data. The question is not whether you trust the current team. It is whether you trust every future decision-maker who will ever have access to the infrastructure where your journal lives.
Portability is the part people underestimate
Privacy gets the headlines, but portability is the more practical benefit of local-first for most people.
A journal is a long-term artifact. You might use it for years or decades. Over that time, apps will change, companies will pivot, and your needs will evolve. If your journal is stored in a proprietary format on a company's server, migrating to a different tool means hoping they offer a good export — and that the export captures everything you care about.
Local-first apps that store data as standard files — Markdown, SQLite, plain text — give you a different kind of insurance. Your data is already in a format that other tools can read. You do not need the original app to access your own records. If the app disappears tomorrow, your files are still on your device, readable by any text editor.
The tradeoffs are real
Local-first is not free. There are genuine costs:
- Sync is harder. Cloud-first apps get multi-device sync almost for free. Local-first apps have to solve sync as a separate problem, and the solutions are usually less seamless.
- Backup is your responsibility. If your phone breaks and you did not back up, your data is gone. Cloud-first apps handle this automatically.
- Collaboration is limited. For a personal journal this rarely matters, but it is a real constraint for shared knowledge bases.
- Some features need the network. If you use AI features that call a cloud LLM provider, those prompts do leave your device. Local-first does not mean air-gapped.
These tradeoffs are worth understanding before choosing a local-first tool. For a personal journal, most of them are acceptable — you do not need real-time collaboration on your diary, and backup to iCloud Drive or a custom folder is a one-tap operation.
How Memex implements local-first
Memex stores all data locally in two forms: Markdown files for human-readable records and knowledge, and a SQLite database (via Drift) for structured data like cards, insights, and metadata. No Memex account is required. The app works offline for everything except AI features that call a cloud LLM.
For AI, Memex uses a bring-your-own-model approach. You connect your own provider — OpenAI, Claude, Gemini, Kimi, Qwen, Ollama, or others. Prompts go directly from your device to the provider you choose. Memex does not proxy, log, or store those requests. If you use Ollama, the entire pipeline runs on your device with zero cloud dependency.
For backup, Memex supports iCloud Drive, a custom folder on your device, or app-internal storage. One-tap full backup creates a .memex file you can store wherever you want. One-tap restore recovers everything.
The entire codebase is open source under GPL-3.0. You can verify every claim in this post by reading the source code.
Local-first is a spectrum, not a binary
It is worth being precise about what different apps actually do:
- Fully local-first: Memex, Obsidian (without Sync). Data lives on your device. Cloud is optional.
- Encrypted cloud: Day One. Data is on their servers but end-to-end encrypted. You trust the encryption implementation.
- Cloud-first with export: Notion. Data lives on their servers. You can export, but the server is the source of truth.
- Cloud-only: Reflection, Rosebud. Data is processed and stored on their infrastructure.
None of these positions is inherently wrong. They serve different users with different priorities. But if you are choosing a tool for your most personal data, it is worth understanding where on this spectrum each app sits.
The long view
A journal is one of the few digital artifacts that might outlast the app that created it. Ten years from now, the app you use today might not exist. The company might have been acquired, pivoted, or shut down. Your phone will be different. Your operating system will be different.
What will not change is that a Markdown file is a Markdown file. A SQLite database is a SQLite database. If your journal is stored in those formats on a device you control, it will still be readable in 2036. That is not a guarantee any cloud service can make.
If that kind of durability matters to you, local-first is not a feature preference. It is a requirement.
For more on how Memex compares to cloud-first alternatives, read our AI journal app comparison. If privacy is the exact reason you care about local-first, our guide to choosing a private AI journal app goes one level deeper. For the full story behind the product, see why we built Memex. To try it, start here.
FAQ
What does local-first mean?
Local-first means the app stores your data on your device as the primary copy, not on a remote server. The app works offline by default. Cloud features like sync or backup are optional additions, not requirements.
Is local-first the same as offline-first?
They overlap but are not identical. Offline-first means the app works without internet. Local-first goes further: it means your device holds the authoritative copy of your data, and any cloud sync is a secondary replica rather than the source of truth.
Which journal apps are local-first?
Memex and Obsidian are the most prominent local-first options for journaling. Memex stores Markdown files and a SQLite database on your device. Obsidian stores plain Markdown files in a local vault. Most other journal apps — Day One, Notion, Reflection, Rosebud — are cloud-first with local caching.
Does local-first mean my data is never in the cloud?
Not necessarily. Local-first means the cloud is optional, not absent. In Memex, you can back up to iCloud Drive or a custom folder. If you use AI features, prompts are sent to your chosen LLM provider. The difference is that these are explicit choices you make, not default behaviors you cannot opt out of.