sim: the setup wizard gives you images, not a source tree

npx sim-setup starts published images, it does not clone the source

The self-hosted path is a single command, `npx sim-setup`. What that wizard does is narrower than the name suggests. It 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 you have a running deployment and a directory to manage, not a checkout you can read, patch, or fork. Source-only local development and Kubernetes modes sit behind a different door: clone the repository and run `bun run sim-setup` inside it. Requirements for all of this are Node.js 20+ and Docker, and the landing page after setup is http://localhost:3000 in the browser. If you expected a self-hosted install to hand you the codebase, correcting that expectation is the first thing to do.

config reads declared state, status reads running processes

Two subcommands sound interchangeable and are not. `npx sim-setup config` detects the effective local-dev, Docker Compose, or current-context Helm configuration, then reports capabilities and OAuth integrations as configured, missing, or invalid, and it does so without printing credential values. `npx sim-setup status` is separate and reports whether installed services are running and healthy. The gap between them is where the time goes. A capability can read as configured while nothing is listening, because config inspects what is declared rather than what answers. If you keep more than one deployment style around, the effective configuration it picks is not necessarily the one serving your traffic. And since config will not print credential values, it can report a variable as invalid without showing you what is inside it, which sends you back to the `.env` the wizard wrote.

down keeps your data, reset archives the .env you need to rebuild

The lifecycle commands carry a distinction worth reading twice.

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

`down` removes containers and keeps the data, so it is the safe one to reach for. `reset` archives `.env` and wipes managed data, and the archived `.env` is the part that bites: that file holds the generated secrets and the Chat API key the wizard connected for you, so a reset sets aside working configuration as well as wiping data. `update` is the quietest of the three, pulling and applying Compose images without asking you what changed.

A self-hosted install still depends on a hosted Chat key

Chat is a Sim-managed service, and the wizard handles it by opening your browser. You sign in when it appears and the key is stored automatically. After that, viewing, creating, or revoking keys happens in the hosted settings page at sim.ai/selfhost/settings/chat-keys, not in the deployment directory. The consequence is that a self-hosted install is not a closed system. A vendor credential ends up in your `.env`, its lifecycle is controlled from a web page, and revoking a key for a machine you host yourself means opening a page on someone else's domain. If Chat is what your agents talk to, that dependency is a data boundary decision, and you should make it before wiring the stack into anything real.

Node.js 20+ for the wizard, [email protected] pinned for the repository

Self-hosting requirements are Node.js 20+ and Docker. The repository's own package.json tells a different story: `packageManager` is [email protected], the package is marked private with version 0.0.0, and workspaces span apps/* and packages/*. Two runtimes are in play, and which one you need depends on which door you came through. The wizard path is Node plus Docker. Development from a clone is Bun at the version the repo pins, plus the source-only modes that `bun run sim-setup` unlocks. The 0.0.0 in package.json is a placeholder for an unpublished workspace root, not a version you can quote in a bug report, so the published tags are your only real version signal. Treating the two paths as one project with one runtime is where people lose an afternoon.

update moves your deployment and leaves your checkout behind

Releases are moving quickly: v0.9.39 and v0.9.40 both landed on 1 November 2026 and v0.9.41 on 3 November 2026, with the most recent push dated 2 November 2026. The line is still 0.9.x, so no stability guarantee is attached to the command surface. More practically, the deployment runs published Sim images and `npx sim-setup update` applies whatever Compose resolves to. If you also cloned the repository to read the code or to develop, that checkout and your running install are separate version tracks, and updating one does nothing for the other. Pin your images if reproducibility matters to you, because the update subcommand is built for convenience rather than for a controlled change window with a rollback step attached.

Optional capabilities arrive one add subcommand at a time

The base install is not the whole product, and the extras attach individually.

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 chat
npx sim-setup add llm
npx sim-setup add integration slack

`npx sim-setup config` re-checks an optional capability without rerunning the full wizard, and the `add` subcommand takes the specific thing you are missing: email, storage, sandbox, jobs, cache, knowledge, chat, llm, or an integration by name. Two consequences follow. A capability you counted on may be absent until you ask for it, and nothing in the base install enumerates what you already have beyond what `config` reports. And `add integration slack` shows that OAuth wiring is per service and separate from the capability itself, so connecting a long integration list is a sequence of individual steps rather than one switch.

Desktop covers macOS 12+ only, and defaults to the hosted service

The macOS desktop build downloads from sim.ai/api/desktop/update/download, needs macOS 12+, and covers both Apple Silicon and Intel. Its one documented configuration move is pointing it at a self-hosted deployment, per the desktop docs, which means the desktop client talks to the hosted service until you retarget it yourself. That leaves one clear platform gap: on Linux or Windows there is no desktop surface, so the only self-hosted interface is the browser at http://localhost:3000. For a workspace meant to sit next to a terminal and run schedules, the missing desktop build is the constraint to plan around, not the browser fallback. Local models are the other half of that story, with Ollama and vLLM supported for self-hosted setups.

Editorial conclusion

Adopt it if you want agents, tables, files and knowledge in one place and can live with a self-hosted install that runs published images and borrows a Chat key from the vendor account. Skip it if you need an offline deployment, a Linux or Windows desktop client, or a source tree you own outright. Before committing, check four things: whether a Sim account and its Chat key sit inside your data boundary, whether an install that resets by archiving your .env is acceptable, which optional capabilities you must add by hand, and whether unreviewed image updates are a change you want running unattended.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes