Open Brain: Backups, Security, and GitHub Hygiene
Before you start: identify which components you use. Start these checks before storing your first real note; you do not need to finish every optional interface first.
Done when: you know who can access the data, what the backup covers, and which recovery steps have passed a restore test.
The fictional note about Ana gives you a clear recovery check: retrieve the same saved ID and the original text, “Ana will send the code on Friday.” Once you add real notes, you need the same confidence about access and recovery. These checks begin before real data enters the system and continue while you use it.
These are checks to perform on your own system. Repository settings alone do not prove that a live deployment is configured correctly.
Before the first real note
Use the synthetic collection to test who can read it and to rehearse recovery in isolation. Confirm permission to use each external service, protect the credentials, and resolve failed access checks before adding private material. Record backup coverage and a successful restore procedure for the components you intend to rely on. If recovery remains untested, keep that gap explicit and continue with synthetic data.
After that first check, repeat the relevant tests when a client, access rule, model, or storage arrangement changes. The recurring checklist below helps keep that work bounded.
Keep a private GitHub repository
If you choose to use GitHub, a private repository limits access to people and integrations you authorize. When creating a repository, select Private, then check its visibility and access settings before pushing. Keep collaborators and connected applications limited to those you trust. A private repository is hosted by GitHub; it does not make information stored in Supabase, sent to model providers, or shared through Telegram private by itself.
Use the repository for code, documentation, and database migrations, not for credentials, private notes, source documents, or backups. Add local configuration and data paths to .gitignore before adding files, and inspect the staged changes before each commit. Ignoring a file does not remove a copy already tracked or stored in Git history. If a credential has been committed or exposed, revoke or rotate it and address its copies and history; deleting the latest file alone is not enough. GitHub explains repository visibility and removing sensitive data.
The computer setup in Part 1 separates project files from local documents and backups. Review database access separately from repository access using the checks below.
Prompt: review access and secrets
Review this Open Brain's access design without changing it.
Inspect the repository and, where authorized, read-only deployed settings.
Check exposed tables, views, functions, grants, row-level policies, and
server routes. Distinguish authentication from authorization. Include
optional search paths and bot access checks.
Look for credential leakage risks in tracked files, browser bundles,
logs, and examples without displaying secret values. Separate confirmed
issues, source-level risks, and settings you could not inspect.
Give me a prioritized report with evidence and proposed tests. Do not
rotate credentials, change permissions, or alter production automatically.Check the result
The report should tell you which component enforces each boundary. Test with synthetic data as the intended owner, an unauthorized account, and a signed-out caller. A successful owner request is only one part of the test.
Use Supabase’s row-level security (RLS) guidance when reviewing database policies. Privileged server credentials require separate care because they can bypass ordinary row policies.
Prompt: prove recovery
Prepare a backup and recovery plan for this Open Brain.
Inventory database records, uploaded files, application code,
configuration, and the secure process needed to restore credentials.
Check which items the existing backup includes.
Propose retention, encryption, storage location, costs, and a restore
test. With my approval, restore into an isolated destination, never over
production. Verify representative notes, IDs, relationships, counts,
and retrieval using approved test data.
Document the exact procedure, result, gaps, and last successful restore.
Do not claim that creating a backup proves it can be restored.Supabase’s backup documentation explains coverage and limitations. In particular, database backups do not include the actual objects stored through Storage. If you keep attachments there, plan for them separately.
What needs recovering?
Keep a short inventory with the location, access owner, retention period, backup location and method, and last restore test for each item:
- Notes and metadata: original text, IDs, dates, labels, and relationships.
- Attachments: the files themselves, not only database links to them.
- Code and migrations: a known working revision and reproducible database changes.
- Configuration: non-secret settings and a secure way to recover or replace credentials.
Record what is not covered. If a restore fails, preserve the original system, fix the recovery procedure, and repeat the isolated test. Do not overwrite production to find out whether a backup works.
For example, suppose you have made an export of Part 2’s test database but have not restored it. A useful inventory entry would look like this. It is an illustrative report, not evidence about my backups:
| Field | Illustrative entry |
|---|---|
| Item and source | Fictional survey-analysis and travel notes in the isolated test database |
| Access owner | Owner of that test project |
| Backup location | Protected export outside the Git repository |
| Coverage | Database records, including original text, IDs, metadata, and embeddings; no separate attachment files |
| Retention | Not yet approved; needs a documented policy |
| Last successful restore | Not tested |
| Next check | Restore in isolation and compare saved IDs, original text, relationships, counts, and retrieval |
The export exists in this example, but the entry does not yet establish recovery. Only after a successful restore test should you replace “Not tested” with the date, destination, and verified result. Record failed attempts separately; they do not establish a successful restore. Keep any remaining coverage gaps visible.
Use the note about Ana and its saved ID as one check. If you added the Telegram note about Tuesday’s code review, check that too. Restore enough configuration to run the same approved search and access tests, then confirm that the recovered sources still match. A matching row count alone is not enough.
Keep maintenance small
Keep code and reproducible database changes in version control. Keep credentials, private notes, and backup files out of the repository. Review a diff before committing rather than automatically committing whatever happens to be in the working folder.
Use a short recurring checklist:
- Did capture fail or retry unexpectedly?
- Do representative searches still return the expected sources?
- Has a change introduced a new access path or external provider?
- Is the latest backup usable, and when was recovery last tested?
- Are dependencies and model choices still supported?
- Are provider and hosting charges still within the approved budget?
You do not need to rebuild the system whenever a new model appears. Preserve the baseline, test a specific improvement, and keep it only when the results justify the added cost or complexity.
Back to the original problem
Part 1 began with notes that were hard to find again. The useful measure of this system is whether you can recover the right source when you need it and keep doing so without making maintenance another deferred task.
I do not use the browser interface very often. It is useful when I need to retrieve something, but sending notes through Telegram is easier for me. The interface solved a particular need without becoming my main way of using the system.
Most of my use is through coding agents such as Claude, Codex, and Hermes. I connect them to my Open Brain so they can retrieve relevant context across my projects. In my setup, project instructions in AGENTS.md tell them to search for information about the current project and save useful notes as they work. That is where the system has become most useful to me. Configure your client’s instruction-loading behavior rather than assuming every harness reads that file automatically, and keep the agents’ access within the data permissions you approved.
Our shared Family Brain is no longer in use. Its Supabase project was paused repeatedly during periods of low use. Supabase’s plan comparison distinguishes Free-plan project pausing from paid plans, which are not paused for inactivity. I mention our experiment because a shared setup could still be useful for another family. Before relying on a service you use only occasionally, check its inactivity policy as well as its cost.
Previous: the browser interface (optional). Return to the series guide, or revisit retrieval checks after a change.