Configuration

Engines

Pulse reads your engines as profiles in .pulse-cli.json, the project file of the Pulse CLI, so the extension and the CLI see the same engines:

{
  "profiles": {
    "dev": {
      "url": "https://dev.example.com/engine-rest",
      "flavor": "operaton",
      "auth": { "type": "basic" },
      "cockpitUrl": "https://dev.example.com/operaton/app/cockpit/default/"
    }
  }
}

Pulse reads url, flavor (camunda7, cibseven or operaton; camunda7 when absent), auth.type (none, basic), cockpitUrl and readOnly (no writes from Pulse either). A profile it cannot serve yet shows up as a problem in the Engines view.

Set credentials with Pulse: Set Credentials…. They live in VS Code's secret storage.

Settings

Setting	Values	Default
pulse.environments	per profile: local, test, production	loopback hosts are local
pulse.writes	localOnly, enabled, disabled	localOnly
pulse.liveUpdates	per environment (local, test, production, unclassified): on, off	local and test on

Production engines show in red, and only by configuration: "pulse.environments": { "prod-eu": "production" }. pulse.writes and pulse.liveUpdates count only in your user settings: a workspace or a dev container cannot turn them on. With enabled, production and unclassified engines ask you to type their host before a write.

Open views read the engine again while they are visible and VS Code has focus: local engines every 5–30 s, test engines every 15–60 s, production and unclassified every 30–120 s once you turn them on. They pause after 15 minutes without activity.

Open in Cockpit

With cockpitUrl, the definition and instance panels get an Open in Cockpit button. Pulse never guesses this URL. It must be an http or https URL without credentials:

Engine	cockpitUrl
Camunda 7, Operaton, CIB seven (Cockpit)	ends in /app/cockpit/<engine name>/
CIB seven webclient	ends in /webapp/