Three paths to secrets that never leak.
Your DevOps team wants kernel-level protection. Your backend devs want a clean SDK. Your CI pipeline needs CLI automation. FyVault does all three — and they all share the same secrets, the same audit log, the same access policies.
Not sure which path fits?
Start here. Most teams use two or three together.
Servers / VMs / Containers
Agent
Serverless / CI / Edge
SDK
Scripts / Local dev
CLI
Agent
For teams that want maximum protection
Your DevOps team runs production servers that handle real customer data every second of every day. A leaked database credential here isn't a hypothetical — it's a breach disclosure, a legal review, and a week of lost sleep. They don't want secrets "managed." They want secrets physically unreachable.
The FyVault agent installs alongside your application and intercepts secret access at the operating system level. On Linux, it uses eBPF to hook into the kernel itself — your application code never sees, holds, or stores the actual secret value. It's not encryption. It's isolation.
Store your secrets
Add secrets through the dashboard or CLI. Pick server-side or zero-knowledge encryption depending on your compliance needs.
Register each server
Every machine gets a hardware fingerprint. If a server isn't registered, it can't receive secrets — no exceptions, no overrides.
Assign access granularly
Decide exactly which secrets each device can reach. Every assignment is audited and revocable in one click.
Install with one command
A single curl command installs the binary, creates an isolated OS user, and loads the runtime interceptors. Under two minutes.
Run your app normally
Replace .env values with FYVAULT:: placeholders. Start your app the same way you always do — the agent handles secret resolution transparently.
Linux (eBPF + kernel keyring) · macOS (Keychain + proxy) · Windows (encrypted store + proxy)
Best for: Production servers, VMs, containers, any long-running process where secrets must never touch application memory
$ curl -fsSL https://get.fyvault.com | bash $ fyvault boot --org acme Fetching secrets... Loading runtime interceptors... 12 secrets sealed. Agent ready.
Real-world scenario
Picture this: your backend runs on three EC2 instances. Today, each one has a .env file with your database password sitting in plaintext. With the agent, those files contain only placeholders. The real values live in the kernel keyring, resolved at the syscall boundary, invisible to your application process. Even if an attacker gets code execution, they can't read what doesn't exist in your process memory.
SDK
For teams that want simplicity
Your backend developers are shipping features, not configuring infrastructure. They have Lambda functions, edge workers, CI pipelines — environments that spin up, do their job, and vanish. They need secrets available in those fleeting moments without ceremony or overhead.
One import. One initialization call. Secrets arrive when you ask for them and can be scoped to short-lived session tokens that expire automatically. No agent to install, no binary to manage — just a clean API that works in any Node.js or Python runtime.
Store your secrets
Add secrets via the dashboard. Use server-side encryption so they're accessible through the API.
Generate an API key
Create a key with SECRETS_READ scope from the dashboard. Takes about ten seconds.
Install the SDK
npm install @fyvault/sdk (Node.js) or pip install fyvault (Python). Initialize it with your access token. That's the entire setup.
Fetch secrets at runtime
Call getValueByName() or get_value_by_name() wherever you need a secret. It arrives fresh, on demand, every time.
Mint session tokens
For production, create short-lived tokens scoped to exactly what each function needs. They self-destruct after their TTL expires.
Any runtime — Node.js, Deno, Bun, Python, edge functions, CI pipelines
Best for: Serverless functions, CI/CD pipelines, scripts, and edge runtimes where you need secrets without infrastructure
import { FyVault } from "@fyvault/sdk";
const fv = new FyVault({ accessToken: process.env.FYVAULT_TOKEN });
// Fetch a secret
const dbUrl = await fv.secrets.getValueByName("db-url");
// Mint a session token (optional)
const session = await fv.accessTokens.create({
ttlSeconds: 900,
scopes: ["secrets:read"],
});Real-world scenario
Your team deploys forty Lambda functions. Each one needs two or three secrets. Today, those secrets are stuffed into environment variables in your serverless config — visible to anyone with console access, logged in CloudWatch when something crashes. With the SDK, each function fetches only what it needs at runtime through a scoped token that expires in fifteen minutes. No secrets in config files. No secrets in logs.
CLI
For teams that want control
Your CI pipeline needs to pull secrets during builds. Your developers want to test locally without copying .env files from Slack. Your ops team wants to rotate a credential across twenty services with a single script. They all want the same thing: a tool that does exactly what they tell it, nothing more.
Forty-plus commands, fully scriptable, designed for automation. The CLI injects secrets as environment variables without ever writing them to disk. Pipe it into scripts, wire it into GitHub Actions, use it for local development — it fits wherever a terminal does.
Authenticate
Run fyvault login once. The CLI remembers your session so you don't re-authenticate for every command.
Create and manage secrets
Use fyvault secret create to add secrets interactively or pipe them in from scripts. Organize by project and environment.
Inject and run
fyvault run -- node app.js injects secrets as environment variables. They exist only in the child process memory — never written to disk, never in your shell history.
Linux · macOS · Windows
Best for: Local development, CI/CD automation, scripting, debugging, and any workflow where you want precise control
$ fyvault login ✓ Authenticated as ansh@acme.dev $ fyvault secret create --name db-url --value "postgres://..." ✓ Created db-url (server-encrypted) $ fyvault run -- node app.js Injecting 4 secrets... # DB_URL is available — never written to .env
Real-world scenario
It's Monday morning. A new developer joins and needs to run the project locally. Instead of someone DMing them a .env file (which will sit in their Downloads folder forever), they run fyvault login, then fyvault run -- npm start. Every secret they need is injected for that session only. When they close the terminal, the secrets are gone. No files to delete. No history to clear.
Side by side, so you can choose with confidence
Every team is different. Some need the strongest isolation possible. Others need the simplest integration path. Here's how the three approaches compare on the dimensions that actually matter.
Agent
Maximum Security
SDK
Maximum Simplicity
CLI
Maximum Control
Agent
SDK
CLI
| Setup | curl + boot | npm install / pip install | npm install (global) |
| Runtime overhead | ~3µs per syscall | HTTP per fetch | None (env vars) |
| Platform | Linux, macOS, Windows | Any JS/Python runtime | Linux, macOS, Windows |
| Offline capable | Yes (after boot) | No (needs API) | No (needs API) |
| Memory exposure | Zero (kernel only) | In-process | In-process (env vars) |
| Best for | Production servers | Serverless / CI | Local dev / scripts |
One vault. Three doors. Zero scattered secrets.
Agent boots
Production secrets sealed at kernel level
SDK deploys
Serverless functions fetch on demand
CLI debugs
Developers inspect and rotate locally
The sprawl
Someone pastes a database URL into a .env file because the deploy is in ten minutes. Six months later, the same credential lives in five places and nobody remembers which version is current.
The cascade
A new microservice needs the Stripe key, so someone copies it from the monolith. A contractor needs staging access, so credentials land in a shared Google Doc. Each decision creates an attack surface nobody can map.
The fix
Store secrets once, pick the delivery method that fits each part of your stack. When you rotate a credential, every server, function, and developer session picks up the new value automatically.