How Your Data Is Stored

Last updated: September 4, 2026

This page covers what bHive keeps on your Mac, where it lives, how well it is protected, and exactly what it 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.

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.