Waleed
6b7fd1a88d
* fix(webhooks): stop the generic webhook publishing a closed output schema
Declaring outputs on the generic webhook trigger did not add three reference
completions — it made those three the only legal fields on the block.
`collectBlockData` registers any non-empty output declaration as an exhaustive
schema, and `resolveBlockReference` then throws `InvalidFieldError` for any
reference outside it that resolves to `undefined`. A generic webhook receives
whatever the caller sends, so every workflow reading a body field started
failing the moment a delivery omitted that field, instead of resolving to
`undefined` and letting the condition evaluate falsy as it always had.
Revert the declaration to `{}` and record why it has to stay that way. The
request metadata is still merged into the workflow input by the provider's
`formatInput`; it is only undeclared, which is what keeps the shape open.
Offering these as editor completions needs a way to mark outputs as hints
rather than a closed schema — a change to `getRegistrySchema`, not to this list.
Pins the behavior at the executor level rather than on the trigger config,
since the config assertion is what passed while the block was broken.
* chore(audits): re-record the workspace module-graph baseline
`check:tool-registry-boundary` fails on CI for any branch right now: the
knowledge page measures 2255 modules against a 2209 baseline, one module past
the max(25, 2%) allowance. It passes locally at 2253, which is why it only
shows up in CI — the two platforms resolve a couple of modules differently, and
the route happened to sit inside that gap.
The drift is not from any one change. 26 of the 34 recorded routes have grown
since the baseline was last written, by up to +44. Measuring this branch's
route with and without its own diff gives 2253 either way, so it contributes
nothing; it is just the branch that happened to cross the line.
Re-records all 34 entries, which is what the script prescribes. No gateway was
added or removed on any route — only the module counts moved — so the boundary
this audit exists to protect is unchanged and the first assertion, that the
tool registry stays out of every workspace page graph, still passes.
Worth a separate look at why the workspace pages have grown this much; this
commit only stops a stale number from blocking unrelated work.
* chore(tests): give the block-data test helper an explicit return type
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.
