Deployment guide

Where everything lives#

Every Purple+ desktop release is published to the locations below: the download page for people, and the release feed plus installer files for tooling.

Choose a deployment model#

Every release ships the same signed client in two packages, built for two management styles.

Default to the per-user installer: machines stay current with zero effort from IT. Choose the MSI when updates must go through your own change control, or when several people share one machine.

Per-user installer (.exe)#

The default installer: PurplePlus-<version>-x64-Setup.exe. It installs into the signed-in user's profile with no admin rights and keeps itself up to date from the release feed.

Manual install#

Send people to download.letsgopurple.plus: the page detects the latest version, starts the download of the signed installer, and shows the version, release date, and file size with a manual download button in case the browser blocks the automatic one. There is nothing to configure.

Silent install and uninstall#

For scripted and unattended provisioning, the installer takes /S:

PurplePlus-<version>-x64-Setup.exe /S

The uninstaller sits in the install folder and takes the same flag:

"%LOCALAPPDATA%\Programs\PurplePlus\Uninstall Purple+.exe" /S

Scripted provisioning#

Poll the feed for the newest released build and download it when it is newer than what you last provisioned, then run the silent install above. Both scripts do the same thing; pick your shell. The manifest they read is documented in The release feed.

$feed = "https://purpleplusinstaller.blob.core.windows.net/releases"
# The blob is served as application/octet-stream, so Invoke-WebRequest would
# return raw bytes; DownloadString gives a string the regex can read.
$yaml = (New-Object System.Net.WebClient).DownloadString("$feed/latest.yml")

# latest.yml is tiny and predictable, so a simple regex is enough.
$version  = ([regex]'(?m)^version:\s*(\S+)').Match($yaml).Groups[1].Value
$filename = ([regex]'(?m)^path:\s*(\S+)').Match($yaml).Groups[1].Value
$fileUrl  = "$feed/$filename"

# A stagingPercentage below 100 marks a pre-release. When that happens, fall back
# to the last released build: the newest history.json entry whose version
# differs from the pre-release.
$staging = ([regex]'(?m)^stagingPercentage:\s*(\d+)').Match($yaml)
if ($staging.Success -and [int]$staging.Groups[1].Value -lt 100) {
    $history  = Invoke-RestMethod "$feed/history.json"
    $previous = $history | Where-Object { $_.version -ne $version } | Select-Object -First 1
    $version  = $previous.version
    $filename = $previous.filename
    $fileUrl  = $previous.url
}

# Compare against whatever version you last provisioned, then download if newer.
$current = "3.42.0"
if ([version]$version -gt [version]$current) {
    $out = Join-Path $env:TEMP $filename
    Invoke-WebRequest -Uri $fileUrl -OutFile $out
    Write-Host "Downloaded Purple+ $version to $out"
    # Provision $out into your workspace here.
}

FEED="https://purpleplusinstaller.blob.core.windows.net/releases"

# Pull the version, filename, and release state from the canonical manifest.
YAML=$(curl -fsSL "$FEED/latest.yml")
VERSION=$(echo "$YAML" | grep -E '^version:' | awk '{print $2}')
FILE=$(echo "$YAML" | grep -E '^path:' | awk '{print $2}')
URL="$FEED/$FILE"
STAGING=$(echo "$YAML" | grep -E '^stagingPercentage:' | awk '{print $2}')

# A stagingPercentage below 100 marks a pre-release. Fall back to the last
# released build: the newest history.json entry whose version differs from the
# pre-release. (history.json is real JSON, so this step uses jq.)
if [ -n "$STAGING" ] && [ "$STAGING" -lt 100 ]; then
    PREV=$(curl -fsSL "$FEED/history.json" | jq -c --arg v "$VERSION" 'map(select(.version != $v)) | .[0]')
    VERSION=$(echo "$PREV" | jq -r '.version')
    FILE=$(echo "$PREV" | jq -r '.filename')
    URL=$(echo "$PREV" | jq -r '.url')
fi

echo "Provisioning Purple+ $VERSION"
curl -fSL -o "$FILE" "$URL"

Provisioning context and detection#

Detecting whether it is installed. A per-user install lands at %LOCALAPPDATA%\Programs\PurplePlus with Purple+.exe inside. If your tool needs a detection rule, check that this path is present rather than matching an exact version: Purple+ keeps itself up to date, so a version-pinned rule goes stale after the app self-updates and can trigger a needless reinstall. Confirm the exact names against a reference install.

Machine-wide MSI#

