Waleed 896d15b666 fix(helm): close blocker/real-gap findings from Helm chart best-practices audit (#5555)
* fix(helm): close blocker/real-gap findings from Helm chart best-practices audit

Verified every finding against the official Helm docs and Kubernetes Pod
Security Standards docs before fixing, and validated each fix with
helm lint/template plus the chart's own helm-unittest suite (65 -> 79
tests, all new tests confirmed to fail on the pre-fix code):

- Blocker: values.schema.json documented "minimum 32/8 characters" on
  BETTER_AUTH_SECRET/ENCRYPTION_KEY/postgresql.auth.password but never
  enforced it. Added anyOf minLength-or-empty constraints (empty stays
  legal for existingSecret/ESO modes) — verified negative/positive cases
  live, no regression for any secret-delivery mode.
- Real gap: copilot didn't support the External Secrets Operator mode the
  rest of the chart offers (app/postgresql/externalDatabase). Added
  external-secret-copilot.yaml, remoteRefs.copilot, and extended
  sim.copilot.validate with the same "map it or remove it" fail-fast
  guard app.env/realtime.env already have. Verified byte-identical
  rendering for the existing non-ESO path.
- Real gap: the OpenTelemetry Collector was the only workload missing the
  shared Restricted-profile securityContext helpers (no container-level
  hardening at all). Wired sim.podSecurityContext/containerSecurityContext
  in, preserving the collector's original UID/GID/fsGroup.
- Real gap: copilot templates hand-rolled label/selector blocks instead of
  using the chart's established sim.<component>.labels/selectorLabels
  pattern. Added sim.copilot.*/sim.copilotPostgresql.* helpers and
  refactored every consumer — confirmed byte-identical helm template
  output before/after (selector labels are immutable on upgrade, so this
  was verified, not assumed).
- Documented (README): the ingressFrom default and readOnlyRootFilesystem
  posture, both real but intentional tradeoffs the audit flagged as
  underdocumented. Added extraVolumes/extraVolumeMounts to copilot's
  Deployment (realtime/pii already had it) so the readOnlyRootFilesystem
  guidance is actually actionable for all three stateless services.

Deferred (nice-to-have, not blocking): pinning the two floating Postgres
image tags, values.schema.json stubs for ~13 uncovered top-level sections,
and an OTel collector image version bump — none are correctness issues.

* fix(helm): move copilot's static config out of the ESO-required Secret

Greptile caught a real bug: copilot.server.env shipped with non-empty
static defaults (PORT, SERVICE_NAME, ENVIRONMENT, LOG_LEVEL), unlike
app.env/realtime.env which ship fully empty. The new ESO validation
correctly required every non-empty env key to be mapped in
externalSecrets.remoteRefs.copilot — but that meant a default install
with copilot + ESO enabled failed demanding secret-store paths for
values that were never secrets.

Fixed by applying the chart's own existing pattern for this exact
problem: moved the 4 static keys into copilot.server.envDefaults
(mirroring app.envDefaults) and inlined them as plain container env,
bypassing the Secret/ExternalSecret system entirely — same rationale
already documented for app.envDefaults. Verified live that Greptile's
exact repro (default copilot env + ESO enabled, only the 7 real secrets
mapped) now renders cleanly and the four values still reach the
container. Added a regression test that fails on the pre-fix code.

* fix(helm): don't shadow copilot's existingSecret with envDefaults

Greptile and Cursor Bugbot both independently caught this: in
copilot.server.secret.create=false (existingSecret) mode, the chart
still unconditionally inlined copilot.server.envDefaults as explicit
container env. Kubernetes gives explicit env precedence over envFrom,
so a pre-existing Secret's PORT/LOG_LEVEL/etc values were silently
overridden by the chart defaults — the exact shadowing bug
app.envDefaults already guards against via its own $useExistingSecret
skip, which I forgot to mirror when copying the pattern to copilot.

Skip envDefaults entirely in existingSecret mode (matching app's
existing behavior — the pre-created Secret is the sole source of
truth), while still rendering extraEnv. Verified live: existingSecret
mode now renders no env: block at all when extraEnv is unset, and
still renders extraEnv without envDefaults leaking in when it is set.
Added two regression tests, confirmed both fail on the pre-fix code.

* fix(helm): key copilot's existingSecret check off its own secret.create, not the global ESO flag

Round 2's fix (which I copied nearly verbatim from Greptile's own
suggested diff) used $useExistingSecret := and (not
externalSecrets.enabled) (not copilot.server.secret.create) — Greptile
caught its own suggestion's remaining bug on round 3: when
externalSecrets.enabled=true globally (for app/postgresql) but copilot
itself uses copilot.server.secret.create=false with its own
pre-created Secret, that condition evaluated to non-existingSecret mode,
so envDefaults still inlined and shadowed the user's Secret values —
same bug, different trigger condition.

envFrom always points at the user-provided Secret name whenever
secret.create=false, independent of what other components do with ESO,
so the check should key on that alone. Verified live: global ESO
enabled + copilot's own existingSecret now renders no env: block and
envFrom correctly points at the pre-created secret name; the two
scenarios that should still inline (copilot itself on ESO, plain
inline mode) still work. Added a regression test, confirmed it fails
against round 2's guard.

* fix(helm): checksum/secret annotation on copilot ignores ESO-sourced secret

Cursor Bugbot caught a real bug: checksum/secret only hashed
secrets-copilot.yaml's rendered output, but under
externalSecrets.enabled=true that template renders nothing (env
credentials come from external-secret-copilot.yaml instead). Result:
changing externalSecrets.remoteRefs.copilot mappings wouldn't change
the pod template hash, so Kubernetes would never restart the copilot
pod to pick up the new mapping — stale envFrom values until a manual
restart.

Fixed by hashing the concatenation of both templates' rendered output:
whichever mode is active, only one renders non-empty content, but the
concatenated hash still changes on a mode switch or a remoteRefs
change. This can't reach into the live secret store value ESO syncs
(Helm only sees the ExternalSecret manifest at render time) — that's
an inherent ESO limitation, not something a checksum annotation can
close; documented as such in the template comment.

Note: deployment-app.yaml and deployment-realtime.yaml have this same
latent limitation in ESO mode (checksum/secret only hashes
secrets-app.yaml), but that's pre-existing code outside this PR's
diff — not fixed here to stay scoped to what Cursor actually flagged.

Verified live: the checksum differs across two different
remoteRefs.copilot.LICENSE_KEY mappings, and still changes correctly
in plain inline mode. Added a regression test.
2026-07-09 20:00:52 -07:00

Sim.ai Documentation Discord X

Ask DeepWiki Set Up with Cursor

Sim — Integrate, Context, Build, and Monitor AI agents

A workspace to build, deploy and manage AI agents and workflows.

Quickstart

Cloud-hosted: sim.ai

Open sim.ai

Self-hosted

npx simstudio

Open http://localhost:3000

Docker must be installed and running. Use -p, --port <port> to run Sim on a different port, or --no-pull to skip pulling the latest Docker images.

The Sim platform — chat on the left, the visual workflow builder on the right

Capabilities

  • Connect 1,000+ integrations and every major LLM
  • Add Slack, Notion, HubSpot, Salesforce, databases, and more
  • Build agents visually, conversationally, or with code
  • Ingest files, knowledge bases, and structured table data
  • Monitor runs, logs, schedules, and workflow activity

One workspace, every surface

Chat and workflows are just the start — tables, files, knowledge, and scheduled tasks all live in the same workspace.

Tables in Sim — structured data your agents can query

Tables — a database, built in

Files in Sim — documents for your team and every agent

Files — one store for your team and every agent

Knowledge bases in Sim — synced docs your agents can search

Knowledge — your agents' memory

Scheduled tasks in Sim — recurring agent runs on a calendar

Scheduled tasks — runs on your schedule

Self-hosting

Docker Compose

git clone https://github.com/simstudioai/sim.git && cd sim
docker compose -f docker-compose.prod.yml up -d

Open http://localhost:3000

Sim also supports local models via Ollama and vLLM. See the Docker self-hosting docs for setup details.

Manual Setup

Requirements: Bun, Node.js v20+, PostgreSQL 12+ with pgvector

  1. Clone and install:
git clone https://github.com/simstudioai/sim.git
cd sim
bun install
bun run prepare  # Set up pre-commit hooks
  1. Set up PostgreSQL with pgvector:
docker run --name simstudio-db -e POSTGRES_PASSWORD=your_password -e POSTGRES_DB=simstudio -p 5432:5432 -d pgvector/pgvector:pg17

Or install manually via the pgvector guide.

  1. Configure environment:
cp apps/sim/.env.example apps/sim/.env
# Create your secrets
perl -i -pe "s/your_encryption_key/$(openssl rand -hex 32)/" apps/sim/.env
perl -i -pe "s/your_internal_api_secret/$(openssl rand -hex 32)/" apps/sim/.env
perl -i -pe "s/your_api_encryption_key/$(openssl rand -hex 32)/" apps/sim/.env
# DB configs for migration
cp packages/db/.env.example packages/db/.env
# Edit both .env files to set DATABASE_URL="postgresql://postgres:your_password@localhost:5432/simstudio"
  1. Run migrations:
cd packages/db && bun run db:migrate
  1. Start development servers:
bun run dev:full  # Starts Next.js app and realtime socket server

Or run separately: bun run dev (Next.js) and cd apps/sim && bun run dev:sockets (realtime).

Chat API Keys

Chat is a Sim-managed service. To use Chat on a self-hosted instance:

  • Go to https://sim.ai → Settings → Chat keys and generate a Chat API key
  • Set COPILOT_API_KEY environment variable in your self-hosted apps/sim/.env file to that value

Environment Variables

See the environment variables reference for the full list, or apps/sim/.env.example for defaults.

Tech Stack

Next.js · Bun · PostgreSQL · Drizzle · Better Auth · Tailwind — and the rest of the stack

Contributing

We welcome contributions! Please see our Contributing Guide for details.

License

This project is licensed under the Apache License 2.0 - see the LICENSE file for details.

Built by the Sim team in San Francisco

Languages
TypeScript 77%
MDX 20.8%
JavaScript 1.9%
CSS 0.1%