envpkt 0.13.4 → 0.13.6
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +40 -2
- package/package.json +8 -8
package/README.md
CHANGED
|
@@ -181,6 +181,15 @@ const result = boot() // decrypts sealed values, injects into process.env
|
|
|
181
181
|
|
|
182
182
|
Mixed mode is supported — sealed values take priority, with fnox as fallback for keys without `encrypted_value`.
|
|
183
183
|
|
|
184
|
+
### Where it injects: self-launched vs serverless
|
|
185
|
+
|
|
186
|
+
Whether envpkt can replace a cloud secret store depends on one thing: **do you control how the process starts?**
|
|
187
|
+
|
|
188
|
+
- **You launch it** (server, container, VM, k8s, systemd) → `envpkt exec -- yourapp` or `boot()` injects the decrypted values straight into the process environment. No cloud secret store needed: the sealed `envpkt.toml` ships with the app, and only the age key has to reach the runtime (N secrets collapse to 1 key).
|
|
189
|
+
- **A platform launches it** (Cloudflare Workers, AWS Lambda, Vercel) → you don't own the launch, and the `age` CLI can't run inside the per-request isolate, so the platform's secret store is unavoidable. envpkt becomes the source of truth that populates and audits that store — not the injector.
|
|
190
|
+
|
|
191
|
+
> Rule of thumb: **own the launch → `exec`/`boot`, no store. Platform owns the launch → store required, envpkt feeds and audits it.** Full details: [Runtime injection guide](https://envpkt.dev/guides/runtime-injection/).
|
|
192
|
+
|
|
184
193
|
## GitHub Actions
|
|
185
194
|
|
|
186
195
|
A composite action resolves the credentials in `envpkt.toml` into the CI job — with secret values masked in the log — so later steps just see them as environment variables:
|
|
@@ -191,7 +200,7 @@ A composite action resolves the credentials in `envpkt.toml` into the CI job —
|
|
|
191
200
|
# Sealed packets are decrypted with the `age` CLI (not preinstalled on runners).
|
|
192
201
|
- run: sudo apt-get update && sudo apt-get install -y age
|
|
193
202
|
|
|
194
|
-
- uses: jordanburke/envpkt@v0
|
|
203
|
+
- uses: jordanburke/envpkt@v0
|
|
195
204
|
with:
|
|
196
205
|
config: ./envpkt.toml
|
|
197
206
|
strict: "true" # fail the build if a credential is expired/unhealthy
|
|
@@ -205,7 +214,36 @@ A composite action resolves the credentials in `envpkt.toml` into the CI job —
|
|
|
205
214
|
|
|
206
215
|
**Inputs:** `config`, `version` (npm version to run, default `latest`), `strict`, `profile`.
|
|
207
216
|
|
|
208
|
-
> Decrypting sealed packets requires the [`age`](https://github.com/FiloSottile/age) CLI on the runner (install it first, as above) — not needed if you only inject plaintext `[env.*]` defaults or resolve via fnox.
|
|
217
|
+
> Decrypting sealed packets requires the [`age`](https://github.com/FiloSottile/age) CLI on the runner (install it first, as above) — not needed if you only inject plaintext `[env.*]` defaults or resolve via fnox. Reference `@v0` for the moving major tag (re-pointed to each `0.x` release), or pin an exact release like `@v0.13.4` for immutability. `@v1` ships when envpkt reaches 1.0. Node is assumed present; add `actions/setup-node` first to pin a version.
|
|
218
|
+
|
|
219
|
+
### Anti-rot CI gate
|
|
220
|
+
|
|
221
|
+
A hand-maintained `envpkt.toml` is documentation, and documentation rots. The fix is a failing build: each `--strict` check exits non-zero so a stale or drifted config blocks the merge. Each gate is **metadata-only** (no secret values) and targets a different failure mode — compose the ones that fit:
|
|
222
|
+
|
|
223
|
+
```bash
|
|
224
|
+
# 1. Secret health — runs anywhere, no live env or age key needed.
|
|
225
|
+
# Fails on expired / stale (> lifecycle.stale_warning_days) / missing / missing-metadata.
|
|
226
|
+
envpkt audit --strict # exit 1 = degraded, 2 = critical
|
|
227
|
+
|
|
228
|
+
# 2. Cross-environment parity — keep dev/staging/prod tracking the same keys.
|
|
229
|
+
envpkt diff dev.envpkt.toml prod.envpkt.toml --exit-code
|
|
230
|
+
|
|
231
|
+
# 3. Drift vs the live environment — run where the env is actually populated
|
|
232
|
+
# (a deployed host or a pre-deploy step), NOT a bare CI runner: with no env
|
|
233
|
+
# set, every var reads as "missing" and the gate false-fails.
|
|
234
|
+
envpkt env check --strict # exit 1 on any drift (missing / untracked)
|
|
235
|
+
```
|
|
236
|
+
|
|
237
|
+
**Where each belongs.** `audit --strict` and `diff --exit-code` are environment-independent — drop them in any PR/CI job as a merge gate. `env check --strict` compares the config against the _live_ environment, so it belongs in a pre-deploy step or a host healthcheck, after the env is populated (e.g. `eval "$(envpkt env export)"`), not in a stock CI runner.
|
|
238
|
+
|
|
239
|
+
```yaml
|
|
240
|
+
# PR gate: block merges when the config rots (no secrets, no age key required)
|
|
241
|
+
- uses: jordanburke/envpkt@v0.13.4
|
|
242
|
+
with: { config: ./envpkt.toml, strict: "true" }
|
|
243
|
+
- run: envpkt diff dev.envpkt.toml prod.envpkt.toml --exit-code
|
|
244
|
+
```
|
|
245
|
+
|
|
246
|
+
> Freshness in the sense of "verified live within N days" (a credential that still _authenticates_, not just one that hasn't _expired_ on paper) is a [verification](#) capability reserved for the hosted offering — `--strict` enforces everything checkable offline today.
|
|
209
247
|
|
|
210
248
|
## For agents and fleets
|
|
211
249
|
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "envpkt",
|
|
3
|
-
"version": "0.13.
|
|
3
|
+
"version": "0.13.6",
|
|
4
4
|
"description": "Credential lifecycle and fleet management for AI agents",
|
|
5
5
|
"keywords": [
|
|
6
6
|
"credentials",
|
|
@@ -42,15 +42,15 @@
|
|
|
42
42
|
"@modelcontextprotocol/sdk": "^1.29.0",
|
|
43
43
|
"@sinclair/typebox": "^0.34.49",
|
|
44
44
|
"commander": "^15.0.0",
|
|
45
|
-
"functype": "^1.
|
|
46
|
-
"functype-log": "^1.
|
|
47
|
-
"functype-os": "^1.
|
|
48
|
-
"smol-toml": "^1.
|
|
45
|
+
"functype": "^1.5.0",
|
|
46
|
+
"functype-log": "^1.5.0",
|
|
47
|
+
"functype-os": "^1.5.0",
|
|
48
|
+
"smol-toml": "^1.7.0"
|
|
49
49
|
},
|
|
50
50
|
"devDependencies": {
|
|
51
51
|
"@types/node": "^24.13.2",
|
|
52
|
-
"ts-builds": "^3.2.
|
|
53
|
-
"tsdown": "^0.22.
|
|
52
|
+
"ts-builds": "^3.2.1",
|
|
53
|
+
"tsdown": "^0.22.3",
|
|
54
54
|
"tsx": "^4.22.4"
|
|
55
55
|
},
|
|
56
56
|
"type": "module",
|
|
@@ -71,5 +71,5 @@
|
|
|
71
71
|
"schemas"
|
|
72
72
|
],
|
|
73
73
|
"prettier": "ts-builds/prettier",
|
|
74
|
-
"packageManager": "pnpm@11.
|
|
74
|
+
"packageManager": "pnpm@11.9.0+sha512.bd682d5d03fe525ef7c9fd6780c6884d1e756ac4c9c9fe00c538782824310dcf90e3ddc4f53835f06dfaebd5085e41855e0bcbb3b60de2ac5bbab89e5036f03b"
|
|
75
75
|
}
|