Philosophy

Why we built varsafe the way we did.

The Problem

Environment variables shouldn't be a topic of conversation. They're infrastructure — they should work and get out of your way.

But they don't. Instead:

• Teams share .env files over Slack
• Secrets get committed to repositories
• Production credentials exist on developer laptops
• No one knows who has access to what
• Rotation means editing files across multiple systems

This isn't a tooling problem. It's a design problem.

Our Approach

Principle 1: Encrypted Pipeline

Your secrets follow a secure path:

1. Encrypted at rest — Industry-standard encryption in our secure storage backend
2. Encrypted in transit — TLS between all components
3. Ephemeral in memory — Decrypted only when needed, never persisted to disk

Secrets written to files can be:

• Committed to version control
• Backed up without encryption
• Discovered by file system searches
• Left behind on disposed hardware

That's why varsafe injects secrets directly into your process's environment by default:

# Recommended: direct injection
varsafe run -- npm run dev

When you need files, you can export — but it's an explicit choice:

# When needed: export to file
varsafe export -o .env

Principle 2: Observable by Default

Security through obscurity doesn't work. Instead, we make everything visible:

• Every secret access is logged
• Every authentication event is recorded
• Every permission change is audited
• Every action has an actor

If someone accesses production secrets at 3am, you'll see it. If a departed employee's credentials are still active, you'll see it. If someone exports your secrets, you'll see it.

Trust is earned through observable, enforceable behavior.

Principle 3: Secure Defaults, Minimal Footguns

The default configuration should be secure. You shouldn't have to be a security expert to avoid common pitfalls.

Secure by default

• Production is protected by default (admin/owner only)
• Session tokens are hashed before storage (database leak doesn't expose sessions)
• Audit logs are immutable (can't cover tracks)
• Rate limiting is enabled by default (can't brute force)

If you need to do something risky, you have to explicitly ask for it.

Principle 4: CLI-First

Developers live in their terminal. A web dashboard requires context switching, clicking around, copying and pasting.

The primary interface is the CLI:

varsafe login              # One time
varsafe run -- npm dev  # Every time

The dashboard exists for management tasks — creating teams, inviting members, viewing audit logs. But the daily workflow is just two commands.

Principle 5: Simple Context Management

If you have one project, it's auto-selected. With multiple projects, set your context once and the CLI remembers it:

varsafe use -p my-api -e development

# Commands use that context
varsafe list
varsafe run -- npm run dev

Override anytime with explicit flags:

varsafe list -p other-project -e staging

No configuration files. No complex setup.

What We Don't Do

We Don't Manage Configuration

Configuration and secrets are different things. Configuration is how your app behaves. Secrets are credentials that should never be visible.

varsafe manages secrets. For configuration, use environment variables directly, config files, or feature flag services.

We Don't Automate Deployment

varsafe provides secrets. It doesn't deploy your code, run your CI/CD pipeline, or manage your infrastructure.

We integrate with your existing deployment tools. We don't replace them.

Design Decisions

Why not build our own crypto?

Cryptography is hard. Key management is hard. We use battle-tested encryption primitives and secure storage infrastructure. Our focus is on the developer experience, not on reimplementing cryptography.

Why Not Just Use .env Files?

They work. Until they don't.

.env files are:

• Easy to commit accidentally
• Hard to rotate across environments
• Invisible (who has access?)
• Inconsistent (is this the latest version?)

That's why varsafe defaults to in-memory injection. But when you need files — for CI pipelines, Docker builds, or local tooling — varsafe export generates them from the same source of truth. Every access is audited, and your .gitignore keeps them out of version control.

Why Version History?

Secrets change. Sometimes they need to change back.

Every change creates a new version. You can see exactly what changed, when, and by whom. If something goes wrong, rollback to any previous state with a single command.

No more "what was the old API key?" or "who deleted that secret?"

What Success Looks Like

When varsafe is working well:

• New team members don't ask "where's the .env file?"
• Rotation happens without a fire drill
• Compliance audits are a CSV export, not a project
• Security reviews find no secrets in repositories
• Developers think about features, not credentials

Secrets become invisible infrastructure. That's the goal.

Feedback

We're building varsafe for developers. If something doesn't feel right, tell us:

Contact form

We read everything. We respond to everything. We're building this for you.