How Your Data Is Stored

Last updated: September 4, 2026

This page covers both apps: what each one keeps on your Mac, where it lives, how well it is protected, and exactly what each does on the network. It is deliberately specific, including where the protection stops.

bHive The search index

bHive runs entirely on your Mac and never uploads your files. To search by meaning while offline, though, it keeps a local index. This page explains exactly what that index contains and where it lives, so you can decide how to treat it.

What the index contains

When bHive indexes a folder, it reads the text out of your files and stores three things in a single database:

Basic file info: names, paths, dates, and sizes.
The extracted text of each file, broken into small passages. For images and scanned PDFs that is the text bHive reads out of the picture; for audio and video (if you turn transcription on) it is the spoken words, and any text on screen. So a recording's words, or the text in a photo, become readable plain text inside the index — on your Mac only.
A numeric "meaning" fingerprint for each passage, which is what makes semantic search possible.

It does not store copies of the files themselves. It keeps pointers to your originals where they already live, plus the text and fingerprints above.

Worth being upfront about: because the extracted text is stored as text, the index is effectively a condensed, plain-text copy of the readable content of everything you have indexed. That is what lets bHive show you the exact passage that matched a search. It is the trade-off for meaning-based search that runs entirely on your own Mac.

Where it lives

The index is a single database file on your Mac, at:

~/Library/Application Support/bHive/index.db

It stays on your device. It is never sent to us or to anyone else. bHive Software has no server that receives your index, your files, or their contents.

Backups

The index has two halves, and they need to be thought about differently.

The searchable half — the extracted text and the fingerprints built from it — really is derived from your files. If it is lost, bHive reads your library again and rebuilds it. That costs time, not data.
Your organizing is not derived from anything. Hives, tags, notes, the names you have given files inside bHive, Smart Folders and Favourites exist only in this database. The documents on your disk do not record which Hive they belong to. If the index is lost, that work is lost with it.

Time Machine backs the index up along with the rest of your app data, so a backup drive will contain that stored text. Treat a backup drive with the same care you would give the files themselves.
You can exclude the bHive folder in Time Machine settings if you would rather the stored text not sit on your backup drive — but do it knowing the trade. The searchable half will rebuild itself. Your organizing will not come back.
bHive can back up the organizing on its own, which is the better answer if that is your concern: Settings ▸ Index ▸ Back Up… writes a small file containing only the irreplaceable half — no file contents, and typically kilobytes rather than megabytes. It identifies your files by their contents rather than their paths, so a restore still finds them if they have been moved or renamed since.

Syncing

The index is not synced anywhere on its own. It lives in Application Support, which is not part of iCloud Drive, so it stays on the Mac it was created on unless you deliberately move or sync that folder yourself.

What bHive does on the network

If you run a firewall like Little Snitch, you will see bHive make one automatic connection: an Amazon S3 address (bhive-sw.s3…amazonaws.com). That is the update check. bHive uses Sparkle — the standard updater for Mac apps outside the App Store — and at launch it fetches a small public file listing available versions. You can read that exact file yourself: appcast.xml.

If you accept an update, the download comes through bhive.software, not from S3 directly. That request is counted — how many updates happened, for which version — and then redirected to the file on S3. So you will see a second connection, to our website, at that moment and only at that moment. It carries nothing identifying; we learn that some Mac took build 1171, not which one. This page previously said the build came from the same place as the check, which was wrong, and a firewall would have shown you otherwise.

Everything on that connection moves toward your Mac, never away from it. The request carries nothing about you, your files, your searches, or your questions — bHive has no analytics, no telemetry, and no server that could receive them.

The only other network activity is a download you ask for by name: the optional search upgrade, or a local AI model. Those are downloads too.
Prefer no automatic connections at all? Decline automatic checking when Sparkle asks, and use Check for Updates… in the menu whenever it suits you.
The one thing bHive ever composes for sending is the diagnostic report in Settings ▸ Feedback — and that opens as a draft in your own mail app, which you read and send yourself, or don't.

bLine Your clipboard history

