--- title: "One year of Envilder: from a CLI script to SDKs, push mode, and a website" author: "Marçal Albert Castellví" published: "2026-05-07T00:00:00.000Z" updated: "2026-10-24T09:31:36.267Z" url: "https://zyvop.com/one-year-of-envilder-from-a-cli-script-to-sdks-push-mode-and-a-website-vhpfc" canonical: "https://dev.to/macalbert/one-year-of-envilder-from-a-cli-script-to-sdks-push-mode-and-a-website-h49" tags: ["AI","AWS","opensource","DevOps"] --- # One year of Envilder: from a CLI script to SDKs, push mode, and a website ![Cover image]() _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: [Embedded Content]() ## 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: ```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" } ``` Enter fullscreen mode Exit fullscreen mode 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 ``` Enter fullscreen mode Exit fullscreen mode 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 ``` Enter fullscreen mode Exit fullscreen mode 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 ``` Enter fullscreen mode Exit fullscreen mode **.NET** (`dotnet add package Envilder`): ```csharp // Via IConfiguration (ASP.NET)var config = new ConfigurationBuilder() .AddEnvilder("envilder.json") .Build(); // Or one-linerEnvilder.Load("envilder.json"); ``` Enter fullscreen mode Exit fullscreen mode 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'); ``` Enter fullscreen mode Exit fullscreen mode 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`: ```json { "$config": { "provider": "azure", "vaultUrl": "https://my-vault.vault.azure.net" }, "DB_PASSWORD": "db-password" } ``` Enter fullscreen mode Exit fullscreen mode 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. > _I wrote up this pattern in full, from the_ `envilder.json` _mapping to the Docker Compose wiring that keeps the token out of Git:_ [_How I run LocalStack without committing LOCALSTACK\_AUTH\_TOKEN_]()_._ ### 5\. GitHub Action CI/CD was always the primary use case, so there's now an official GitHub Action: ```yaml - uses: macalbert/envilder/github-action@v0.7.9with: map-file: envilder.json env-file: .env ``` Enter fullscreen mode Exit fullscreen mode ### 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: - 🌐 [envilder.com]() - 🔧 [GitHub]() - 📦 [npm (CLI)]() · [npm (SDK)]() · [PyPI]() · [NuGet]() 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.