[wmadden-electric]

prisma dev no longer invents secrets. A secret now comes only from the environment of the current run: the shell, or a .env that prisma.config.ts loads. A required secret that is unset stops the run:

$ prisma dev module.ts
prisma dev cannot start: …
  - AUTH_SIGNING_SECRET  (required by service "auth.service": signingKey must be present (was missing))

Set each missing variable in either of these ways:
  - export it in the shell you run `prisma dev` from, or
  - load a .env file from prisma.config.ts: install the dotenv package and add import 'dotenv/config' at the top of prisma.config.ts.

An optional secret that is unset now reaches the service as absent, so a feature that depends on it stays off. A secret whose value changed since the last run restarts the services that read it.

Closes #379. Closes #380.

The problem

Until now, prisma dev gave any secret the shell left unset or empty a made-up value, local-placeholder-<16 hex>, and saved it in .prisma-composer/dev/secrets.json. A service could not tell the made-up value from a real key. prisma/asks declares its Fireworks key optional ('fireworksApiKey?': secretString()) and turns embeddings off without it. Locally it received the made-up key, turned embeddings on, and every search failed with a 401 from Fireworks. prisma/asks had to recognise the placeholder by its text (prisma/asks#233). Because the value was saved and a warm start does not redeploy, a real key set later never reached a running service (#380).

What changes

1. No made-up values (target/src/local-target/preflight.ts). The placeholder and its warning are gone.
2. Required or optional is decided by the service's own schema. ADR-0042 forbids Composer from looking inside a schema, so the dev preflight validates each service's input with every unset secret left out. If the schema accepts that, the secrets were optional. If not, prisma dev stops and names each secret whose absence alone fails validation, with the service and the schema's message.
3. The engine leaves optional secrets out. The dev preflight sends the names of absent secrets to the deploy-engine process on the variable deploy's preflight already uses (PRISMA_COMPOSER_PREFLIGHT_<extension>), as dev: followed by JSON. The serializer drops an envSecret from the input document only when its name is on that list. Deploy never sends the list, so dev and deploy still share one lowering (ADR-0041). One decoder reads both payload kinds: target/src/control/preflight-payload.ts.
4. Nothing is stored between runs. secretsStore is removed. The local Deployment provider reads current values from process.env and gives each service only the secrets and env-sourced params its own rows point at (local-target/src/compute.ts). A leftover secrets.json is deleted on start.
5. A changed value redeploys the services that read it. Hosted deploys already add a <name>:updatedAt member to each Deployment's triggers for every variable it points at. Under prisma dev that member is now an HMAC-SHA256 of the current value, under a random key in .prisma-composer/dev/fingerprint.key (mode 0600). When the value changes, Alchemy sees the trigger change and updates that deployment; other services are left alone. The key exists because Alchemy writes trigger members to its state file as given, and a bare hash would let someone check guesses against it.
6. Docs. New ADR-0058 amends ADR-0041's secrets rule and records Will's reasoning. local-dev.md, running-locally.md and the core-concepts skill describe the new behaviour.
7. Examples. examples/auth, examples/email and examples/storefront-auth stopped under prisma dev without their secrets. Each now has a committed .env.example, dotenv as a dev dependency, and import 'dotenv/config' in its prisma.config.ts.

Breaking for local dev

• An app whose required secret is unset locally used to start with a made-up value. It now stops with an error naming the variable. Fix: set it in the shell, or load a .env from prisma.config.ts.
• An optional secret that is unset now arrives absent instead of as a made-up value.
• A service now receives only the secrets and env-sourced params its own input and params point at. Code that read another service's variable directly from process.env now gets nothing.
• prisma deploy also evaluates prisma.config.ts. A .env loaded there is in the deploy's environment, and deploy uploads any secret the target stage does not have yet. Keep local-only values out of it before deploying, or deploy from a shell where it is not loaded. The guide, ADR-0058 and each example's .env.example say so.

Deploy behaviour does not change.

Tests

• local-target-preflight.test.ts is rewritten: required unset or empty stops dev with the variable and the service; optional unset or empty is absent from the document; a secret shared by two services; the payload never carries a value; a damaged key file gives the path and the fix; two runs creating the key at once agree.
• input-serializer.test.ts and preflight-payload.test.ts: deploy documents and deploy payload decoding are unchanged.
• compute-materialize-env.test.ts and dev-pointed-variables.test.ts: services get current values, only their own, and the copied pointer formats match the serializer's.
• operations.test.ts: prisma dev carries the payload to the engine and blanks a stale one.
• test/integration/test/local-dev-criteria-4-5.integration.ts, criterion 5 rewritten end to end: required unset and empty stop dev; a value from the fixture's .env reaches the service with nothing in the shell; an optional secret arrives absent; after a warm start with a changed value only the service that reads it is redeployed and sees the new value; a leftover secrets.json is deleted.
• Manual run on examples/storefront-auth, reading each service process's environment: unset stops with the error above; value A reaches auth.service and not the storefront; a warm start with value B gives auth.service value B; a value only in .env reaches the service.

Follow-up work

Recorded in .drive/deferred.md. The main item: a deploy still fails when an optional secret is missing on the platform. ADR-0042 says that case should deploy with the field left out.

Alternatives considered

• Keep placeholders only for required secrets (prisma dev replaces a secret set to an empty string with a placeholder #379's first proposal). Rejected: a made-up credential still turns features on that then fail at the external service.
• Read optionality from the schema. Rejected by ADR-0042, which allows only validate.
• A separate transport variable for dev. Rejected: one variable per extension keeps core unaware of the payload's contents; the dev: prefix keeps deploy's payload shape unchanged.
• Pass current values on every warm start instead of redeploying. Rejected: it needs a change to the emulator's resume API and restarts every service every time.
• Composer loads .env itself under prisma dev only. This would keep local values out of prisma deploy. Rejected because Will chose the ORM's model, where the user owns their environment and prisma.config.ts loads it.

Agent: schubert-65

🤖 Generated with Claude Code

[prisma-gizmo]

✅ Gizmo reviewed b9efe0a — posted 0 inline comment(s) this pass.

Open findings: none

Change walkthrough

prisma dev stops inventing secrets: a secret now comes only from the run's environment (shell or a .env that prisma.config.ts loads), a required unset secret stops dev with an error naming the variable and service, an optional one reaches the service as absent, and a changed value redeploys exactly the services that read it. Closes #379 and #380.

Dev preflight and serializer. Required-vs-optional is decided by validating each service's input with unset secrets left out (ADR-0042 compliant — the schema is never read). Absent names travel to the deploy-engine process on the existing PRISMA_COMPOSER_PREFLIGHT_<extension> transport with a dev: prefix, so one payload decoder serves both dev and deploy and deploy's payload shape is untouched. The serializer drops an envSecret leaf only when the payload names it absent; deploy behaviour is unchanged. The secrets.json store is gone — values are read fresh from process.env each run, and a leftover file is deleted on start. Changed values redeploy via the existing <name>:updatedAt trigger member, now an HMAC-SHA256 under a per-checkout random key (mode 0600) so Alchemy's state file can't be used to guess short secrets.

Examples and docs. examples/auth, examples/email and examples/storefront-auth get committed .env.example files, dotenv dev dependencies and import 'dotenv/config' in their prisma.config.ts. New ADR-0058 (renumbered from 0057, which main took for node addressing) records the decision; local-dev.md, running-locally.md and the core-concepts skill describe the new behaviour, including the caveat that prisma deploy also sees a config-loaded .env.

This pass's delta. The incremental diff is dominated by the rebase onto main's ADR-0056 dev-server work and ADR-0057 addressing work, and it all coheres with the secrets change: materializeEnv feeds dev servers the same pointed-at values from the current environment (with restart-on-change covered by the new serve tests), the pure stashRows refactor keeps boot and dev-server stashing on one path, and resource-ID/fromLegacyId migrations preserve existing deployed keys. Test suites were re-anchored to full addresses (localdevs4fixture.bkg), with per-address deployment-state assertions proving a secret rotation redeploys only the reader. The ADR renumbering left no stale references; integration and unit coverage now spans unset/empty required and optional secrets, shared secrets, warm-start rotation, and secrets.json cleanup.

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

Run configuration

• Source mode: Auto
• Repository: Unavailable
• Branch: Unavailable
• File: No configuration file from this repository applied
• Commit: Unavailable
• Layers: Organization UI
• Review profile: ASSERTIVE
• Plan: Advanced
• Run ID: a6257114-430c-45b4-884e-984f7b50023e

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

_{Comment @coderabbitai help to get the list of available commands.}

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/@prisma/composer@382

npm i https://pkg.pr.new/@prisma/composer-cli@382

npm i https://pkg.pr.new/@prisma/composer-prisma-cloud@382

commit: b9efe0a

[prisma-gizmo]

New findings: none · trace

[prisma-gizmo]

No Gizmo finding is open and the head commit has been reviewed. Approving.

[prisma-gizmo]

New findings: none · trace

[prisma-gizmo]

No Gizmo finding is open and the head commit has been reviewed. Approving.