Storage without hand-waving

Know what lives where.

Keel makes the storage model inspectable. The live workspace, exported backups, optional cloud copies, and sign-in providers do different jobs. This page keeps those promises separate.

Live workspace

SQLite or PostgreSQL

SQLite is the default and keeps the workspace in one database file. PostgreSQL is available for managed hosts without persistent local disk.

Application encryption

Backups, not the live database

Snapshot backups can be encrypted with a passphrase. The live database is not end-to-end or application-encrypted. Use full-disk or volume encryption for storage-at-rest protection.

Optional copies

Your folder or storage provider

Backups can stay local or be copied to Google Drive, OneDrive, Azure Blob, or Cloudflare R2 after you configure that provider.

Moving

Export, restore, verify

Use Keel's export or backup path rather than copying a database while it is being written. Restore a test copy before removing the old install.

The GitHub idea

Possible? Yes. Best as primary storage? No.

A GitHub App could sign users in and write an encrypted vault file to a repository. That is technically real, but every sync becomes repository content activity. It brings permissions, rate limits, conflicts, repository history, and metadata leakage into a workflow that wants database semantics.

01

Identity and storage are separate

GitHub sign-in can identify a user without granting repository access. Storage permissions should be requested only if the user opts into that feature.

02

Encryption does not hide all metadata

Ciphertext can hide note content, but repository existence, update timing, file size, commits, and access relationships remain visible to GitHub.

03

Git is not a sync database

Concurrent devices can race or conflict, attachments grow history, and rekeying or deletion has to account for old commits.

Recommendation

Keep keelnotes.com public and useful. Keep notes self-hosted.

The current site should remain a product, release, and deployment guide. It should not accept notes or require a user account. That gives Keel a trustworthy front door without creating a second, multi-tenant security product.

Now: release and guidance site

Static Cloudflare site, public source, downloads, install decision support, storage truth, security policy, and no account database.

Later: optional hosted Keel

GitHub sign-in for identity, browser-side encryption, ciphertext in dedicated object storage, explicit recovery design, and a security review before beta.

If GitHub storage is added later

  1. Use a GitHub App, not a broad classic OAuth app. Ask for access only to a user-selected repository.
  2. Encrypt in the client before upload. Never send the vault key or plaintext notes to the Keel service.
  3. Store one versioned vault manifest plus chunked encrypted objects. Do not make one commit per keystroke.
  4. Define passphrase derivation, recovery, device enrollment, key rotation, conflict handling, and deletion before collecting any user data.
  5. Position GitHub as an optional backup or export target first. Dedicated object storage remains a better fit for a hosted sync service.
Best first experiment: add “export encrypted snapshot to a selected GitHub repository” as an opt-in backup provider. That tests demand without pretending GitHub is a real-time note database.

Backup checklist

  • Set a strong backup passphrase and keep it in a password manager.
  • Keep at least one copy off the machine that runs Keel.
  • Confirm the backup timestamp and size change after meaningful edits.
  • Test a restore into a separate temporary install.
  • Document the data location and recovery steps for your future self.