Your data

Where it isYour record is a few plain files on one disk

Your journal entries, tasks, documents, and meetings are all in SQLite files: a database whose whole contents are one ordinary file, readable on any computer, with no server around it. The files are in one data folder on the backend's disk. The backend is the private server that holds all your data, and it runs at Railway, the cloud computer whose account you own.

core.db

Everything you typed: journal entries, tasks, documents, meetings, areas, streams, and the signals your devices report. One file per account, inside the data folder's users directory, in a folder named by your account id.

system.db

Sign-in records at the top of the data folder: your account row and its settings, your web login, and your tokens stored as hashes. The plain token appears once, when it is minted, so a copy of this file logs nobody in.

The media store

Photos, videos, and audio you record go through the journal's upload path. With a media bucket configured they upload to a private bucket at Cloudflare R2, a second company's rented file storage; without one they go into a media folder beside the databases. Every object is keyed under your account and reachable only through expiring links. The videos & photos section of the operating guide covers the protections on it.

The code holds none of this. GitHub keeps the code and the work list, and the ship script's tripwire scan fails any change whose files contain personal data. With the buckets configured, your record is stored with exactly two companies: Railway and Cloudflare.

BackupsThe backend copies every database once a day, off the machine where a bucket is configured

Once a day, and again each time it starts, the backend writes a consistent snapshot of each account's core.db into a backups folder on its own disk. On Sundays the snapshot is kept as a weekly copy. system.db is snapshotted in the same run.

On the same disk

The last seven days of daily copies and the last eight Sundays, for quick undo of a bad edit or a bad change. A lost disk loses these along with the live files. Covering that loss is the bucket's job.

At Cloudflare

With the backup bucket configured, each snapshot also uploads to a dated key in a private backup bucket, separate from the media bucket: every account's core.db, plus system.db. The bytes upload exactly as written, uncompressed. The backend deletes no bucket copies. They accumulate under their dates.

Checked on every upload

Each bucket copy is read straight back and compared, hash against hash, with what was sent. A copy that reads back different counts as not sent, and the failure goes in the backend's log.

Only if configured

The bucket copies run where the backup bucket's credentials are set on the backend, or where the operator has set an upload command of their own. An instance with neither keeps only the same-disk copies. Ask your Claude which state yours is in: the backup line on the Account screen is wrong today, and the paragraph under Taking it with you says how.

Your photos and videos are outside these copies entirely. A snapshot holds the databases and only the databases, so a recording has exactly one copy: the object in the media bucket, or the file in the media folder on the same disk.

Getting it backRestoring is manual work on the snapshot files

There is no restore tool. A snapshot is an ordinary SQLite file, so getting data back means an operator picking a dated copy, from the backups folder or from the bucket, and working on it by hand: opening it beside the live file to pull back something deleted, or standing it up in place of a lost database. You ask, your Claude does the file work, and touching the live files stays a deliberate step taken with you.

Taking it with youOne download returns your record as a zip

Settings → Account has a Download your data button. The zip it returns holds one JSON file per table, readable by anything, plus sqlite/core.sql, a full SQL copy of your database that sqlite3 rebuilds into the exact file. Two things are outside the zip. Your photos and videos are not in it, and the media store is their only home. system.db is not in it either, so your account row, your timezone, your web login and token hashes, your AI switches, model picks and edited prompts, and your stored service keys stay behind on the server; what the zip holds is everything in your own core.db. Bringing an export back is not a button either: the backend ships an import command an operator runs against a zip.

The phone does the same thing, under Settings → Account, where the button reads Save your data. A phone has no downloads folder, so it prepares the same zip and hands it to the share sheet, and you send it wherever you keep files. The sheet never reports what you chose, so the screen says nothing on the way that worked and speaks up only when the file could not be prepared or could not be passed on.

Both screens print one sentence under the button meant to say whether a copy of your record exists anywhere but this server: the date it was last copied off, or that the next copy runs overnight, or that this LifeOps keeps no off-site copy and the file you just saved is the copy you hold.

The accountsYour written record survives any one account closing

With the backup bucket configured, the databases are in two places at once, Railway's disk and Cloudflare's bucket, so closing either single account leaves a complete copy at the other. Photos and videos are the exception, held once, wherever the media store points. Each account below says what it runs, what stops without it, and where you see its bill.

Railway

Runs the backend and the web app, and its disk holds the live databases. If it stops, both apps go offline. With the backup bucket configured, the copies at Cloudflare and the code at GitHub rebuild everything, minus at most the day since the last copy. You see its bill in your Railway account.

Cloudflare

Holds both buckets where they are configured, your media and your backups. If it stops, photos and videos in the bucket stop playing, and the backup copies are inside the closed account with them. The backend keeps running untouched on its own disk. You see its bill in your Cloudflare account.

Anthropic

Runs the model behind the five AI jobs — filing an entry, a task and a document under one of your life areas, writing up a transcribed recording, and writing the line saying what changed between two versions — and behind Chat, which answers your questions out of your own data. Each job has its own switch in Settings and Chat has none, so removing the key is what stops Chat. If it stops, everything saves and shows as always, with those fields left for you, and Chat refuses rather than answering. You see its bill in your Anthropic console. The AI in your LifeOps covers the switches, and the app’s own Keys screen says the same thing in one line: “Every AI job runs on this: filing an entry into a life area, writing up a recording, and the assistant’s own answers.”

ElevenLabs

Turns a recording into a transcript, and only while Transcribed recordings is on in Settings → Features with a key stored for it. It bills by the minute of recording, against whichever key is stored, so storing your own puts it on your ElevenLabs account. If it stops, recordings still upload and play, with no transcript, title or summary.

Resend

Sends the one email this system sends: the alert saying a background job broke, and the one saying it recovered. Settings → Keys holds a slot for it, though the alert sender still reads the deployment’s own RESEND_API_KEY, together with the address it writes to. It touches none of your record. If it stops, a broken job goes unannounced until you or your Claude looks. You see its bill in your Resend account.

Apple & Google

Developer accounts for shipping the phone app through their stores, holding none of your data. If either lapses, new store builds stop, and nothing about your data changes.

Expo

The build service that turns the code into the phone app. The account is free to start and holds none of your data.