For SCCM, Intune, or Ivanti deployments we publish a machine-wide MSI next to the .exe: the same signed Purple+ client, installed once for every account on the machine into C:\Program Files\<product name>. Unlike the per-user installer, run this one with administrative rights, typically as SYSTEM from your deployment tool. The filename swaps -Setup.exe for -Setup.msi, in the same releases folder.

Install and upgrade#

msiexec /i PurplePlus-<version>-x64-Setup.msi /qn

Add /l*v install.log to capture a verbose log. Only a per-machine install is supported: do not pass ALLUSERS or MSIINSTALLPERUSER overrides.

Upgrading is the same command with the newer MSI: it replaces the old version in place, and reinstalling the same version is safe too. Uninstall goes by product code, the way any MSI is removed:

msiexec /x {ProductCode} /qn

{ProductCode} changes with every release. Your deployment tool typically reads it straight from the MSI when you package the install; if you need it for a script, the registry DisplayVersion value under that product code's uninstall key also confirms which version is installed.

Scripted download#

Resolve the newest released build from the feed and download its MSI. The script is self-contained; the manifest it reads is documented in The release feed.

$feed = "https://purpleplusinstaller.blob.core.windows.net/releases"
$yaml = (New-Object System.Net.WebClient).DownloadString("$feed/latest.yml")

# Resolve the newest released build; fall back past a pre-release
# (stagingPercentage below 100) to the last released history.json entry.
$version  = ([regex]'(?m)^version:\s*(\S+)').Match($yaml).Groups[1].Value
$filename = ([regex]'(?m)^path:\s*(\S+)').Match($yaml).Groups[1].Value
$staging  = ([regex]'(?m)^stagingPercentage:\s*(\d+)').Match($yaml)
if ($staging.Success -and [int]$staging.Groups[1].Value -lt 100) {
    $previous = (Invoke-RestMethod "$feed/history.json") | Where-Object { $_.version -ne $version } | Select-Object -First 1
    $version  = $previous.version
    $filename = $previous.filename
}

# The MSI ships next to the exe under the same name: swap the extension.
$msiName = $filename -replace '\.exe$', '.msi'
$out = Join-Path $env:TEMP $msiName
Invoke-WebRequest -Uri "$feed/$msiName" -OutFile $out
Write-Host "Downloaded Purple+ $version MSI to $out"

# Import $out into SCCM, Intune, or Ivanti, or install directly:
msiexec /i "$out" /qn /l*v install.log

Updates are yours to deploy#

A machine-wide install never updates itself. Every Purple+ copy on that machine, including any per-user install already there, switches to a notify-only banner that asks people to contact their IT administrator. From that point on, deploying each new release is your job.

Because an upgrade replaces files in place, it closes any running Purple+ session, ending active calls, so schedule it in a maintenance window, particularly on machines shared across shifts or sign-ins.

Detection#

Two ways to confirm the MSI is installed, in the order most deployment tools reach for them:

Per-user leftover cleanup#

If a per-user install already exists on the machine, the machine-wide app removes it automatically the first time that Windows account launches Purple+ after the MSI is deployed (until then, that copy keeps working, just also frozen into the same notify-only mode). For an account that never opens the app again, clean up its leftover copy directly, run as that user:

"%LOCALAPPDATA%\Programs\PurplePlus\Uninstall Purple+.exe" /S

The release feed#

The reference for the scripts above. latest.yml is the canonical "what is the newest build" manifest: small, stable, always present, and the same file the Purple+ app uses to update itself, so per-user installs stay current on their own. You only need the feed to provision new installs, not to push updates.

latest.yml The newest-build manifest#

version: 6.0.0
files:
  - url: PurplePlus-6.0.0-x64-Setup.exe
    sha512: <base64 sha512>
    size: 96118784
path: PurplePlus-6.0.0-x64-Setup.exe
sha512: <base64 sha512>
releaseDate: '2026-06-09T10:00:00.000Z'
stagingPercentage: 100 # 0 while the build is a pre-release; absent also means released

Read version to compare against what you have provisioned, then download the installer from the same releases folder using the path filename. The sha512 values let you verify the download if you want. Each release publishes the MSI alongside the exe under the same name, so swapping -Setup.exe for -Setup.msi on that filename gives the MSI URL.

history.json Previous releases, newest first#

Sits in the same folder, each entry with an absolute url. Read it only for the pre-release case above, to grab the last released build.

[
  {
    "version": "6.0.0",
    "filename": "PurplePlus-6.0.0-x64-Setup.exe",
    "url": "https://purpleplusinstaller.blob.core.windows.net/releases/PurplePlus-6.0.0-x64-Setup.exe",
    "date": "2026-06-09T10:00:00.000Z",
    "size": 96118784
  },
  { /* the previous release, and so on (newest first) */ }
]

Frequently asked#