Reuse credential options across V2 docs

content/docs/get-started/choose-your-stack.mdx

@@ -84,13 +84,9 @@ A database breach defeats encryption at rest, because the database decrypts on r
 
 ## From development to production
 
-| Stage | Credentials | Setup |
-|---|---|---|
-| Local development | Device-based | `stash init` per developer. No environment variables. |
-| CI and staging | Machine | An application client key, plus `CS_*` environment variables. |
-| Production | Machine | Same, with the client key held in your secret manager. |
+<CipherStashCredentials />
 
-Device auth gives each developer their own identity, so local decryptions are attributable. There's no interactive device in CI, hence the switch. See [going to production](/stack/deploy/going-to-production).
+Device auth gives each developer their own identity, so local decryptions are attributable. There is no interactive device profile in CI, hence the switch to explicit credentials. See [Deployment](/guides/deployment) for build-time availability, environment separation, and rollout gates.
 
 ## Still not sure
 

content/docs/get-started/quickstart.mdx

@@ -182,4 +182,4 @@ You encrypted a field, stored it, queried it without decrypting, and read it bac
 - **Using an ORM or Supabase?** The [Drizzle](/stack/cipherstash/encryption/drizzle) and [Supabase](/integrations/supabase) integrations wrap your existing client so queries look normal.
 - **No app changes possible?** [CipherStash Proxy](/reference/proxy) sits in front of Postgres and does this transparently.
 - **Bind decryption to a user.** [Provable access control](/solutions/provable-access) ties a value to the identity that encrypted it.
-- **Ready to deploy?** [Going to production](/stack/deploy/going-to-production) covers the switch from device auth to machine credentials.
+- **Ready to deploy?** [Deployment](/guides/deployment) covers credential choices, environment promotion, and production rollout gates.

content/docs/guides/deployment/index.mdx

@@ -21,7 +21,9 @@ For the detailed dual-write, backfill, and cutover procedure for populated colum
 
 ## Credentials at build and runtime
 
-An encryption client constructed at module load may authenticate when a build tool imports that module. In that case, `CS_WORKSPACE_CRN`, `CS_CLIENT_ID`, `CS_CLIENT_KEY`, and `CS_CLIENT_ACCESS_KEY` must be available during both the build and runtime phases.
+<CipherStashCredentials />
+
+An encryption client constructed at module load may authenticate when a build tool imports that module. In that case, the four `CS_*` variables shown above must be available during both the build and runtime phases.
 
 Do not let a local `stash auth login` session mask missing deployment credentials. Reproduce the production build in a clean environment that has only the secrets explicitly supplied by the deployment platform.
 

content/docs/guides/migration/encrypt-existing-data.mdx

@@ -27,7 +27,7 @@ Do not start the backfill until dual-writes are running in every deployed writer
 
 - Install EQL and configure your encryption client. For Supabase, complete the [Quickstart](/integrations/supabase/quickstart) against a development table first.
 - Inventory every writer of the columns: services, jobs, Edge Functions, imports, seeds, RPC functions, webhooks, and administrative tools.
-- Make the same CipherStash machine credentials available to the deployed application and the backfill job.
+- Make the same CipherStash deployment credentials available to the application and backfill job; see [Credentials at build and runtime](/guides/deployment#credentials-at-build-and-runtime).
 - Decide which encrypted capability each column needs by following [EQL core concepts](/reference/eql/core-concepts).
 
 The examples migrate `patients.name` and `patients.date_of_birth`:
@@ -127,7 +127,7 @@ npx stash encrypt backfill --table patients --column date_of_birth
 The command pages by primary key, encrypts rows in chunks, and records checkpoints. It is resumable and idempotent. For a non-interactive job, acknowledge the deployment gate with `--confirm-dual-writes-deployed`.
 
 <Callout type="warn">
-Run the backfill with the same CipherStash workspace and credentials as the deployed application. A local CipherStash profile may point to a different workspace, producing values the production application cannot decrypt.
+Run the backfill with the same CipherStash workspace and keyset as the deployed application. A local developer profile may point to a different workspace, producing values the production application cannot decrypt. Use the deployed environment's explicit `CS_*` values for the job.
 </Callout>
 
 </Step>

content/docs/integrations/drizzle.mdx

@@ -31,6 +31,12 @@ npx stash eql install
 The v3 install (the default) runs directly against the database and cannot generate a Drizzle migration: `--drizzle` is rejected for a v3 install. EQL is therefore not part of your migration history, so a database rebuilt from migrations will not have it. Re-run the install after a rebuild.
 </Callout>
 
+## Credentials
+
+<CipherStashCredentials />
+
+The native Stack client used below discovers the four `CS_*` variables first, then falls back to the developer profile. Use separate credentials for each deployed environment.
+
 ## Declare the table
 
 The column type *is* the capability. There are no flags to configure. `TextEq` answers equality and nothing else, `IntegerOrd` answers ranges and ordering, `TextMatch` answers free-text containment, and a bare `Text` or `Bigint` is storage-only.

content/docs/integrations/supabase/edge-functions.mdx

@@ -35,28 +35,23 @@ Map the `wasm-inline` entries in your function's `deno.json`:
 Provide the four `CS_*` values explicitly through an env file when serving locally and through Supabase secrets when deployed.
 </Callout>
 
-Provide the `CS_*` credentials when you serve the function. Generate them with `stash env` rather than assembling the file by hand — it prints the deployment variables for the workspace you are authenticated against, so redirect it straight to the env file:
+<CipherStashCredentials />
+
+For an Edge Function, use the CLI or Dashboard option; the developer profile cannot cross into the Deno runtime. To create a dedicated local credential set and write it directly to the function's env file:
 
 ```bash example-id="supabase-edge-stash-env"
-npx stash env > ./supabase/functions/.env.local
+npx stash env --name edge-dev --write ./supabase/functions/.env.local
 ```
 
-`--write` writes to a file instead of stdout if you would rather not redirect. The command is marked experimental, so read what it emits before committing to it — and never commit the file itself. The [CLI reference](/reference/cli/env) has the full flag set.
+Never commit this file. Each successful `stash env` run creates a new credential with a unique name, and the access key cannot be shown again.
 
 Then serve the function against that file:
 
 ```bash
 supabase functions serve --env-file ./supabase/functions/.env.local
 ```
 
-```sh title="supabase/functions/.env.local"
-CS_WORKSPACE_CRN=crn:ap-southeast-2.aws:<workspace-id>
-CS_CLIENT_ID=...
-CS_CLIENT_KEY=...
-CS_CLIENT_ACCESS_KEY=...
-```
-
-For deployed functions, set the same values as [Edge Function secrets](https://supabase.com/dashboard/project/_/settings/functions).
+For deployed functions, add the same four values as [Edge Function secrets](https://supabase.com/dashboard/project/_/settings/functions). Use a separate credential set for production rather than copying the local values.
 
 ## Encrypt and decrypt in a function
 

content/docs/integrations/supabase/index.mdx

@@ -37,6 +37,7 @@ With EQL 3.0.4, the Supabase wrapper supports encrypted equality, range, and ord
 | Look up the complete wrapper API | [`encryptedSupabase` reference](/reference/stack/supabase) |
 | Bind decryption to the signed-in user | [Supabase Auth](/integrations/supabase/auth) |
 | Encrypt inside Supabase Edge Functions | [Edge Functions](/integrations/supabase/edge-functions) |
+| Choose local or deployment credentials | [Workspace credentials](/reference/workspace/configuration#credentials) |
 | Use an ORM against Supabase Postgres | [Drizzle](/integrations/drizzle) or [Prisma ORM 8](/integrations/prisma) |
 | Encrypt columns that already contain data | [Encrypt existing data](/guides/migration/encrypt-existing-data) |
 | Plan a production rollout or rollback | [Deployment guide](/guides/deployment) |

content/docs/integrations/supabase/quickstart.mdx

@@ -58,7 +58,7 @@ If the command generates a Supabase migration instead of applying EQL directly,
 npx stash eql status
 ```
 
-The native Stack client automatically uses the developer profile created by this login. You do not need `CS_*` machine credentials for local development; those are for deployed environments.
+The native Stack client automatically uses the developer profile created by this login. You do not need the four deployment environment variables for local development. When you deploy, [choose a deployment credential source](/guides/deployment#credentials-at-build-and-runtime).
 
 <Callout type="idea">
 **Using an agent?** An agent can drive the same setup. If no developer profile exists, it should start `npx stash auth login --json --region <region> --supabase`, show you the returned verification URL, and leave the command running until authorization completes. It can then run `npx stash init --supabase --region <region>`.

content/docs/integrations/supabase/supabase-js.mdx

@@ -46,7 +46,11 @@ SUPABASE_ANON_KEY=...
 DATABASE_URL=postgresql://...
 ```
 
-The encryption client also needs a local developer profile created by `stash auth login`, or `CS_*` machine credentials in a deployed environment. The [Quickstart setup](/integrations/supabase/quickstart#initialize-cipherstash) creates and uses the developer profile.
+## Credentials
+
+<CipherStashCredentials />
+
+The [Quickstart setup](/integrations/supabase/quickstart#initialize-cipherstash) creates and uses the developer profile. In CI or a deployed application, add the four `CS_*` variables to the same server environment as the Supabase settings above.
 
 ## Create the client
 

content/docs/reference/proxy/configuration.mdx

@@ -48,7 +48,7 @@ docker compose up
 <Callout type="info">
 Unlike the Stack SDK, Proxy **always requires credentials to be supplied explicitly**, because it runs as a separate process or container and cannot use the host's device-based authentication.
 
-For local development, create a client key and access key in the [Dashboard](https://dashboard.cipherstash.com). For production, see [Going to production](/stack/deploy/going-to-production).
+Create the four variables with `stash env` or the Dashboard, then supply them to the Proxy container. [Workspace credentials](/reference/workspace/configuration#credentials) shows both options and the complete environment block.
 </Callout>
 
 ## Setting up the database schema

content/docs/reference/workspace/configuration.mdx

@@ -7,19 +7,11 @@ components: [platform, encryption]
 
 A workspace is identified by its **CRN** and accessed with a **client key** and an **access key**. How those credentials reach your application differs between local development and production.
 
-## Local development
+## Credentials
 
-For local development, credentials are handled automatically by device-based authentication. Run `stash init` to set up your device:
+<CipherStashCredentials />
 
-```bash cta cta-type="quickstart" example-id="stash-init-workspace"
-npx stash init
-```
-
-This creates a device-backed client key with access to the workspace's default keyset. No environment variables are needed.
-
-## Production credentials
-
-In production and CI/CD, a workspace is configured with explicit credentials:
+## What the deployment variables mean
 
 | Credential | Description |
 |---|---|
@@ -28,9 +20,7 @@ In production and CI/CD, a workspace is configured with explicit credentials:
 | Client key | Your half of the dual-party key split |
 | Access key | Authenticates API calls to CipherStash |
 
-These are the same credentials the [Stack SDK](/reference/stack) and [Proxy](/reference/proxy/configuration) consume. For the full set of environment variables and programmatic options, see the [Stack SDK configuration reference](/reference/stack).
-
-See [going to production](/stack/deploy/going-to-production) for a step-by-step guide to generating them.
+These are the same credentials the [Stack SDK](/reference/stack) and [Proxy](/reference/proxy/configuration) consume. For build-time availability, environment separation, and production rollout gates, see [Deployment](/guides/deployment).
 
 ## Keysets