docs(helm): say null must be applied in every layer that sets a key

`null` deletes a key from the map it is applied to, not from the pod. A key
set in both `app.env` and `app.envDefaults` survives a null on the app.env
entry alone — the deployment then inlines the envDefaults value again. Under
ESO a retained `externalSecrets.remoteRefs.app` mapping keeps syncing the key
regardless of app.env.

- README and self-hosting docs: drop the "works in all three secret modes"
  shorthand and spell out that every layer setting the key must be nulled,
  including the ESO remote mapping
- tests: cover both halves — nulling only app.env restores the envDefault,
  nulling both actually removes the key
- chart 1.5.4; staging took 1.5.3 in the meantime

Author: waleedlatif1

apps/docs/content/docs/en/platform/self-hosting/environment-variables.mdx

@@ -260,7 +260,9 @@ app:
     FREE_TABLE_ROWS_LIMIT: null
 ```
 
-Setting the variable to an empty string does **not** remove it: the chart reads an empty value as "not specified", so the inherited value still applies. Confirm what the pod will actually receive before rolling out:
+Setting the variable to an empty string does **not** remove it: the chart reads an empty value as "not specified", so the inherited value still applies.
+
+Null the variable in every layer that sets it. If it appears in both `app.env` and `app.envDefaults`, nulling only the `app.env` entry lets the `envDefaults` value apply again and the limit stays in force. With External Secrets, also drop the key from `externalSecrets.remoteRefs.app`, which keeps syncing it independently. Confirm what the pod will actually receive before rolling out:
 
 ```bash
 helm template sim ./helm/sim -f values.yaml | grep -A1 FREE_TABLE   # expect no output

helm/sim/Chart.yaml

@@ -2,7 +2,7 @@ apiVersion: v2
 name: sim
 description: A Helm chart for Sim - the open-source AI workspace where teams build, deploy, and manage AI agents
 type: application
-version: 1.5.3
+version: 1.5.4
 appVersion: "v0.7.44"
 kubeVersion: ">=1.25.0-0"
 home: https://sim.ai

helm/sim/README.md

@@ -374,7 +374,9 @@ app:
     FREE_TABLE_ROWS_LIMIT: null
 ```
 
-Or on the CLI: `--set app.envDefaults.FREE_TABLES_LIMIT=null`. This works for `app.env` and `realtime.env` too, and in all three secret modes.
+Or on the CLI: `--set app.envDefaults.FREE_TABLES_LIMIT=null`.
+
+**Null the key in every layer that sets it.** `null` deletes the key from the map you null, not from the pod — so if a key is set in both `app.env` and `app.envDefaults`, nulling only the `app.env` entry makes the inline `envDefaults` value apply again and the variable stays on the pod. The same holds for `realtime.env` / `realtime.envDefaults`. Under ESO there is a third source: a key mapped in `externalSecrets.remoteRefs.app` keeps being synced into the Secret regardless of `app.env`, so remove that mapping too. Rendering the manifest (below) is the reliable way to confirm the key is actually gone.
 
 **Setting the key to `""` instead does not remove it.** Every key under `app.env` in `values.yaml` ships as a `""` placeholder, so the templates have to treat an empty string as "the operator said nothing" — if they did not, the ten placeholders that collide with a real `app.envDefaults` value (`NEXT_PUBLIC_APP_URL`, `BETTER_AUTH_URL`, `NEXT_PUBLIC_BRAND_NAME`, `VERTEX_LOCATION`, `EMAIL_VERIFICATION_ENABLED`, …) would blank themselves out on every default install. An empty entry is a silent no-op; `null` is the deletion.
 

helm/sim/tests/env-null-deletion_test.yaml

@@ -101,6 +101,35 @@ tests:
             name: BILLING_CONCURRENCY_LIMIT_FREE
             value: "10"
 
+  - it: nulling only app.env lets a matching envDefaults value apply again
+    template: deployment-app.yaml
+    values:
+      - values/preset-free-limits.yaml
+    set:
+      <<: *defaults
+      app.env.FREE_TABLES_LIMIT: null
+    asserts:
+      - contains:
+          path: spec.template.spec.containers[0].env
+          content:
+            name: FREE_TABLES_LIMIT
+            value: "3"
+
+  - it: nulling both layers is what actually removes the key
+    template: deployment-app.yaml
+    values:
+      - values/preset-free-limits.yaml
+      - values/unset-free-limits.yaml
+    set:
+      <<: *defaults
+      app.env.FREE_TABLES_LIMIT: null
+    asserts:
+      - notContains:
+          path: spec.template.spec.containers[0].env
+          content:
+            name: FREE_TABLES_LIMIT
+            value: "3"
+
   - it: nulling a boot-critical key is still refused by the existing validator
     values:
       - values/preset-free-limits.yaml