This is a follow-up to my first post about Envilder, where I introduced it as a simple CLI to generate .env files from AWS SSM. A year later, it has grown quite a bit, and I want to share what changed, why, and what I learned building it almost entirely with AI.
Where we left off
A year ago, Envilder did one thing: pull secrets from AWS SSM Parameter Store and write them to a .env file. That was already useful. It removed the "what's the DB password?" Slack messages and kept onboarding fast.
But real usage exposed real gaps. If you haven't seen Envilder before, here's the basic flow: create secrets via CLI and consume them in your app:
{% vimeo 1189935282 %}
The map file: one contract, every context
Before getting into features, this is the core idea behind Envilder and what makes it different from ad-hoc scripts.
Everything in Envilder revolves around a single JSON file: envilder.json. It's a declarative contract that decouples your application from the secret provider:
{
"$schema": "https://envilder.com/schema/map-file.v1.json",
"$config": {
"provider": "aws",
"profile": "my-profile"
},
"DB_PASSWORD": "/my-app/prod/db-password",
"API_KEY": "/my-app/prod/api-key",
"STRIPE_SECRET": "/my-app/prod/stripe-secret"
}
Left side: the environment variable name your app expects. Right side: the path in your secret provider. The $config` block declares the provider and credentials.
The key point: **your application never knows where secrets come from**. It depends on `envilder.json`, not on AWS SSM, not on Azure Key Vault. If you migrate from SSM to Key Vault tomorrow, you change the `$config block. Your app code, your CI/CD pipelines, your onboarding scripts don't change at all. The SDKs even let you override the provider at runtime via a fluent builder, without touching the file.
At the SDK level, this goes further: the code depends on an ISecretProvider abstraction, not on AWS or Azure directly. The map file feeds that abstraction. Switch provider in $config`, your app code stays the same.
And because `envilder.json` contains paths, not values, it **lives in your repo**, versionable, reviewable, shared across the team. When someone joins the project, they run one command and get every secret they need. When someone adds a new secret, the diff in `envilder.json` is the documentation. The same file is consumed by the CLI, all three SDKs, and the GitHub Action. One contract, every context.
## What changed (and why)
### 1. Push mode: stop switching tools
The first friction: every time someone needed to add a new secret, they had to open the AWS Console or use the AWS CLI directly. Envilder was a read-only tool.
Now you can push secrets to the cloud directly from Envilder. The powerful part: it accepts an `.env` file and your `envilder.json`, and pushes everything in one go:
```bash
envilder --push --env-file=.env --map-file=envilder.json
```
This reads the `.env` values, maps them through `envilder.json` to the right provider paths, and creates (or updates) all secrets at once. New project? Define your `envilder.json`, write your `.env` locally, push. Done. No clicking through the AWS Console, no running 15 `aws ssm put-parameter` commands.
You can also push a single key when needed:
```bash
envilder --push --key=DB_PASSWORD --value=12345 --ssm-path=/my-app/db/password
```
One tool for reading and writing. No context switching.
One detail worth noting about pull: when generating your `.env`, Envilder only overwrites the keys declared in `envilder.json`. Any other variables already in your `.env` are left untouched. This means you can safely mix Envilder-managed secrets with local-only variables (like `DEBUG=true` or `LOG_LEVEL=verbose`) without losing them on every pull.
### 2. SDKs: because `.env` files are a liability
Generating `.env` files was the original goal, but it's inherently insecure: secrets land on disk, they get accidentally committed, they go stale. The safer approach is resolving secrets at runtime, directly in your application.
Envilder now has SDKs for three platforms:
**Python** (`pip install envilder`):
```python
from envilder import Envilder
Envilder.load('envilder.json')
# secrets are now in os.environ, no file on disk
```
**.NET** (`dotnet add package Envilder`):
```csharp
// Via IConfiguration (ASP.NET)
var config = new ConfigurationBuilder()
.AddEnvilder("envilder.json")
.Build();
// Or one-liner
Envilder.Load("envilder.json");
```
The .NET SDK targets .NET Standard 2.0, so it works from .NET Framework 4.6.1 all the way to .NET 10. It integrates natively with `IConfiguration` and `IServiceCollection`. It feels like a first-class .NET library, not a wrapper.
**TypeScript/JavaScript** (`@envilder/sdk`):
```typescript
import { Envilder } from '@envilder/sdk';
const secrets = await Envilder.resolveFile('envilder.json');
```
All three SDKs support a fluent builder for runtime overrides (switch profile, provider, or vault URL without touching the map file), environment-based loading, and secret validation.
### 3. Azure Key Vault support
This is the payoff of the abstraction. The SDK architecture already had a provider interface (`ISecretProvider`), so adding Azure Key Vault was a natural extension. Same `envilder.json`, different `$config:
{
"$config": {
"provider": "azure",
"vaultUrl": "https://my-vault.vault.azure.net"
},
"DB_PASSWORD": "db-password"
}
Your app code doesn't change. You can even implement your own provider (HashiCorp Vault, GCP Secret Manager) by plugging in the interface.
4. LocalStack supports Envilder, and Envilder uses itself
LocalStack supports the Envilder project, which means the acceptance tests run against a local AWS emulation with full SSM support.
The fun part: LocalStack now requires an auth token to run. How does Envilder manage that token? With itself. The CI pipeline uses Envilder to resolve the LOCALSTACK_AUTH_TOKEN from SSM before running the tests that validate Envilder against LocalStack. It references itself as a dependency of its own test infrastructure.
5. GitHub Action
CI/CD was always the primary use case, so there's now an official GitHub Action:
- uses: macalbert/envilder/github-action@v0.7.9
with:
map-file: envilder.json
env-file: .env
6. A website
envilder.com: documentation, schema references, and a landing page. Nothing fancy, but it makes the project feel real and gives the SDKs a proper home.
Where Envilder fits
Doppler and Infisical are full platforms with their own infrastructure. Your secrets are stored on their servers, managed through their dashboards. That's a valid choice, but it comes with cost (Doppler Team at $21/user/month, Infisical Pro at $18/identity/month) and a trust trade-off.
Envilder has no infrastructure. Zero. Your secrets stay in your cloud (AWS SSM or Azure Key Vault) and never pass through a third party. Audit trails? CloudTrail or Azure Monitor. Access control? IAM or Azure RBAC. Encryption at rest, versioning? Already there. You're not giving anything up. Those capabilities come from the provider you already pay for.
Envilder just makes them easy to consume everywhere: local dev, CI/CD, application runtime. One envilder.json, one command, SDKs for three platforms. No servers, no middleman, no SaaS fees. MIT licensed.
The AI part (brief version, full post coming)
I built most of this project with AI assistance. Started with GPT-4 a year ago, went through several Claude models (Sonnet, Haiku), and the real leap came with Claude Opus 4.5 for planning and architecture decisions. For implementation with good skill definitions, Sonnet remains excellent and more cost-effective.
I also use CodeRabbit for automated code review on every PR. It catches things I miss and forces consistency.
I'm writing a dedicated post about what worked, what didn't, and where AI genuinely accelerated the project versus where it got in the way. Stay tuned.
Numbers (honest ones)
- 350 commits, 39 releases
- 8 contributors: 1 human, 7 bots (Copilot, Gemini, CodeRabbit, Jules, Dependabot, GitHub Advanced Security)
- SDKs published on npm, PyPI, and NuGet with full CI/CD pipelines
- Used internally across multiple projects at M47 AI Company
- Trusted Publishing enabled on PyPI (Sigstore attestations)
What's next
The roadmap includes drift detection (check mode), auto-discovery for bulk parameter fetching, and more provider backends. But the priority is adoption: making it easy for people to try, and making sure it works perfectly for the simple use cases it targets.
If you manage secrets with AWS SSM or Azure Key Vault and the big platforms feel like overkill, give Envilder a try:
I'd love feedback, especially from people who tried the first version.
A special thanks to Brian Rinaldi and the LocalStack team for accepting Envilder into the LocalStack for Open Source program. Their fully subsidized Ultimate tier license is what powers our acceptance test suite against a local AWS emulation.