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:
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:
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:
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):
from envilder import Envilder
Envilder.load('envilder.json')
# secrets are now in os.environ, no file on disk
.NET (dotnet add package Envilder):
// 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):
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 landed on Claude Opus 4.5 and now 4.6.
The jump to Opus 4.6 has been significant, particularly 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)
- 136 GitHub stars
- 263 commits, 20 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.
Top comments (0)