digistay-fetch-env

Generic AWS Parameter Store → .env materializer for DigiStay apps.

It pulls an app's config + secrets from AWS Parameter Store, merges any local overrides, and writes a single .env the app reads at startup. It knows nothing about specific apps, databases, or environments — all of that is data in Parameter Store. The script is ~40 lines of bash; this package just versions and distributes it.

What it does

/digistay/<env>/<app>/config    (String JSON, non-secret)   ┐
/digistay/<env>/<app>/secrets   (SecureString JSON, secret) � ──► merge ──► .env
.env.local  (your local overrides, wins on conflict)        ┘

Install

Per project (recommended for local dev):

pnpm add -D digistay-fetch-env

then in package.json:

{
  "scripts": {
    "env:local":   "digistay-fetch-env staging <app> .env",
    "env:dev":     "digistay-fetch-env staging <app> .env",
    "env:staging": "digistay-fetch-env staging <app> .env",
    "env:prod":    "digistay-fetch-env prod <app> .env"
  }
}

<app> is the Parameter Store app name (may differ from the repo name). env:local/env:dev pull staging until a sandbox dev namespace exists.

On a server (global):

npm i -g digistay-fetch-env
digistay-fetch-env staging <app> /home/ubuntu/<app>/.env

Usage

digistay-fetch-env <env> <app> <out-file>

• <env> — dev | staging | prod (selects the PS namespace; IAM-enforced)
• <app> — the Parameter Store app name
• <out-file> — where to write the merged .env

Local overrides — .env.local

Put only the keys you want to override (your local DB, localhost URLs) in a .env.local next to the output file. Every run merges with .env.local winning, and your overrides survive re-fetches. .env.local is yours — keep it gitignored, never commit it.

Requirements

• aws CLI, configured (aws configure, region ap-south-1)
• python3
• The caller's IAM identity must be allowed to read the relevant /digistay/<env>/* parameters + kms:Decrypt.

Design

Generic by design — no per-app / per-db / per-env logic. Adding an app, a DB name, or a secret is a Parameter Store edit, touching zero code. Full database connection strings are stored as ordinary secrets. (Secrets-Manager-based rotation, if adopted, is resolved via a value template in the config blob — not by editing this script.)

MIT licensed.