bLine keeps what you copy so you can get it back. That history lives on each of your own Macs and nowhere else — there is no server of ours holding a copy.

Where it lives

Everything bLine keeps is under one folder:

~/Library/Application Support/bLine/

History/ — the clips themselves, each sealed as its own file.
Snapshots/ — hourly, daily and weekly snapshots of your history, so a mistaken clear can be undone. They cost almost nothing, because a snapshot links to the clips rather than copying them.
WebSnapshots/ — pictures of linked pages, only if you turned website snapshots on.
config.json — your settings, this Mac's identity key, and the secret shared by your group.

How well it is protected, and where that stops

Clips are encrypted on disk. Each is sealed with a key derived from this Mac's own identity, so the files in History/ are unreadable on their own: copy that folder to another machine and you get nothing usable.

But that key is not kept somewhere separate. It lives in config.json, in the same folder, as ordinary text. The file is readable only by your macOS user account, and that permission — not the encryption — is what stands between your stored clips and someone else. Anything that can read your account's files can read them: another admin on the Mac, a full-disk backup, or a copy of that whole folder. The encryption protects the clips from being read out of a stray History/ folder. It does not protect them from someone who already has your home directory.

It stays there for a concrete reason. bLine ships a small command-line tool that Raycast and the app both use to read your history, and macOS will not let a standalone program hold the entitlement needed to reach the Keychain. Putting the key out of the tool's reach would break searching your clips rather than protect them.

The group secret is in the Keychain

The key above unlocks one Mac's stored clips. There is a second secret, shared by every Mac in your bLine, that seals what travels between them — and that one is worth far more to anyone who wants your clipboard, because it reads everything your Macs send each other and can pass for one of them.

That secret is kept in the macOS Keychain, not in config.json. The Keychain is encrypted with your login password and is not part of the folder above, so a copy of bLine's data directory does not contain it, and neither does a backup of that directory on its own. Older installs move it there automatically the first time they run a build that supports it; nothing is lost and there is nothing to do.

The practical consequences are worth spelling out. A Time Machine backup contains your clipboard history in a form that can be opened by anyone holding that drive and the folder from it, so treat the backup with the same care you would give the things you copy. And bLine deliberately does not record everything: content marked confidential by a password manager is never stored at all, and clips that look like one-time codes are dropped after five minutes.

Text read from images

bLine reads the words inside screenshots so you can search for them. That happens on the Mac that holds the image, is stored encrypted beside the history, and is never sent anywhere — not even to your other Macs, which read their own copies. Deleting the clip deletes the text with it.

What bLine does on the network

Unlike bHive, bLine is a networked app by definition: its whole job is moving what you copy between your Macs. A firewall will show:

Direct connections to your other Macs on your local network. Clips are sealed before they leave and opened only on Macs in your group. Someone watching the network can see that two machines are talking, not what was said, whose it is, or that any of it is bLine.
A relay, only if you set one up. bLine ships with none. If you want your Macs to sync across different networks you deploy one yourself on your own Cloudflare account; it forwards sealed bytes it has no key for and stores nothing. We do not run one and are not in that path.
The update check, to the same S3 address bHive uses, with the download itself coming through bhive.software exactly as described above. You can read bLine's version list yourself: appcast.xml.
One page load per copied link, and only if you switch on website snapshots, which are off by default. The Mac that copied the link loads that page once with no cookies and no sign-in; your other Macs never load it. Links that look single-use are skipped rather than opened, because loading one can spend it.

That is the complete list. There is no analytics connection, because there is no analytics.

Encryption and shared Macs

The index is a standard database file, protected by your macOS user account's normal permissions.
If you have FileVault turned on, the index is encrypted at rest along with everything else on your disk. If you keep an index of sensitive material, turning on FileVault is a good idea.
On a Mac shared between people, treat the index like any other sensitive document in your home folder.

Removing the index

You are always in control of the index. Quitting bHive and deleting the ~/Library/Application Support/bHive folder removes it completely. The next time you index a folder, bHive builds a fresh index from your files.

Questions

Happy to answer anything about how this works. Email hello@bhive.software.