One model. Your secrets. Every runtime.
Define secret mappings once. Resolve them consistently from AWS SSM or Azure Key Vault.

Your new developer joins the team. They need environment variables to run the app locally. What happens next? Someone sends API keys over Slack. Someone else digs up a wiki page with outdated credentials. Forty-five minutes later, their .env file is "probably correct".

Envilder fixes this in one command.

You create a JSON mapping between variable names and cloud secret paths. Envilder resolves them from AWS SSM or Azure Key Vault. The same mapping file works in local dev (CLI), CI/CD (GitHub Action), and application startup (runtime SDKs).

envilder --map=param-map.json --envfile=.env

No SaaS middleman. No vendor lock-in. Secrets stay in your cloud.

• Onboarding takes hours, not seconds. Every new developer needs someone to explain which secrets go where. Keys get shared over Slack, pasted from wikis, or copied from a colleague's machine. It's slow, error-prone, and insecure.
• Every environment has its own workflow. Local dev reads .env files. CI/CD uses vault integrations. Production has its own method. Same app, three different secret workflows.
• No single source of truth. Without a versioned contract, dev/staging/production configs drift apart. Deployments break. Nobody knows which config is correct.

• 📋 One mapping file for everything. A single param-map.json defines what secrets your app needs. Git-versioned, PR-reviewable, the same across every environment.
• ⚡ Works everywhere your code runs. CLI for local dev, GitHub Action for CI/CD, runtime SDKs for application startup. Same file, same result.
• 🛡️ Your cloud, zero infrastructure. Secrets stay in AWS SSM or Azure Key Vault. No SaaS proxy, no extra servers, no data to migrate.

Watch how easy it is to automate your .env management in less than 1 minute:

1. Create a mapping file (param-map.json):

{
  "DB_PASSWORD": "/my-app/db/password",
  "API_KEY": "/my-app/api-key"
}

2. Generate your .env file:

npx envilder --map=param-map.json --envfile=.env

That's it. Your secrets are pulled from AWS SSM and written to .env. Add .env to .gitignore. The mapping file is versioned and reviewable in PRs.

💡 Using Azure Key Vault? Add a $config section to your mapping file. See Mapping File Format below.

npm install -g envilder

💡 No install needed? npx envilder works out of the box.

Requirements: Node.js v20+. AWS CLI or Azure CLI configured. See full requirements.

AWS SSM (default):

- name: Configure AWS Credentials
  uses: aws-actions/configure-aws-credentials@v5
  with:
    role-to-assume: ${{ secrets.AWS_ROLE_TO_ASSUME }}
    aws-region: us-east-1

- name: Pull secrets from AWS SSM
  uses: macalbert/envilder/[email protected]
  with:
    map-file: param-map.json
    env-file: .env

Azure Key Vault:

- name: Azure Login
  uses: azure/login@v2
  with:
    client-id: ${{ secrets.AZURE_CLIENT_ID }}
    tenant-id: ${{ secrets.AZURE_TENANT_ID }}
    subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

- name: Pull secrets from Azure Key Vault
  uses: macalbert/envilder/[email protected]
  with:
    map-file: param-map.json
    env-file: .env
    provider: azure
    vault-url: ${{ secrets.AZURE_KEY_VAULT_URL }}

📖 Full GitHub Action docs

• 📖 Full Documentation: the complete guide at envilder.com
• Push Command Guide
• Pull Command Guide

The mapping file (param-map.json) is the core of Envilder. It's the single model that defines what secrets your app needs and where they live in your cloud provider. The same file is used by the CLI, the GitHub Action, and the runtime SDKs. You can optionally include a $config section to declare which provider and settings to use.

When no $config is present, Envilder defaults to AWS SSM Parameter Store:

{
  "API_KEY": "/myapp/prod/api-key",
  "DB_PASSWORD": "/myapp/prod/db-password",
  "SECRET_TOKEN": "/myapp/prod/secret-token"
}

Values are SSM parameter paths (e.g., /myapp/prod/api-key).

Add a $config key to declare the provider and its settings. Envilder reads $config for configuration and uses all other keys as secret mappings:

AWS SSM with profile:

