diff --git a/.github/workflows/rust.yml b/.github/workflows/rust.yml
index bfda6c1aca..5f13165d13 100644
--- a/.github/workflows/rust.yml
+++ b/.github/workflows/rust.yml
@@ -75,7 +75,7 @@ jobs:
           sudo rm -rf "/usr/local/share/boost"
           sudo rm -rf "$AGENT_TOOLSDIRECTORY"
       - name: Check
-        run: cargo check --all-features --all-targets
+        run: cargo check --release --all-features --all-targets
       - name: Rustfmt
         run: cargo fmt --all -- --check
       - name: Clippy
@@ -83,4 +83,4 @@ jobs:
       - name: Setup WASM
         run: rustup target add wasm32-unknown-unknown
       - name: Check WASM
-        run: cargo check -p hyperlane-core --features=strum,test-utils --target wasm32-unknown-unknown
+        run: cargo check --release -p hyperlane-core --features=strum,test-utils --target wasm32-unknown-unknown
diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml
index d44fc82a5f..7b560d63b2 100644
--- a/.github/workflows/test.yml
+++ b/.github/workflows/test.yml
@@ -219,7 +219,7 @@ jobs:
         working-directory: ./rust
 
       - name: agent tests with CosmWasm
-        run: RUST_BACKTRACE=1 cargo test --package run-locally --bin run-locally --features cosmos -- cosmos::test --nocapture
+        run: RUST_BACKTRACE=1 cargo test --release --package run-locally --bin run-locally --features cosmos -- cosmos::test --nocapture
         working-directory: ./rust
 
       - name: agent tests excluding CosmWasm
diff --git a/typescript/infra/src/infrastructure/external-secrets/helm/README.md b/typescript/infra/src/infrastructure/external-secrets/helm/README.md
index 4e6670b84d..34c36446f2 100644
--- a/typescript/infra/src/infrastructure/external-secrets/helm/README.md
+++ b/typescript/infra/src/infrastructure/external-secrets/helm/README.md
@@ -29,4 +29,3 @@ Regardless, workload identities are a more attractive long-term option, and movi
 The [documentation](https://external-secrets.io/v0.4.4/) is the best source. In short, it allows Kuberenetes Secrets to get their secrets from an external secret provided (like GCP's Secret Manager), all without a developer/deployer needing to touch the secrets themselves.
 
 The general idea is there are `SecretStore`s (or `ClusterSecretStore`s, which are the cluster-wide version), that specify how the cluster can authenticate with the external secret provider. `ExternalSecret`s can then be specified in "application" infrastructure, which allow developers to specify a template for a Secret that will be created using the secret values from the external provider (& using the credentials from the SecretStore).
-