FyVault
Runtime secret execution layer

Secrets that never touch
your application

Traditional secrets managers store secrets securely. FyVault executes them securely — credentials flow through your infrastructure without entering application memory. Zero code changes. Cloud only needed at boot.

How it works

Three mechanisms, one install command. Your app code stays exactly the same.

API Keys
eBPF intercepts outbound requests and rewrites headers with real keys from the kernel keyring. ~3 microsecond overhead. Works fully offline.
AWS Credentials
A signing shim reads credentials from the kernel keyring and computes SigV4. The SDK gets signed credentials, never the raw key.
Database
A protocol proxy on localhost speaks native Postgres wire protocol. Your app connects without a password. The proxy handles auth.

Zero code changes

Your .env file is the only thing that changes. Everything else stays identical.

Before (secrets exposed)

GEMINI_API_KEY=AIzaSy-realkey-here

DATABASE_URL=postgres://user:secretpw@rds:5432/db

AWS_SECRET_KEY=wJalrXUtnFEMI/real

After (placeholders only)

GEMINI_API_KEY=FYVAULT::gemini

DATABASE_URL=postgres://user@localhost:5433/db

AWS_SECRET_KEY=FYVAULT::aws

Defense in depth

Kernel isolation
Secrets live in the kernel keyring under a separate OS user. Not in .env, not in process memory. Assumes kernel integrity.
Placeholder defense
Attacker gets root? They find FYVAULT:: placeholders. Extracting real secrets requires kernel-level access — a significantly higher bar.
Offline after boot
Cloud is only needed at startup. Kill it — nothing breaks.
TLS everywhere
tcpdump shows nothing. All traffic is encrypted before it hits the wire.

One command to install

curl -fsSL https://get.fyvault.dev | bash

Registers the device, creates the isolated OS user, loads the systemd service, attaches the eBPF hook.