docs: correct why an existing secret must carry the provider and coordinator keys

Author: nicktrn

apps/supervisor/src/workloadManager/kubernetes.ts

@@ -14,7 +14,7 @@ import { PlacementTagProcessor } from "@trigger.dev/core/v3/serverOnly";
 import { env } from "../env.js";
 import { type K8sApi, createK8sApi, type k8s } from "../clients/kubernetes.js";
 import { getRunnerId } from "../util.js";
-import { withBlockIoUringSeccompProfile } from "./kubernetesPodSpec.js";
+import { nodetypeNodeSelector, withBlockIoUringSeccompProfile } from "./kubernetesPodSpec.js";
 
 type ResourceQuantities = {
   [K in "cpu" | "memory" | "ephemeral-storage"]?: string;
@@ -329,13 +329,7 @@ export class KubernetesWorkloadManager implements WorkloadManager {
             schedulerName: env.KUBERNETES_SCHEDULER_NAME,
           }
         : {}),
-      ...(env.KUBERNETES_WORKER_NODETYPE_LABEL
-        ? {
-            nodeSelector: {
-              nodetype: env.KUBERNETES_WORKER_NODETYPE_LABEL,
-            },
-          }
-        : {}),
+      ...nodetypeNodeSelector(env.KUBERNETES_WORKER_NODETYPE_LABEL),
       ...(env.KUBERNETES_POD_DNS_NDOTS_OVERRIDE_ENABLED
         ? {
             dnsConfig: {

apps/supervisor/src/workloadManager/kubernetesPodSpec.ts

@@ -6,6 +6,18 @@ import type { k8s } from "../clients/kubernetes.js";
  */
 export const BLOCK_IO_URING_SECCOMP_PROFILE = "profiles/block-io-uring.json";
 
+/**
+ * An empty label is the documented off-switch: run pods then get no nodeSelector
+ * at all. The Helm chart ships an empty value, so don't collapse this into a
+ * fallback default - that would pin every chart install to a label its nodes
+ * don't carry.
+ */
+export function nodetypeNodeSelector(
+  label: string | undefined
+): Pick<k8s.V1PodSpec, "nodeSelector"> {
+  return label ? { nodeSelector: { nodetype: label } } : {};
+}
+
 /**
  * Node >= 24 always creates io_uring fds, which can't be checkpointed. Blocking
  * io_uring_setup makes libuv fall back to epoll. Other runtimes don't need this,

docs/self-hosting/kubernetes.mdx

@@ -153,7 +153,7 @@ secrets:
   existingSecret: "your-existing-secret"
 ```
 
-`PROVIDER_SECRET` and `COORDINATOR_SECRET` are not new secrets. Chart 4.5.6 made the webapp reject the shared, previously-published defaults these used to fall back to, so an existing Secret must now carry strong, unique values for both:
+The chart wires `PROVIDER_SECRET` and `COORDINATOR_SECRET` into the webapp deployment, and the pre-upgrade check requires both, so an existing Secret must include them. For a deployment that already runs, add them before upgrading:
 
 ```bash
 kubectl patch secret my-trigger-secrets -n trigger --type merge -p \
@@ -539,7 +539,7 @@ With external datastores, secrets, registry, and authentication in place, you ha
   <Accordion title="You supply your own secret (secrets.existingSecret)">
     With `secrets.existingSecret` set, the chart reads every key from your Secret and generates none, so any key the app needs must already be present there.
 
-    Chart 4.5.6 hardened this: the webapp now requires strong, unique `PROVIDER_SECRET` and `COORDINATOR_SECRET` values — it previously fell back to a shared, published default for these, which it now rejects at startup. Add both to your Secret before upgrading:
+    As of chart 4.5.6 the webapp deployment references `PROVIDER_SECRET` and `COORDINATOR_SECRET`, and the pre-upgrade check requires both, so an existing Secret must carry them. Add both before upgrading:
 
     ```bash
     kubectl patch secret my-trigger-secrets -n trigger --type merge -p \