Installation

InstallCopy Anchor Link

curl -fsSL https://sdods.com/install.sh | sh

curl -fsSL https://sdods.com/install.sh | sh -s -- --workspace ~/my-tests --mcp claude

With a package managerCopy Anchor Link

The script is the front door because it works on a machine that has nothing. If you already run a package manager, these install the same software and let it handle upgrades.

npmCopy Anchor Link

The CLI is a normal global package. This is exactly what the installer script does for you, minus the Node check, the browser download and the PATH shim:

npm install -g @sdods/cli

Browser engines are a separate download, because most API suites never need one:

sdods browsers install chromium

HomebrewCopy Anchor Link

The tap holds the formula only; the software comes from npm. It depends on Homebrew's node rather than vendoring one, so SDODS runs on the same Node as the rest of your toolchain:

brew install yarlisaisolutions/sdods/sdods

Homebrew asks you to trust a tap that is not one of its own the first time you install from it, and prints the brew trust command to run. Reading the formula with brew info needs no trust; installing does.

DockerCopy Anchor Link

The image is the server and the web UI, with the browser engines already inside — this is the one channel that needs nothing installed on the host at all.

The image is published for linux/amd64 and linux/arm64, each built and tested on its own architecture, so it runs natively on Intel, Apple silicon and arm64 servers such as Graviton. No flag is needed:

docker run --rm -p 8080:8080 -v sdods-data:/data ghcr.io/yarlisaisolutions/sdods-server

Tags up to 0.9.0 carry linux/amd64 only. Docker does not fall back to emulation for a missing architecture — it refuses the pull, so on arm64 those tags fail with no matching manifest for linux/arm64/v8. To run one of them there, ask for the platform explicitly:

docker run --rm --platform linux/amd64 -p 8080:8080 -v sdods-data:/data ghcr.io/yarlisaisolutions/sdods-server:0.9.0

Images published before the repository moved to YarlisAISolutions live at ghcr.io/siri1410/sdods-server; pull from the new path.

Check which platforms a tag carries before you pull it:

docker buildx imagetools inspect ghcr.io/yarlisaisolutions/sdods-server

Any CLI command works as the argument, so the same image runs a suite in CI:

docker run --rm ghcr.io/yarlisaisolutions/sdods-server run -p demo-shop -e staging -l api

Windows: winget and ScoopCopy Anchor Link

Both install the desktop app, not the CLI — they are the managers Windows users already have, and a GUI installer is what they are built to place. The CLI on Windows comes from npm or the PowerShell script.

winget install SDODS.SDODS

Scoop needs the bucket added once:

scoop bucket add sdods https://github.com/YarlisAISolutions/scoop-sdods

scoop install sdods

Debian and UbuntuCopy Anchor Link

Install a single .deb when you just want the app and not the update channel. Download it from the download page first — the filename carries the version, so the glob is what keeps this correct across releases:

sudo apt install ./SDODS-*-linux-amd64.deb

Or add the signed repository, which is what makes apt upgrade keep it current. Add the key first — apt reads binary keyrings, so it is dearmoured on the way in:

curl -fsSL https://sdods.com/apt/sdods-archive-keyring.gpg | sudo tee /usr/share/keyrings/sdods-archive-keyring.gpg > /dev/null

echo "deb [signed-by=/usr/share/keyrings/sdods-archive-keyring.gpg] https://sdods.com/apt stable main" | sudo tee /etc/apt/sources.list.d/sdods.list

sudo apt update && sudo apt install sdods

Keeping the desktop app currentCopy Anchor Link

The desktop app checks for a new release once its dashboard is up and every six hours after that. It downloads the update in the background, then asks: SDODS x.y.z is ready — Restart to update. Choose Later and the update waits: nothing installs when you quit, and the app asks again the next time it starts or when you pick SDODS ▸ Check for Updates…. Restarting stops the local server first, so a run in progress ends there; your workspace, database and results are untouched.

Who updates the app depends on how you installed it:

On installs the app does not update, Check for Updates… says which of these applies instead. To stop the background checks, untick SDODS ▸ Check for Updates Automatically; the manual check still works. To switch the updater off entirely, for example on a machine whose software is managed centrally, launch the app with SDODS_DESKTOP_NO_UPDATE=1 set. What each check found is written to desktop.log (SDODS ▸ Open Logs Folder).

See it before you run itCopy Anchor Link

--dry-run prints every step it would take and changes nothing. On a machine you do not own, run this first and read it.

curl -fsSLO https://sdods.com/install.sh
sh install.sh --dry-run --browsers chromium

--version-check answers the other question — which versions and paths it resolved on this machine — and then exits.

sh install.sh --version-check

What it installs, and whereCopy Anchor Link

