Waleed
aba681133a
* refactor(auth): drop the isProduction prop nothing on the signin path reads Same shape as the `isWorkflowRunning` removal: declared, required, threaded through every layer, and never read at the end of the chain. `SocialLoginButtons` declares `isProduction: boolean` as a REQUIRED prop and never reads it, so every caller had to produce and forward a value that was discarded. Neither `login-form` nor `signup-form` reads it either — each only declares it, destructures it, and passes it down. `signup-form` forwards it twice, through its own inner `SignupFormContent` hop. With the chain gone, `getOAuthProviderStatus` has no consumer for the `isProduction: isProd` it returned: the pages destructured it only to forward it, and `/api/auth/providers` already takes just the three availability flags. So the return value and its `isProd` import go too. `isProduction` stays alive where it is genuinely used — `verify-content.tsx` branches on it and hands it to `useVerification`, and imports `isProd` directly rather than through this helper. That path is untouched. Found by the rule enabled in #7037: it was the only `.tsx` unused-parameter warning in `apps/sim`. (cherry picked from commit331c2ed2ed) * refactor: drop two more props declared, threaded, and never read Same shape as the two already in this PR, found by sweeping the rest of the unused-parameter list for params callers actively compute and pass. `FieldItem.level` is the worse of the two. It is a required `level: number` that the component never reads, and `FieldTreeNodes` exists to thread it: declared, destructured, handed to `FieldItem`, and incremented on every recursion (`level={level + 1}`) from a `level={0}` seed. So a depth counter was carried through an arbitrarily deep tree to feed a component that ignores it. Indentation comes from the nested wrapper divs (`ml-1.5 pl-2.5`, `ml-3 pl-2.5`), not from the counter — removing it changes no rendering. `useMentionMenu`'s `onContextSelect` is a required prop carrying the TSDoc "Callback when a context is selected". The hook never invokes it, so that contract is unimplemented and a future caller would reasonably rely on it. Only the dead hand-off goes there. `addContextNotified` stays: the caller invokes it directly at five sites, and the ref sinks behind it keep its identity stable for those. Context selection has always worked because the caller does the work itself, not because the hook calls back. (cherry picked from commit110ba76df3) * refactor: drop two more dead prop chains in the sub-block editor `GroupedCheckboxList` declares `title` (required) and `maxHeight` and reads neither. It renders its own hardcoded copy instead — `Select PII Types to Detect` for the header and `PII types` for the field label — so a block author who sets `title` on a `grouped-checkbox-list` subBlock gets silence, and the `maxHeight = 400` default implies a scroll ceiling that is never applied. Both props go, along with the two values `sub-block.tsx` was passing. `flatTagList` was threaded through the recursive tag renderers to a dead end: declared on `NestedTagRendererProps`, inherited by `FolderContentsProps`, destructured in both, forwarded once more, and read by neither. Its real consumer is `flatTagIndexMap`, built from it at the top level and documented "Map from tag string to index for O(1) lookups" — so the array was being carried alongside its own index through arbitrary nesting depth. The top-level memo and its length checks stay; only the descent goes. Note the component's copy is PII-specific while its name and props present as generic. Renaming it is a separate call, not made here. Both removals were caught mid-flight by `tsc`: my line patterns also matched a live `flatTagList` on `KeyboardNavigationHandler` and a live `title` on `Switch`, which is exactly why the type-check runs before the commit and not after. (cherry picked from commit5db44f347b) * refactor(custom-blocks): drop the workspaceId three mutation hooks never use `usePublishCustomBlock`, `useUpdateCustomBlock` and `useDeleteCustomBlock` each take `workspaceId?: string` and never read it. `custom-block-detail.tsx` passes it to all three. The parameter looks like it was meant to narrow the invalidation to `customBlockKeys.list(workspaceId)`, but `lists()` is the level CLAUDE.md's targeted-invalidation rule actually prescribes, and it is a correct superset. So the invalidation is right as written and the parameter is simply vestigial — removing it is the honest fix, and narrowing the key would be a separate call with its own risk of under-invalidating. Worth recording that these three were reported to me as having zero callers and therefore being dead exports. They are not: the search that produced that claim omitted `apps/sim/ee`, where all three are used. (cherry picked from commit2d0854a587)
A workspace to build, deploy and manage AI agents and workflows.
Quickstart
Cloud-hosted: sim.ai
Self-hosted
npx sim-setup
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, and knowledge all live in the same workspace.
Tables — a database, built in |
Files — one store for your team and every agent |
Knowledge — your agents' memory |
Self-hosting
Requirements: Node.js 20+ and Docker.
npx sim-setup is an interactive wizard that creates a small sim/ deployment directory, provisions the database, generates secrets, writes .env, connects a Chat API key, and starts the published Sim images with Docker Compose. It does not clone the repository.
When it finishes, open http://localhost:3000.
Inside a cloned Sim repository, run bun run sim-setup to unlock the source-only local development and Kubernetes modes.
Reconfigure an optional capability without rerunning the full wizard:
npx sim-setup config
npx sim-setup add email
npx sim-setup add storage
npx sim-setup add sandbox
npx sim-setup add jobs
npx sim-setup add cache
npx sim-setup add knowledge
npx sim-setup add llm
npx sim-setup add integration slack
npx sim-setup config detects the effective local-dev, Docker Compose, or current-context
Helm configuration and reports configured, missing, or invalid capabilities and OAuth
integrations without printing credential values. This is separate from npx sim-setup status,
which reports whether installed services are running and healthy.
Manage your install from its directory:
npx sim-setup start | stop | restart # bring your install up / down / cycle
npx sim-setup update # pull and apply Compose images
npx sim-setup status # what's installed and healthy
npx sim-setup logs # follow logs
npx sim-setup doctor # diagnose configuration problems
npx sim-setup down # remove containers (data kept)
npx sim-setup reset # archive .env and wipe managed data
The setup package detects how you're running and acts accordingly. Use --dir <path> to create or manage a deployment somewhere other than ./sim.
Sim also supports local models via Ollama and vLLM. See the self-hosting docs for details.
Chat API Keys
Chat is a Sim-managed service. npx sim-setup connects a Chat API key for you — sign in when it opens your browser and the key is stored automatically. To view, create, or revoke keys later, go to sim.ai/selfhost/settings/chat-keys.
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
- Framework: Next.js (App Router)
- Runtime: Bun
- Database: PostgreSQL with Drizzle ORM
- Authentication: Better Auth
- Schema Validation: Zod
- UI: Shadcn, Tailwind CSS
- Streaming Markdown: Streamdown
- State Management: Zustand, TanStack Query
- Flow Editor: ReactFlow
- Docs: Fumadocs
- Monorepo: Turborepo
- Realtime: Socket.io
- Background Jobs: Trigger.dev
- Remote Code Execution: E2B
- Isolated Code Execution: isolated-vm
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.
