keybayFive-command CLI · macOS · Linux desktop
Keep secrets
out of Git.
Commit your non-secret config and kb:// references. Keybay keeps the values in an OS-protected local store, then gives your app the environment it already expects. No Keybay account or hosted service. No Keybay daemon, network path, or shell hook.
The Keybay SDK is available. Add it with dart pub add keybay. The legacy 0.1.0 GitHub/Homebrew release predates immutable verification, and its macOS CLI fails current code-signature checks; require Keybay CLI 0.1.1 or newer.
keybay CLI · macOS / Linux
.secrets.env
Non-secret manifest
API_URL=https://staging.example.com
OPENAI_API_KEY=kb://acme-example/openai-api-keyTerminal
Store, then run
$ keybay set acme-example/openai-api-key
Value for acme-example/openai-api-key (input hidden):
Stored.
$ keybay run -- ./app.sh
Keybay example app started.
API_URL: https://staging.example.com
OPENAI_API_KEY: available (value not printed)Keybay keeps one store per OS user. Namespaces organize keys; they do not isolate them. When you use run, resolved values are passed to the child process as environment variables.
Dart / Flutter SDK
Use Keybay inside your app.
Name a store with appId, then read and write values directly. Keybay handles the storage details on iOS, Android 12+, macOS, and Linux desktop.
Dart
import 'package:keybay/keybay.dart';
final store = SecretStorage(appId: 'com.example.app');
await store.writeString('api-token', tokenFromOAuth);
final stored = await store.readString('api-token');How Keybay stores data on each platform.
Keybay makes the storage choice for you, using one documented policy for each runtime.
| Context | Stored as | Protected by |
|---|---|---|
| SDK · iOS | Data Protection Keychain items | Device-only, non-synchronizing, after first unlock |
| SDK · Android 12+ | Authenticated encrypted file | Store key wrapped by Android Keystore; actual level inspected |
| SDK · entitled macOS | Data Protection Keychain items | The same fixed item policy as iOS |
| SDK/CLI · unentitled macOS | Authenticated encrypted file | 32-byte store key in the login Keychain |
| SDK/CLI · Linux desktop | Authenticated encrypted file | 32-byte store key in an unlocked Secret Service provider |
Desktop credential stores must be available and unlocked. Keybay does not attest Apple hardware backing; on Android it reports the wrapping-key security level it actually observes.
Windows and headless deployments are unsupported.
What Keybay protects—and what it doesn't.
Full security design →- Fails closed
- If the required store is unavailable, locked, invalidated, corrupt, tampered with, or unsupported, Keybay stops. It never substitutes plaintext.
- Encrypted, coordinated writes
- On file-backed platforms, Keybay uses XChaCha20-Poly1305 with key commitment. Writes are atomic, mode
0600, fsynced, and locked across processes. - Only claims it can verify
- Android reports its wrapping key's observed security level. Keybay makes no hardware-backing claim for Apple native items.
- Protection has a boundary
- After your app reads a value—or
runadds it to a child environment—it is ordinary process data. Same-user malware, rollback, and root remain outside the threat model.
Local by design.
Keybay is for secrets that belong on one device. The CLI keeps one store per OS user; the SDK keeps a local store for each appId. It does not sync secrets, distribute them to a team, or provision production systems.
Built to stay auditable: one exact-pinned third-party runtime dependency, with the architecture and cryptographic design documented in the repository.