Concept
What Is Secrets Management?
Secrets management is the practice of securely storing, accessing, and auditing the sensitive credentials your application needs to run — API keys, database passwords, encryption keys, and tokens. Done well, it prevents leaks, simplifies team onboarding, and gives you a full audit trail of who accessed what and when.
What Counts as a Secret?
Any value that grants access to a system, service, or dataset is a secret. If it would cause damage in the hands of an attacker, it needs to be managed as one. Common examples include:
- •API keys — Stripe, OpenAI, Twilio, SendGrid, and every other third-party service that authenticates via a bearer token or key header.
- •Database credentials — Connection strings containing usernames, passwords, and hostnames. A leaked DATABASE_URL gives an attacker direct access to your data.
- •Authentication tokens — JWT signing secrets, OAuth client secrets, session encryption keys. These control who can impersonate your users.
- •TLS and signing certificates — Private keys used for HTTPS, code signing, or mTLS between services.
- •Environment variables in .env files — The catch-all bucket where most developers store all of the above. If it’s in your .env file and not safe to publish on Twitter, it’s a secret.
Why .env Files Fail at Scale
The .env file pattern was designed for convenience, not security. It works when you're a solo developer running a side project. It breaks the moment your team grows past one person:
Plaintext on disk
Every .env file is unencrypted. Any process, dependency, or malicious script with file system access can read your production database password.
No access control
There’s no way to give a junior developer access to development secrets but not production. Everyone who has the file has everything.
No audit trail
When a key leaks, you cannot answer the most basic questions: who had access, when did the value last change, which environments were affected.
Shared over insecure channels
New team member? The .env file gets DM’d over Slack. That secret now lives in chat logs, email threads, and clipboard history — none of which you control.
Runtime vs Buildtime Secrets
Not all secrets are used the same way. Understanding when your application consumes a secret matters for security.
| Approach | How It Works | Risk |
|---|---|---|
| Buildtime | Secrets are read during the build step and baked into the artifact (Docker image, JS bundle, compiled binary). | The secret persists in every copy of the artifact. Anyone with access to the image or bundle can extract it. |
| Runtime | Secrets are injected into the process environment at startup. The application reads process.env at runtime. | Lower. The secret exists only in memory for the duration of the process. No file on disk, no value in the build output. |
Runtime injection is almost always safer. With secr run, secrets are fetched from encrypted storage and injected as environment variables at process start — no file is written to disk, and nothing is embedded in your build artifacts:
# Secrets are injected at runtime — never touch the file system
secr run -- npm start
# Your application reads them from process.env as usual
# process.env.DATABASE_URL → "postgresql://..."
# process.env.STRIPE_SECRET_KEY → "sk_live_..."Team Sharing Problems
Beyond the technical risks, unmanaged secrets create operational friction that slows teams down:
- 1.Onboarding friction. Every new developer spends their first day chasing down .env files from teammates. Missing one variable means a cryptic runtime error that takes hours to debug.
- 2.Stale secrets. Someone rotates the Stripe key in production but forgets to tell the team. Half the developers are running against an expired key for days before anyone notices.
- 3.No version history. When a deployment breaks because a secret changed, there's no way to see what the previous value was, who changed it, or roll it back.
- 4.Environment drift. Development, staging, and production slowly diverge as developers update their local .env files independently. What works in dev fails in production because of a missing or misconfigured variable.
How secr Solves This
secr replaces the .env file workflow with encrypted, centralized secrets management designed for development teams:
Encrypted storage
Secrets are encrypted with AES-256-GCM and stored server-side. Project keys are managed by AWS KMS, GCP Cloud KMS, or Azure Key Vault. Plaintext never hits disk.
Zero-disk injection
secr run injects secrets into your process environment at startup. No .env file is written. Nothing for an attacker, a malicious dependency, or an AI agent to read.
Role-based access control
Assign team members as viewers, developers, or admins. Control who sees development secrets vs production credentials. Revoke access instantly when someone leaves.
Full audit log
Every read, write, delete, and access event is logged with timestamps, user identity, and IP address. Meet compliance requirements and investigate incidents in minutes.
Version history
Every secret change is versioned. See who changed a value, when, and what the previous value was. Roll back a bad rotation with a single command.
CLI-first workflow
Manage secrets from the terminal, where developers already work. No context switching to a web dashboard for everyday operations.
# Set a secret
secr set DATABASE_URL="postgresql://user:pass@host:5432/db"
# Pull secrets into your running process — zero files on disk
secr run -- npm start
# See who changed what and when
secr ls --env production
# Rotate a key and re-encrypt all secrets
secr rotate-keyGet started in 30 seconds
npm i -g @secr/cli
secr login
secr init
secr run -- npm start