Self-hosted vs. local-first personal CRM: two privacy architectures, compared honestly

Self-hosted and local-first are the two serious answers to the same worry — relationship notes in a stranger’s cloud — and they are not interchangeable. One trades convenience for control and hands you a server to run. The other keeps the primary copy on your device and hands you almost nothing to operate. Which trade fits depends on you, not on the software.

Two architectures, one motive

A personal CRM holds the most sensitive database most people will ever build voluntarily: who matters to you, what they confided, when you last spoke, what’s fragile in their life right now. Putting that on a vendor’s servers in plaintext means trusting not just today’s company but every future owner of it, every pricing pivot, every quiet acquisition.

Both architectures in this comparison refuse that bet — differently. A self-hosted CRM moves the server under your control: the application runs on a machine you rent or own, and the vendor disappears from the data path entirely. Local-first software abolishes the mandatory server instead: the primary copy lives on the device in your hand, the app is fully functional offline, and a server — if you enable one — is reduced to a relay for encrypted sync between your own devices. The term comes from Kleppmann, Wiggins, van Hardenberg & McGranaghan (2019), whose paper laid out the test we’d encourage applying to any “private” app: if the vendor vanished tomorrow, would the software still work, with your data intact, on hardware you control?

Both architectures pass that test. Everything else about them differs.

Self-hosting: control as a part-time job

The reference product here is Monica — open source under AGPL v3, maintained since 2017, installable via Docker or by hand, with a genuinely free self-hosted edition. We compare it to our own product at length on the Endearist vs. Monica page, and the short version stands: if you want a comprehensive, web-based system of record and you enjoy operating software, Monica self-hosted is an excellent choice.

The money is the easy part. A small VPS at about a dollar a month puts three years of self-hosting near €30 — against roughly €270 for Monica Cloud at $9 a month over the same stretch. No personal CRM gets meaningfully cheaper in cash.

The honest ledger is the time. Self-hosting a PHP/Laravel application with a MySQL database means owning operating-system patches, application upgrades and their occasional breaking migrations, TLS renewal, and backups that you restore-test rather than merely schedule. A few hours a month when things go well; an unplanned evening when they don’t. And the duty has a sharp edge: a self-hosted CRM that stops getting patched doesn’t politely degrade. It sits on a public IP address, holding intimate data about everyone you know, accumulating known vulnerabilities. Neglected self-hosting isn’t a lesser version of privacy — it’s a liability the vendor cloud never was.

Two further trade-offs deserve plain statement. Monica is web-only: no native desktop client, and mobile means the web app in a phone browser — workable, not delightful. And the control is real but concentrated: you are the security team, the backup operator, and the person who notices at 11 p.m. that the certificate expired.

Local-first: the device is the source of truth

Local-first inverts the topology. The database lives on your phone or laptop — in Endearist’s case as a local store you can export to plain Markdown — and the application is built to be complete without any network at all. Sync across devices is optional and end-to-end encrypted (AES-256-GCM, keys that never leave your devices), routed either through the vendor’s relay or through storage you already control: iCloud, Google Drive, WebDAV. Whatever carries the traffic sees ciphertext.

What this buys you is the absence of an ops burden rather than the presence of a server. Nothing to patch, nothing publicly addressable, no attack surface beyond the device you already secure with a passcode and disk encryption. The privacy floor is high by default — which matters, because defaults are what most people actually run.

What it costs you is a different dependence: on the vendor’s app binary. There’s no AGPL codebase to fork this afternoon, no community fork waiting if development stops. Honest local-first vendors compensate structurally, and you should demand that they do: exports in open formats you can test during a trial, offline operation that makes a vendor shutdown an inconvenience instead of an emergency, and a written source-release pledge that the code goes public on shutdown or acquisition. With those three in place, the dependence has a floor under it. Without them, “local-first” is just a cache with good marketing.

Threat models, honestly

“More private” is meaningless without naming the adversary, so name them.

Vendor business-model drift — the realistic one: pricing pivots, acquisitions, features moving behind paywalls, plaintext data quietly feeding an AI roadmap. Both architectures defend well. Self-hosting removes the vendor from the data path; local-first removes the plaintext from the vendor’s reach. This, not espionage, is the threat most people are actually buying protection against.

Server compromise. Here the architectures genuinely diverge. Self-hosting concentrates risk on one machine whose security equals your diligence — excellent if maintained, dreadful if not. Local-first has no server of yours to breach; an attacker needs your physical device, which a passcode and full-disk encryption already defend.

Device loss. The inversion of the previous case. The self-hosted server doesn’t care if your phone drowns. A local-first primary copy does — so encrypted sync or scheduled backups aren’t optional extras; they’re the survival plan for the device-loss scenario.

Your own future negligence. The least flattering adversary and the most reliable one. Self-hosting assumes you’ll still be patching and restore-testing backups in year three; local-first assumes you’ll keep a second copy somewhere. Both assumptions fail sometimes — but they fail differently. A forgotten local-first backup costs you data only if the device also dies; a forgotten server patch exposes data while everything appears to work fine.

Legal and jurisdictional exposure. Data on a rented VPS lives in a datacenter subject to that host’s compliance machinery. Data on your personal device sits behind stronger practical and, in many jurisdictions, legal protections. Edge-case territory for relationship notes — but it points the same direction as the rest: fewer third parties holding anything at all.

Who should pick which

Pick self-hosting if operating servers is something you do anyway — homelab, VPS, monitoring you check with morning coffee — and you want a broad web-based record with code you can audit and fork. Monica has earned its position as the default answer there since 2017.

Pick local-first if you want the same custody of your data with none of the operating: native apps, offline by default, encrypted sync when you choose to turn it on. That’s the configuration we think fits most people who care about privacy but will never lovingly maintain a Linux box — and most people who think they’ll maintain one, eighteen months from now.

And the choice isn’t a marriage. Because both architectures live or die by open exports, you can start local-first this afternoon, graduate to a self-hosted system when the homelab itch arrives, or run both in parallel — a comprehensive web record on your server, a lighter local app in your pocket. The only configuration with no exit is the one this whole comparison exists to avoid: plaintext relationship notes in a cloud someone else controls, exportable on their terms.