fix(supply-chain): attest every pullable tag, and correct docs from review

Review found that the attestation covered only the multi-arch index while
create-ghcr-manifests also publishes single-arch tags (:version-amd64,
:latest-arm64, and so on) that resolve to different digests. Those were
pullable but unsigned, so verification failed for anyone who pinned one.

The matrix now attests all three subjects per image — the index and both
per-arch manifests. That also makes the SBOMs truthful: the amd64 and arm64
images contain different packages, and one SBOM on the index cannot describe
both. create-release now requires attest-images, so a release can no longer
advertise images whose signing failed.

The helm workflow's path filter now includes the inventory generator, which
could previously change without the check that validates it ever running.

The inventory header named global.imageRegistry alone as the redirect. That
only rewrites the simstudioai/* images; third-party ones also need
global.useRegistryForAllImages, and the NVIDIA device plugin is hardcoded in a
template and cannot be redirected by any values key at all.

Docs corrections from the same round:

- The copilot workloads cannot be covered by networkPolicy.egress — it is only
  rendered into policies the chart creates, and it creates none for them.
- Data drains and retention cleanup need Trigger.dev. Without it the work is
  claimed and enqueued to the database, but nothing drains that job type.
- MIGRATION_DATABASE_URL has no chart values key: the migrations init container
  builds DATABASE_URL itself and reads only the database Secret.
- Finished CronJob Jobs are deleted after ten minutes by ttlSecondsAfterFinished,
  so the history limits do not mean what the page implied.
- lock_timeout is 5s for ordinary DDL, but a migration can set it to 0 for
  statements like CREATE INDEX CONCURRENTLY.
- Losing Redis interrupts in-flight execution streams and cancellation, which
  "drops live updates and nothing else" understated.
- NEXT_PUBLIC_BRAND_BACKGROUND_COLOR sets no background; it only tells Sim
  whether the brand ground is dark.
- Pi uses its own image, not the Function base.
- doctor skips the Postgres, migration, and Redis probes on the production
  Compose layout, and does not shape-check optional secrets.
- The Daytona snapshot build needs the E2B parity manifest to exist first.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015BwsJTEQRzWJaY4BRCkPZt

Author: waleedlatif1

.github/workflows/ci.yml

@@ -620,10 +620,17 @@ jobs:
   # Attaching attestations here instead leaves the index itself untouched — they
   # are stored as separate referrer manifests that point at it.
   #
-  # The subject is the sha index digest. `imagetools create` builds the version
-  # and latest indexes from the same two per-arch manifests in the same order,
-  # so all three tags resolve to one digest and a single attestation covers
-  # every tag a customer can pull.
+  # Every pullable tag is covered. `create-ghcr-manifests` publishes both
+  # multi-arch tags (`:sha`, `:version`, `:latest`) and single-arch ones
+  # (`:version-amd64`, `:latest-arm64`, …), and those resolve to different
+  # digests — an index digest and the two per-arch manifest digests. The matrix
+  # therefore attests all three subjects per image. `imagetools create` is
+  # deterministic, so the version and latest indexes share the sha index's
+  # digest and need no separate attestation.
+  #
+  # Per-arch subjects also give a truthful SBOM: the amd64 and arm64 images
+  # contain different packages, and a single SBOM attached to the index cannot
+  # describe both.
   attest-images:
     name: Attest Images
     runs-on: ${{ (vars.CI_PROVIDER == '' || vars.CI_PROVIDER == 'blacksmith') && 'blacksmith-2vcpu-ubuntu-2404' || 'ubuntu-latest' }}
@@ -648,6 +655,9 @@ jobs:
           - ghcr.io/simstudioai/realtime
           - ghcr.io/simstudioai/pii
           - ghcr.io/simstudioai/cron
+        # The published tag suffixes, and so the distinct digests a customer can
+        # pull. Empty is the multi-arch index.
+        suffix: ['', '-amd64', '-arm64']
 
     steps:
       - name: Login to GHCR
@@ -661,17 +671,18 @@ jobs:
       # whatever that tag points at when the step runs, which is not necessarily
       # what this run published.
       #
-      # `{{json .Manifest}}` piped through jq, not `{{.Manifest.Digest}}` — the
-      # latter resolves the index to the runner's own platform and prints that
-      # manifest's digest instead, which would attest one architecture and leave
-      # the index a customer actually pulls unsigned.
-      - name: Resolve index digest
+      # `{{json .Manifest}}` piped through jq, not a bare `{{.Manifest.Digest}}`:
+      # buildx renders a format string consisting only of a `.Manifest` field as
+      # the human-readable inspect block rather than the field value, so the bare
+      # form does not produce a parseable digest.
+      - name: Resolve digest
         id: digest
         run: |
-          DIGEST="$(docker buildx imagetools inspect "${{ matrix.image }}:${{ github.sha }}" \
+          REF="${{ matrix.image }}:${{ github.sha }}${{ matrix.suffix }}"
+          DIGEST="$(docker buildx imagetools inspect "$REF" \
             --format '{{json .Manifest}}' | jq -r '.digest')"
           if [ -z "$DIGEST" ] || [ "$DIGEST" = "null" ]; then
-            echo "::error::Could not resolve a digest for ${{ matrix.image }}:${{ github.sha }}"
+            echo "::error::Could not resolve a digest for ${REF}"
             exit 1
           fi
           echo "value=${DIGEST}" >> "$GITHUB_OUTPUT"
@@ -754,11 +765,14 @@ jobs:
     name: Create GitHub Release
     runs-on: ${{ (vars.CI_PROVIDER == '' || vars.CI_PROVIDER == 'blacksmith') && 'blacksmith-4vcpu-ubuntu-2404' || 'ubuntu-latest' }}
     timeout-minutes: 10
-    needs: [create-ghcr-manifests, detect-version]
-    # Explicit results: see migrate's comment.
+    needs: [create-ghcr-manifests, attest-images, detect-version]
+    # Explicit results: see migrate's comment. attest-images is a gate, not just
+    # an ordering edge — a release must not advertise images whose signature or
+    # attestation failed to publish.
     if: >-
       !cancelled() &&
       needs.create-ghcr-manifests.result == 'success' &&
+      needs.attest-images.result == 'success' &&
       needs.detect-version.result == 'success' &&
       needs.detect-version.outputs.is_release == 'true'
     permissions:

.github/workflows/helm.yml

@@ -6,11 +6,19 @@ on:
     paths:
       - 'helm/sim/**'
       - '.github/workflows/helm.yml'
+      # The image inventory is generated from the chart and checked here, so a
+      # change to its generator has to run this workflow too.
+      - 'scripts/generate-image-manifest.ts'
+      - 'package.json'
   pull_request:
     branches: [main, staging, dev]
     paths:
       - 'helm/sim/**'
       - '.github/workflows/helm.yml'
+      # The image inventory is generated from the chart and checked here, so a
+      # change to its generator has to run this workflow too.
+      - 'scripts/generate-image-manifest.ts'
+      - 'package.json'
 
 concurrency:
   group: helm-${{ github.ref }}

apps/docs/content/docs/platform/enterprise/data-drains.mdx

@@ -260,4 +260,4 @@ curl -H "Authorization: Bearer $CRON_SECRET" \
   https://sim.example.com/api/cron/run-data-drains
 ```
 
-Each due drain is then fanned out as a `run-data-drain` background job, so the deployment also needs `TRIGGER_DEV_ENABLED` with a configured Trigger.dev project, or the default database-backed job queue, which both deployments use out of the box. See [background jobs](/platform/self-hosting/background-jobs).
+Each due drain is then fanned out as a `run-data-drain` background job, so the deployment also needs `TRIGGER_DEV_ENABLED` with a configured Trigger.dev project, and a configured Trigger.dev project. Without it the dispatcher still claims the work and enqueues it to the database, but nothing drains that queue for this job type, so the runs stay pending and never execute. See [background jobs](/platform/self-hosting/background-jobs).

apps/docs/content/docs/platform/enterprise/data-retention.mdx

@@ -205,14 +205,16 @@ curl -H "Authorization: Bearer $CRON_SECRET" \
   https://sim.example.com/api/logs/cleanup
 ```
 
-Each call fans the work out as background jobs, so the deployment also needs `TRIGGER_DEV_ENABLED` with a configured Trigger.dev project, or the default database-backed job queue, which both deployments use out of the box.
+Each call fans the work out as background jobs, so the deployment also needs `TRIGGER_DEV_ENABLED` with a configured Trigger.dev project, and a configured Trigger.dev project. Without it the dispatcher still claims the work and enqueues it to the database, but nothing drains that queue for this job type, so the runs stay pending and never execute.
 
 ### PII redaction
 
 PII redaction runs against a standalone [Presidio](https://microsoft.github.io/presidio/) service. Deploy it (see `apps/pii`) and point Sim at it:
 
 ```bash
 # The Presidio service exposing /analyze and /anonymize
+# Helm: http://<release>-pii.<namespace>.svc.cluster.local:5001
+# Docker Compose: http://<pii service name>:5001
 PII_URL=http://sim-pii.simstudio.svc.cluster.local:5001
 ```
 

apps/docs/content/docs/platform/enterprise/self-hosted.mdx

@@ -92,7 +92,7 @@ curl -H "Authorization: Bearer $CRON_SECRET" \
   https://sim.example.com/api/logs/cleanup
 ```
 
-Both features also fan work out as background jobs, so the deployment needs `TRIGGER_DEV_ENABLED` with a configured Trigger.dev project, or the default database-backed job queue, which both deployments use out of the box. See [background jobs](/platform/self-hosting/background-jobs).
+Both features also fan work out as background jobs, so the deployment needs `TRIGGER_DEV_ENABLED` with a configured Trigger.dev project, and a configured Trigger.dev project. Without it the dispatcher still claims the work and enqueues it to the database, but nothing drains that queue for this job type, so the runs stay pending and never execute. See [background jobs](/platform/self-hosting/background-jobs).
 
 ## Choose an organization model
 

apps/docs/content/docs/platform/enterprise/verified-domains.mdx

@@ -73,4 +73,4 @@ NEXT_PUBLIC_SSO_ENABLED=true
 
 `ENTERPRISE_ENABLED` turns both on together. See the [self-hosted enterprise guide](/platform/enterprise/self-hosted).
 
-Once enabled, verify domains from **Settings → Organization → Single sign-on**, in the **Verified domains** section above the identity provider configuration. The older `/settings/domains` link still resolves to the same page.
+Once enabled, verify domains from **Settings → Organization → Single sign-on**, in the **Verified domains** section above the identity provider configuration. The older `/workspace/<workspaceId>/settings/domains` path still resolves to the same page.

apps/docs/content/docs/platform/enterprise/whitelabeling.mdx

@@ -133,6 +133,8 @@ NEXT_PUBLIC_BRAND_PRIMARY_COLOR=#701ffc
 NEXT_PUBLIC_BRAND_PRIMARY_HOVER_COLOR=#6518e6
 NEXT_PUBLIC_BRAND_ACCENT_COLOR=#9d54ff
 NEXT_PUBLIC_BRAND_ACCENT_HOVER_COLOR=#8c3dff
+# Not a background: this only tells Sim whether your brand ground is dark,
+# which it uses to pick contrasting text.
 NEXT_PUBLIC_BRAND_BACKGROUND_COLOR=#0c0c0c
 ```
 
@@ -162,6 +164,8 @@ branding:
   files:
     custom.css: |
       .sidebar { background-color: #0c0c0c; }
+    wordmark.svg: |
+      <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 120 24"><text y="18">Acme</text></svg>
   # Binary files (PNG, JPG, ICO) base64-encoded
   # base64 -i logo.png | tr -d '\n'
   binaryFiles:

apps/docs/content/docs/platform/self-hosting/background-jobs.mdx

@@ -71,7 +71,7 @@ cronjobs:
   enabled: true
 ```
 
-Each job runs a small `curlimages/curl` pod that calls the app's **in-cluster Service** (not the ingress), with `concurrencyPolicy: Forbid` so a slow run never overlaps itself. The Service load-balances that single call to one replica, so a job never fans out across pods. The chart keeps three completed and one failed Job per CronJob for inspection; it sets no `backoffLimit`, so a failing job retries up to the Kubernetes default of six times before it is marked failed.
+Each job runs a small `curlimages/curl` pod that calls the app's **in-cluster Service** (not the ingress), with `concurrencyPolicy: Forbid` so a slow run never overlaps itself. The Service load-balances that single call to one replica, so a job never fans out across pods. The chart keeps three completed and one failed Job per CronJob, but `ttlSecondsAfterFinished` defaults to 600, so a finished Job is deleted ten minutes after it ends — inspect a failure promptly or collect the logs. It sets no `backoffLimit`, so a failing job retries up to the Kubernetes default of six times before it is marked failed.
 
 Disable individual jobs you do not need — billing reconciliation is the obvious one on a self-hosted install:
 

apps/docs/content/docs/platform/self-hosting/index.mdx

@@ -113,4 +113,4 @@ Sim is self-contained for the core editor and execution engine. A few features r
 | **Agent blocks** | An API key for at least one model provider | Or a self-hosted OpenAI-compatible endpoint: Ollama, vLLM, LM Studio, or LiteLLM. |
 | **Chat module** | `COPILOT_API_KEY` from sim.ai | Set `NEXT_PUBLIC_CHAT_DISABLED=true` to hide the module instead. |
 | **Integrations** | Your own OAuth app per service | See [Integrations & OAuth](/platform/self-hosting/integrations-oauth). |
-| **Remote Function / Pi execution** | Optional E2B or Daytona key, plus a Function base image | Without one, JavaScript Function code that has no `import` or `require` still runs in the in-process isolated VM. Python, Shell, JavaScript with external imports, custom Function Sandboxes, and Pi require a configured remote provider **and** an immutable Function base image — the key alone is not enough. See [Sandboxes](/platform/self-hosting/sandboxes). |
+| **Remote Function / Pi execution** | Optional E2B or Daytona key, plus a Function base image | Without one, JavaScript Function code that has no `import` or `require` still runs in the in-process isolated VM. Python, Shell, JavaScript with external imports, and custom Function Sandboxes require a configured remote provider **and** an immutable Function base image — the key alone is not enough. Pi uses a separate image, pinned with `E2B_PI_TEMPLATE_ID` or `DAYTONA_PI_SNAPSHOT_ID`. See [Sandboxes](/platform/self-hosting/sandboxes). |

apps/docs/content/docs/platform/self-hosting/redis.mdx

@@ -24,7 +24,7 @@ Sim uses Redis as a message bus and shared cache. Both deployments ship it by de
   With more than one app or realtime replica and no `REDIS_URL`, users on different pods stop seeing each other's edits and live status updates. Beyond one startup log line noting single-pod mode, nothing is logged — the app looks healthy and quietly loses events. Treat Redis as mandatory the moment `replicaCount` exceeds 1.
 </Callout>
 
-Everything Sim keeps in Redis is cache, coordination state, or an in-flight event — never committed data, which lives in PostgreSQL and object storage. Losing the instance drops live updates in progress and nothing else, so persistence is not required.
+Everything Sim keeps in Redis is cache, coordination state, or an in-flight event — never committed data, which lives in PostgreSQL and object storage. Persistence is therefore not required. Losing or restarting the instance is not free, though: in-flight execution streams and cancellation markers live here, so active runs stop streaming and a cancellation issued across the gap may not land. Completed work is unaffected.
 
 ## Configuration