{
  "$config": {
    "provider": "aws",
    "profile": "prod-account"
  },
  "API_KEY": "/myapp/prod/api-key",
  "DB_PASSWORD": "/myapp/prod/db-password"
}

Azure Key Vault:

{
  "$config": {
    "provider": "azure",
    "vaultUrl": "https://my-vault.vault.azure.net"
  },
  "API_KEY": "myapp-prod-api-key",
  "DB_PASSWORD": "myapp-prod-db-password"
}

Azure naming: Key Vault secret names only allow alphanumeric characters and hyphens. Envilder automatically normalizes names: slashes and underscores become hyphens (e.g., /myapp/db/password → myapp-db-password).

CLI flags and GitHub Action inputs always override $config values:

CLI flags / GHA inputs  >  $config in map file  >  defaults (AWS)

This means you can set a default provider in $config and override it per invocation:

# Uses $config from the map file
envilder --map=param-map.json --envfile=.env

# Overrides provider and vault URL from the map file
envilder --provider=azure --vault-url=https://other-vault.vault.azure.net --map=param-map.json --envfile=.env

Beyond the CLI and GitHub Action, Envilder provides runtime SDKs that resolve secrets directly into your application's memory at startup. No .env file written to disk, no secrets left behind. SDKs use the same map-file format as the CLI.

Install via NuGet:

dotnet add package Envilder

Load secrets into IConfiguration or inject them into the process environment:

// Option A: integrate with IConfiguration
var mapFile = new MapFileParser().Parse(
    File.ReadAllText("secrets-map.json"));
var provider = SecretProviderFactory.Create(mapFile.Config);

var config = new ConfigurationBuilder()
    .AddEnvilder("secrets-map.json", provider)
    .Build();

var dbPassword = config["DB_PASSWORD"];

// Option B: resolve + inject into environment
var client = new EnvilderClient(provider);
var secrets = await client.ResolveSecretsAsync(mapFile);
EnvilderClient.InjectIntoEnvironment(secrets);

📖 Full .NET SDK docs

Install via uv (recommended) or pip:

uv add envilder
# or
pip install envilder

Load secrets into your application with a single line:

from envilder import Envilder

# Resolve + inject into os.environ
Envilder.load('secrets-map.json')

Or route by environment, where each environment points to its own map file:

from envilder import Envilder

Envilder.load('production', {
    'production': 'prod-secrets.json',
    'development': 'dev-secrets.json',
    'test': None,  # no secrets loaded
})

📖 Full Python SDK docs

graph LR
    A["Mapping Model (param-map.json)"] --> B[Envilder]:::core
    B --> C["CLI → .env file"]
    B --> D["GitHub Action → CI/CD"]
    B --> E["SDK → app memory"]
    F["AWS SSM / Azure Key Vault"]:::cloud --> B

    classDef cloud fill:#ffcc66,color:#000000,stroke:#333,stroke-width:1.5px;
    classDef core fill:#1f3b57,color:#fff,stroke:#ccc,stroke-width:2px;

1. Define: create a param-map.json mapping env var names to cloud secret paths
2. Resolve: Envilder fetches each secret from your cloud vault
3. Deliver: secrets arrive as a .env file (CLI/GHA) or in-memory (SDKs)
4. Push: rotate or add secrets from your local environment back to the cloud

Envilder is not a secrets manager. It is a configuration resolution layer that reads from your existing cloud vault and delivers secrets where they're needed (.env file, CI/CD, app memory). No SaaS backend. No extra servers.

When Envilder shines: you already have secrets in AWS SSM or Azure Key Vault and want a versioned mapping file that resolves them everywhere: local dev, CI/CD, and app runtime. No data to migrate. No servers to deploy. No vendor to depend on.

For detailed tool-by-tool comparison including chamber and aws-vault, see envilder.com.

Envilder already covers the full dev-to-production lifecycle with CLI, GitHub Action, and runtime SDKs for .NET and Python. Here's what's coming:

👉 Full roadmap with priorities

All help is welcome! PRs, issues, ideas.

• 🔧 Use our Pull Request Template
• 🧪 Add tests where possible
• 💬 Feedback and discussion welcome
• 🏗️ Check our Architecture Documentation
• 🔒 Review our Security Policy

Supported by LocalStack.

MIT © Marçal Albert
See LICENSE | CHANGELOG | Security Policy