Your data stays on machines you control
FoxByte runs on your own laptop or servers. It has no telemetry, we never see your data, and nothing leaves the machine unless you send it somewhere. Here is exactly how that works, including the few connections it does make.
On your machines, and nowhere else by default
Your databases
Every branch, row and index lives on the machine that runs FoxByte. There is no FoxByte cloud in the path.
No telemetry
FoxByte sends no usage data, metrics or crash reports to anyone, including us.
Backups
Kept beside the database until you choose a bucket of your own. Then they go there and only there.
Realtime
The change feed streams from your own server to your own apps, with no third party in the middle.
Every connection FoxByte makes to the outside
None of these carries your data. Once installed, FoxByte runs without an internet connection: the update check gives up quietly and the console falls back to system fonts.
- An update check. fox start asks GitHub whether a newer release exists, and fox check reports your version. It sends nothing about your data. FOX_NO_UPDATE_CHECK=1 turns it off.
- Downloads you ask for. Installing, fox update and fox upgrade fetch signed releases from GitHub and engine images from GitHub’s container registry.
- Web fonts. The console loads its fonts from Google Fonts, so your browser contacts Google when you open it.
- Sign-in with GitHub or Google, only if you configure it. Otherwise accounts are email and password, checked on your machine.
- Backups and anchor copies, only to a bucket you set with fox backup target set or fox blackbox anchor-target set.
- Imports, only from the source you name. Importing from private networks is for admins, and cloud metadata addresses are refused.
How secrets and traffic are kept safe
Encrypted in transit
The console, the gateway and the Agent API all serve TLS, and a service that cannot load its certificate refuses to start rather than fall back to plain text off loopback.
Passwords never stored
Account passwords are kept only as bcrypt hashes. Nobody can read one back, not even an admin; a forgotten password is reset from the machine itself.
Keys shown once
API keys are stored as SHA-256 hashes with a short prefix for display. Revoke one and everything using it is cut off at once.
Sessions hashed at rest
Sign-in session tokens are stored hashed, so a copy of the accounts file does not hand out live sessions.
A password per role
Every account and agent logs in to Postgres as its own role with its own password. The install secret belongs to the superuser alone and never appears on a command line.
Secrets in locked files
Private keys and the backup bucket’s secret are written to files only their owner can read, and the backup secret is asked for rather than typed on a command line.
Who can see what
Branches belong to their maker
Everyone shares main. A branch made through the console, the API or an agent is its maker’s; other people’s branches are not listed and answer “not found”, through the gateway too.
Agents see one branch
An agent key opens its own branch and nothing else. It never holds an admin grant, and the console and control-plane API refuse it.
Postgres rules still apply
Row-level security policies and GRANTs work exactly as they do in Postgres, for every client that connects.
Admin power is on the record
Admin grants, sign-ins, failed sign-ins, key changes and refused requests all go into the security log, chained and verifiable.
Records about people, and how long they last
The Blackbox records every schema change with who made it, the tool and the full statement. The security log records who came in and what they were refused. Both are append-only on purpose, so plan for that: keep personal data out of schema statements.
Query history keeps the SQL each person ran, never the results, for 90 days by default. fox history retention changes how long, and each person sees only their own.
- Blackbox: schema changes, who, which tool
- Security log: sign-ins, keys, grants, refusals
- Query history: SQL text only, 90 days by default
Delete what you no longer need
Removing data is a command away, and nothing is kept elsewhere because nothing was sent elsewhere.
Backups in an Object Lock bucket cannot be deleted before their retention ends, by design. Choose the retention with that in mind.
$ fox branch delete qa $ fox apikey revoke you@example.com <id> $ fox user delete former@example.com $ fox backup prune --keep 7 $ fox uninstall
What FoxByte does not do for you yet
- Encryption at rest. FoxByte does not add its own encryption to stored data yet. Use disk encryption on the machine (FileVault, BitLocker or LUKS) and server-side encryption on your backup bucket.
- Self-hosted console fonts. Until the console bundles its own fonts, opening it makes a request to Google Fonts.
- Compliance by itself. FoxByte gives you controls and evidence, but no product makes you compliant with a regulation on its own. Check your obligations with your counsel.
Privacy questions
No. FoxByte runs on your machines, sends no telemetry and has no service in the path of your data. We could not see it if we wanted to.
Yes, once installed. Installing and updating need GitHub, but the database, branches, the Blackbox and the console all run offline. The update check gives up quietly and the console falls back to system fonts.
In a small accounts database on the machine that runs FoxByte. Passwords are bcrypt hashes, keys and session tokens are SHA-256 hashes, and none of it leaves the machine.
Not by itself. It helps: data stays where you put it, access is per person, and the Blackbox and security log give you evidence of who changed what. Whether that meets your obligations is a question for your counsel.
Almost nothing: no analytics, no tracking cookies and no third-party scripts. The website privacy page lists the few preferences it keeps in your browser.
Run it where your data already lives.
Install FoxByte on your own machine. Nothing about your data goes anywhere else.
$ curl -fsSL https://get.thefoxbyte.com/install.sh | sh