SFCC Sandbox Switcher

Always know which SFCC sandbox you are uploading to. Switch instances in two clicks.

Salesforce Commerce Cloud developers work against several sandboxes, but dw.json holds exactly one. So everyone improvises the same workaround: a text file of hostnames and passwords, copy-pasted whenever they switch.

The typing is the annoyance. The expense is not knowing which sandbox you are on.

Prophet uploads on save, silently, to whatever dw.json last said. Switch instances on Friday, forget over the weekend, and Monday's work goes quietly onto the wrong box — invisible until someone else notices broken code on a shared sandbox.

This extension puts the active sandbox in your status bar and makes switching a two-click operation. It is a guardrail that happens to also save the typing.

What you get

An indicator that is always right. The status bar shows the instance you are pointed at and its code version. Hand-edit dw.json, run git checkout, let another tool rewrite it — the indicator updates immediately, no reload.

Protected instances look different. Flag your shared integration and QA boxes as protected. They get a warning-coloured status bar and ask for confirmation before you switch to them. An unrecognised hostname is marked too, since that usually means a hand edit nobody remembers making.

Passwords out of plaintext files. Credentials go to your operating system's keychain via VS Code's SecretStorage, keyed per username@hostname. You are asked once per instance.

A sandbox list your team can share. Commit a sandboxes.json next to dw.json and everyone gets the same list. Personal sandboxes live in your home directory and merge on top, so your own instances never need to go in the shared file.

It works alongside Prophet, not instead of it

This extension does not upload cartridges, debug, or tail logs — Prophet Debugger owns those and does them well. It only manages the connection target.

Prophet re-reads dw.json when it changes, so switching takes effect immediately. No restart, no reload, no configuration linking the two.

Your dw.json survives intact

Real connection files carry cartridge, client-id, client-secret, p12, self-signed, and vendor keys like sitecode. A switch changes the connection fields and nothing else — key order, indentation, line endings and the trailing newline are all preserved byte-for-byte.

Designed for a locked-down work laptop

No admin rights. No native modules to compile. No child processes and no network calls at all — nothing for EDR, AppLocker or PowerShell Constrained Language Mode to block. No telemetry, no crash reporting, no update pings.

If your home directory is redirected to a network share, set DW_JSON_MANAGER_HOME to a local directory.

Getting started

1. Open a project containing a dw.json.
2. Click the sandbox indicator in the status bar.
3. Choose Add a sandbox…, or just type a sandbox id like abcd-001 to switch straight away.

The extension ships with an empty list and no bundled hostnames.

Sandbox list format

{
  "sandboxes": [
    {
      "id": "dev",
      "label": "My dev sandbox",
      "hostname": "abcd-001.dx.commercecloud.salesforce.com",
      "codeVersion": "version1",
      "username": "first.last@example.com",
      "protected": false
    }
  ]
}

Project list: sandboxes.json next to dw.json, committed. Personal list: ~/.dw-json-manager/sandboxes.json. Project entries win on id collision.

Commands

One thing to be aware of

dw.json holds your Business Manager password in plaintext. That is the platform's interface and no tool can change it — Prophet and everything else read it from there.

So keep dw.json out of version control. The extension warns you if it sits in a git repository without a .gitignore rule covering it, and offers to add one.

License

MIT