By default the installer installs the published @sdods/cli package globally with your package manager. There is no SDODS source tree on your machine — the packages ship compiled.

Your shell profile is edited only when you pass --modify-path. The @sdods/* packages are about 9 MB; with their dependencies the global install comes to roughly 400 MB, and each browser adds another 500 MB or so. Nothing is written to ~/.sdods at all on this path.

Your tests live wherever you put them: sdods init ~/my-tests scaffolds a workspace, demo project included, and nothing outside that directory is yours to manage.

Installing from source insteadCopy Anchor Link

--source git clones the repository into ~/.sdods/app and installs every workspace's dependencies there, then writes a shim to ~/.local/bin/sdods (Windows: %LOCALAPPDATA%\SDODS\bin). That is the path for working on SDODS rather than with it, and it needs about 1.5 GB. --install-node additionally puts fnm in ~/.sdods/.fnm.

The default never falls back to a clone on its own: if the registry cannot be reached the installer says so, rather than quietly downloading a source tree you did not ask for.

OptionsCopy Anchor Link

Every flag has an environment-variable equivalent, so the same behaviour works in a Dockerfile or a CI step.

Windows takes the same names as PowerShell parameters: -Version, -Dir, -BinDir, -Pm, -Browsers, -Workspace, -Source, -Mcp, -ModifyPath, -Yes, -Uninstall, -DryRun, -Verbose, -VersionCheck, -Help.

Exit codes and security notes are in Reference → Installer.

First runCopy Anchor Link

Projects are discovered from the current directory, so start in a workspace. The default install is a global package with no source tree, so create one first — unless you passed --workspace, which did it for you:

sdods init ~/my-tests      # skip if you installed with --workspace
cd ~/my-tests
sdods project list

sdods run -p demo-shop -e staging -l api                        # API layer, no browser
sdods run -p demo-shop -e staging -l ui -b chromium -t @smoke   # UI smoke
sdods report --last --open                                      # HTML report and dashboard

Then point SDODS at something of your own:

sdods init ~/my-tests                    # new workspace with the demo project
sdods analyze /path/to/your-app --apply  # detect routes, API endpoints and test ids

Inside a clone, the same commands run through the package manager:

bun run sdods project list
bun run sdods config validate

Advanced installsCopy Anchor Link

The one-liner is the happy path. These are the ones that come up on a work laptop.

export HTTPS_PROXY=http://proxy.corp.example:8080
export NO_PROXY=localhost,127.0.0.1,.corp.example
export NODE_EXTRA_CA_CERTS=/etc/ssl/certs/corp-root-ca.pem
git config --global http.proxy "$HTTPS_PROXY"      # only if the clone still fails
curl -fsSL https://sdods.com/install.sh | sh

# the version the team is standardised on
curl -fsSL https://sdods.com/install.sh | sh -s -- --version v0.2.0

# a second install, in its own home, under its own command name
curl -fsSL https://sdods.com/install.sh | sh -s -- \
  --version main --dir ~/.sdods-main --bin-dir ~/.local/bin/sdods-main

CI=1 SDODS_BROWSERS=none SDODS_MODIFY_PATH=1 \
  sh -c "curl -fsSL https://sdods.com/install.sh | sh"

ENV SDODS_HOME=/opt/sdods SDODS_BIN_DIR=/usr/local/bin SDODS_BROWSERS=chromium SDODS_YES=1
RUN curl -fsSL https://sdods.com/install.sh | sh

docker build -t sdods-server .
docker run --rm sdods-server doctor          # any CLI command works as the argument
docker run --rm -p 8080:8080 -v sdods-data:/data sdods-server   # the server and web UI

curl -fsSL https://sdods.com/install.sh | sh -s -- --mcp all

Check the installCopy Anchor Link

sdods doctor

doctor continues past a failure so you get the whole picture in one pass, and --fix installs missing browser engines. It is also the fastest way to answer “is my environment the problem?” before opening an issue.

Upgrade and uninstallCopy Anchor Link

curl -fsSL https://sdods.com/install.sh | sh                          # upgrade: same command
curl -fsSL https://sdods.com/install.sh | sh -s -- --version v0.2.0   # pin a release
curl -fsSL https://sdods.com/install.sh | sh -s -- --uninstall --yes  # remove

Uninstalling removes ~/.sdods and the command shim. Workspaces you created stay where they are, and the browser engine cache is shared with other tools, so remove that yourself if you want the space back.

To start the web UI over without reinstalling — remove every user, or wipe the platform database — see Reinstall or reset.

TroubleshootingCopy Anchor Link

Next stepsCopy Anchor Link

• The workshop — a real open-source application, onboarded and then exercised feature by feature
• Onboard an existing app
• Your first API test
• Use it from Claude Code or Codex