CRE: CLI 1.8.0 Release (#3602)

* tenant config docs

* note about production cre: linked workflow owner vault auth

* scriptable init + templates & release notes

* added warnings about confidential http request + secrets

Author: dev-dist

public/changelog.json

@@ -398,6 +398,13 @@
     }
   },
   "data": [
+    {
+      "category": "release",
+      "date": "2026-03-26",
+      "description": "CRE CLI version 1.8.0 is now available. This release adds a tenant context cache (`~/.cre/context.yaml`) after login, scriptable `cre init` for CI pipelines, and `cre templates list --json` for machine-readable template listings.\n\nUpdate your CLI by running `cre update` when prompted, or follow the [CLI Installation guide](https://docs.chain.link/cre/getting-started/cli-installation) for fresh installations.\n\n[See all changes on GitHub](https://github.com/smartcontractkit/cre-cli/compare/v1.7.0...v1.8.0)",
+      "title": "CRE CLI v1.8.0 — Tenant Context and Scriptable Init",
+      "topic": "CRE"
+    },
     {
       "category": "release",
       "date": "2026-03-26",

src/content/cre/account/cli-login.mdx

@@ -5,7 +5,7 @@ title: "Logging in with the CLI"
 metadata:
   description: "Learn how to log in to the CRE CLI: authenticate through your browser, complete 2FA verification, and start using CLI commands."
   datePublished: "2025-11-04"
-  lastModified: "2026-02-12"
+  lastModified: "2026-03-26"
 ---
 
 import { Aside, ClickToZoom } from "@components"
@@ -80,3 +80,5 @@ Login completed successfully
 ```
 
 Your CLI session is authenticated and ready to use.
+
+In the terminal, the CLI may show **“Fetching user context…”** while it downloads your organization’s tenant configuration from the platform. It then writes **`~/.cre/context.yaml`** (registry manifest: vault gateway URL, registries, secrets auth flows, and related fields). That file is separate from your credentials file (`cre.yaml`). For details and a sanitized example, see [Tenant context cache](/cre/reference/cli/authentication#tenant-context-cache).

src/content/cre/account/managing-auth.mdx

@@ -5,7 +5,7 @@ title: "Managing Authentication"
 metadata:
   description: "Manage your CRE CLI sessions: check if you're logged in, handle expired sessions, and securely log out when needed."
   datePublished: "2025-11-04"
-  lastModified: "2026-02-12"
+  lastModified: "2026-03-26"
 ---
 
 import { Aside } from "@components"
@@ -18,6 +18,8 @@ To authenticate your CLI with your CRE account, use the `cre login` command. Thi
 
 For detailed login instructions, see the [Logging in with the CLI](/cre/account/cli-login) guide.
 
+Browser login stores **`~/.cre/cre.yaml`** (credentials) and **`~/.cre/context.yaml`** (cached **tenant context**: registry manifest from the platform, including vault gateway URL and related settings). **`cre logout`** removes both. For a full description and a sample `context.yaml` shape, see [Tenant context cache](/cre/reference/cli/authentication#tenant-context-cache).
+
 ## API key authentication
 
 {/* prettier-ignore */}
@@ -70,7 +72,7 @@ To check your deploy access status or submit a request, see [Requesting Deploy A
 
 ## Logging out
 
-To explicitly end your CLI session and remove your stored credentials, use the `cre logout` command:
+To explicitly end your CLI session and remove your stored credentials **and cached tenant context** (`context.yaml`), use the `cre logout` command:
 
 ```bash
 cre logout

src/content/cre/capabilities/confidential-http-go.mdx

@@ -47,6 +47,13 @@ This approach ensures:
 | **Request body**               | Template-based injection: secrets referenced in the request body (e.g., `{{.myApiKey}}`) are resolved inside the enclave, so sensitive values never appear in workflow memory. |
 | **Response body**              | Optionally encrypted. When `EncryptOutput` is enabled, the full response is [AES-GCM](https://en.wikipedia.org/wiki/Galois/Counter_Mode) encrypted before leaving the enclave. |
 
+<Aside type="caution" title="Do not inject sensitive values into the request as plain workflow strings">
+  **Credentials:** List sensitive values in **`VaultDonSecrets`** and reference them only with **`{{.key}}` placeholders**. Secrets read via **`runtime.GetSecret()`** (or any string you build in workflow code) and pasted into headers or body are handled in **Workflow DON** execution, not enclave-only. See [Making Confidential Requests (Go)](/cre/guides/workflow/using-confidential-http-client/making-requests-go#step-4-implement-the-request-logic).
+
+**Scope:** The enclave executes the **outbound HTTP request** and template resolution—not arbitrary workflow logic. Using `confidentialhttp.Client` does not make the rest of your workflow confidential compute.
+
+</Aside>
+
 ## Use cases
 
 ### Credential isolation

src/content/cre/capabilities/confidential-http-ts.mdx

@@ -47,6 +47,13 @@ This approach ensures:
 | **Request body**               | Template-based injection: secrets referenced in the request body (e.g., `{{.myApiKey}}`) are resolved inside the enclave, so sensitive values never appear in workflow memory. |
 | **Response body**              | Optionally encrypted. When `EncryptOutput` is enabled, the full response is [AES-GCM](https://en.wikipedia.org/wiki/Galois/Counter_Mode) encrypted before leaving the enclave. |
 
+<Aside type="caution" title="Do not inject sensitive values into the request as plain workflow strings">
+  **Credentials:** List sensitive values in **`vaultDonSecrets`** and reference them only with **`{{.key}}` placeholders**. Secrets read via **`runtime.getSecret()`** (or any string you build in workflow code) and pasted into headers or body are handled in **Workflow DON** execution, not enclave-only. See [Making Confidential Requests (TypeScript)](/cre/guides/workflow/using-confidential-http-client/making-requests-ts#step-4-implement-the-request-and-wire-it-into-your-workflow).
+
+**Scope:** The enclave executes the **outbound HTTP request** and template resolution—not arbitrary workflow logic. Using `ConfidentialHTTPClient` does not make the rest of your workflow confidential compute.
+
+</Aside>
+
 ## Use cases
 
 ### Credential isolation

src/content/cre/getting-started/part-1-project-setup-go.mdx

@@ -7,7 +7,7 @@ pageId: "getting-started-part-1"
 metadata:
   description: "Getting started Part 1 (Go): set up your first CRE project, explore the structure, and run a successful workflow simulation."
   datePublished: "2025-11-04"
-  lastModified: "2026-01-14"
+  lastModified: "2026-03-26"
 ---
 
 import { Aside, CopyText, CodeHighlightBlock } from "@components"
@@ -89,6 +89,11 @@ The CRE CLI provides an `init` command to scaffold a new project. It's an intera
 
 The CLI will then create a new `onchain-calculator` directory and initialize your first workflow within it.
 
+{/* prettier-ignore */}
+<Aside type="note" title="Scriptable init">
+  Prefer a **non-interactive** or **CI** flow? The CLI supports **`cre init --non-interactive`** and related flags—see [Project setup commands](/cre/reference/cli/project-setup).
+</Aside>
+
 ## Step 3: Explore the generated files
 
 The `init` command creates a directory with a standard structure and generates your first workflow code. Let's explore what was created.

src/content/cre/getting-started/part-1-project-setup-ts.mdx

@@ -7,7 +7,7 @@ pageId: "getting-started-part-1"
 metadata:
   description: "Getting started Part 1 (TypeScript): set up your first CRE project, explore the structure, and run a successful workflow simulation."
   datePublished: "2025-11-04"
-  lastModified: "2026-01-20"
+  lastModified: "2026-03-26"
 ---
 
 import { Aside, CopyText, CodeHighlightBlock } from "@components"
@@ -89,6 +89,11 @@ The CRE CLI provides an `init` command to scaffold a new project. It's an intera
 
 The CLI will then create a new `onchain-calculator` directory and initialize your first workflow within it.
 
+{/* prettier-ignore */}
+<Aside type="note" title="Scriptable init">
+  Prefer a **non-interactive** or **CI** flow? The CLI supports **`cre init --non-interactive`** and related flags—see [Project setup commands](/cre/reference/cli/project-setup).
+</Aside>
+
 ## Step 3: Explore the generated files
 
 The `init` command creates a directory with a standard structure and generates your first workflow code. Let's explore what was created.

src/content/cre/guides/workflow/secrets/index.mdx

@@ -5,7 +5,7 @@ date: Last Modified
 metadata:
   description: "Secure your API keys and credentials: learn how to manage secrets safely in CRE for both simulated and deployed workflows."
   datePublished: "2025-11-04"
-  lastModified: "2025-11-04"
+  lastModified: "2026-03-26"
 ---
 
 import { Aside, CodeHighlightBlockMulti } from "@components"
@@ -42,6 +42,8 @@ Your workflow environment determines how you manage secrets:
 - Your workflow retrieves secrets from the Vault at runtime
 - **Vault DON required**
 
+**Production CRE** supports **only** the **linked workflow owner** authorization model for `cre secrets`. Alternate vault authorization is **not** available in production and currently exist only in **non-production** environments.
+
 **→ Follow this guide:** [Using Secrets with Deployed Workflows](/cre/guides/workflow/secrets/using-secrets-deployed)
 
 ### 3. Secure secret management (Best practice)

src/content/cre/guides/workflow/using-confidential-http-client/index.mdx

@@ -13,7 +13,11 @@ import { Aside } from "@components"
 
 The CRE SDK provides a Confidential HTTP client that allows your workflows to interact with external APIs while keeping sensitive data private. Requests execute inside a secure enclave, secrets are injected via templates, and responses can optionally be encrypted.
 
-For a conceptual overview of what Confidential HTTP is and how it differs from the regular HTTP capability, see [The Confidential HTTP Capability](/cre/capabilities/confidential-http).
+<Aside type="caution" title="Read this before putting sensitive data in Confidential HTTP requests">
+  **Confidential HTTP does not automatically protect credentials you load with `runtime.getSecret()` / `runtime.GetSecret()`** and then paste into headers or body as plaintext. For Vault DON–style isolation, use **`vaultDonSecrets` / `VaultDonSecrets`** and **`{{.key}}` templates** only. The step-by-step guide below explains the correct pattern and common mistakes.
+</Aside>
+
+For **why** you might need Confidential HTTP—what stays off Workflow DON nodes, and [when to use it vs. regular HTTP](/cre/capabilities/confidential-http#when-to-use-confidential-http-vs-regular-http)—see [The Confidential HTTP capability](/cre/capabilities/confidential-http#whats-kept-confidential).
 
 ## Guides
 

src/content/cre/guides/workflow/using-confidential-http-client/making-requests-go.mdx

@@ -12,12 +12,12 @@ metadata:
 
 import { Aside } from "@components"
 
-The `confidentialhttp.Client` is the SDK's interface for the underlying [Confidential HTTP Capability](/cre/capabilities/confidential-http). It allows your workflow to make privacy-preserving API calls where secrets are injected inside a secure enclave and responses can be optionally encrypted.
+`confidentialhttp.Client` implements the [Confidential HTTP capability](/cre/capabilities/confidential-http-go). Use it when an outbound call should carry [sensitive credentials or request fields](/cre/capabilities/confidential-http-go#whats-kept-confidential) without assembling them as plain strings in workflow code on every node—see [when to use Confidential vs. regular HTTP](/cre/capabilities/confidential-http-go#when-to-use-confidential-http-vs-regular-http). For those values, use **`VaultDonSecrets`** with **`{{.key}}`** placeholders only; **`runtime.GetSecret()`** in headers or body follows a different trust boundary.
 
 Unlike the regular [`http.Client`](/cre/reference/sdk/http-client), the Confidential HTTP client:
 
 - Executes the request in a secure **enclave** (not on each node individually)
-- Injects secrets from the **Vault DON** using template syntax
+- Resolves **`VaultDonSecrets`** into the request via **Vault DON** template syntax
 - Optionally **encrypts the response** before returning it to your workflow
 
 ## Prerequisites
@@ -139,9 +139,11 @@ func makeConfidentialRequest(config Config, runtime cre.Runtime) (Result, error)
 }
 ```
 
-<Aside type="note" title="Alphabetic secret ordering required">
-  When using multiple secrets, pass them into `VaultDonSecrets` in alphabetical order by key. The Vault DON processes
-  secrets in a canonical order to ensure consistent behavior across nodes during execution.
+<Aside type="caution" title="Do not assemble sensitive request data in workflow code">
+  Register API credentials in the Vault DON, add them to **`VaultDonSecrets`**, and reference them **only** with **`{{.key}}` placeholders** in headers or body—not with plaintext from **`runtime.GetSecret()`** or other workflow-built strings (those run in **Workflow DON** execution on every node). See [Using secrets with deployed workflows](/cre/guides/workflow/secrets/using-secrets-deployed).
+
+With **multiple** secrets, list **`VaultDonSecrets`** keys in **alphabetical order** (Vault DON canonical ordering).
+
 </Aside>
 
 ### Step 5: Wire it into your workflow
@@ -188,7 +190,7 @@ headers := map[string]*confidentialhttp.HeaderValues{
 }
 ```
 
-The template placeholders are resolved inside the enclave. The actual secret values never appear in your workflow code or in node memory.
+The template placeholders are resolved inside the enclave. The actual secret values never appear in your workflow code or in node memory. Credentials must be wired through **`VaultDonSecrets`** as in Step 4—not interpolated from **`runtime.GetSecret()`**.
 
 ## Response encryption