Updates & Uninstall

Upgrade Levee, update the container runtime image and AI tools, and remove Levee completely

Nothing in Levee changes under a user without someone deciding it. IT installs new Levee versions, new container images arrive only with a Levee release, and each user chooses when a project moves to a newer AI tool. Uninstalling removes the programs but keeps the audit log and users' files.

Levee has three parts that update independently:

Levee has no self-updater. It never downloads a new version of itself.

How do I upgrade Levee?

Install the newer MSI over the existing one. Running projects stop during the upgrade, and configuration and data are kept.

Interactively, or silently:

msiexec /i .\VediramLeveeSetup-<version>-x64.msi /qn /norestart /l*v "$env:SystemRoot\Temp\levee-upgrade.log"

Or use the wrapper script Levee installed, which keeps a bounded archive of install logs:

& "$env:ProgramFiles\Vediram\Levee\setup\install-levee.ps1" -MsiPath .\VediramLeveeSetup-<version>-x64.msi

What an upgrade does:

• It replaces the service, container engine, app, CLI, and policy channels in one transaction. If it fails, the previous version stays in place.
• It stops and restarts both Levee services. Running projects stop, and users see the Levee app reconnect. Schedule upgrades outside working hours, or ask users to stop their projects first.
• It keeps your configuration and data: policy.json, tenant-config.json, config.json (your logging changes are never overwritten), the audit log, projects, published tools, and the loaded runtime image.
• It checks the prerequisites again (edition, build, ASP.NET Core 8 runtime) before it changes anything.
• It updates LeveeFS when the new version includes a newer driver. A driver update needs a restart: the MSI then returns 3010, and shared files are available again after the restart.
• Upgrading from a version earlier than 0.59.0 moves the programs from %ProgramData%\Vediram\Levee\ to %ProgramFiles%\Vediram\Levee\ and removes the old program files from ProgramData. Data stays in ProgramData.

Downgrades are blocked. Installing an older MSI fails with A newer version of Levee is already installed. To go back to an older version, uninstall first, then install the older MSI. Configuration and data survive the uninstall (see below).

Keep the app and service on the same version. They are installed together by the same MSI. If the app finds a different service version, for example after a partial or failed upgrade, it shows "App and service versions don't match". Reinstall the current MSI to fix it.

With Intune or Configuration Manager, deploy the new version as a new application that supersedes the old one, without uninstalling the previous version first. See Enterprise deployment.

How does the container runtime image update?

The image a machine runs is set by the Levee version installed on it. A newer image arrives when you install a Levee release that requires it.

When Vediram publishes a newer runtime image, the Levee app shows a "Container image update available" banner and levee doctor reports it. Levee does not download or switch to the new image because of that notice, so a working fleet never changes silently.

The release notes for each Levee version say whether it moves to a new image and what to do. When it does, the service provisions the new image the same way as on first install. See Container runtime for mirrors and pre-staged images on offline machines.

How do AI tools update?

The administrator publishes a new version next to the old one, and each user upgrades the projects that use it. Publishing a new version never changes what running projects use.

AI tools are versioned packages that administrators publish on each machine. See AI tools for the folder layout.

1. The administrator publishes the new version next to the old one. Keep the old version in place until users have upgraded.
2. In each project that uses the tool, the user sees an Upgrade button in the project's Settings > Tools list.
3. If the new version needs network destinations the old one didn't, the user approves them as part of the upgrade, and your policy can still block them.

A project keeps the tool version it enabled until the user upgrades.

How do I uninstall Levee?

Ask users to stop their projects, then uninstall the MSI. The audit log, policy, and users' project folders stay on the machine unless you remove them yourself.

Uninstall from Settings > Apps > Installed apps > Vediram Levee, or silently:

msiexec /x .\VediramLeveeSetup-<version>-x64.msi /qn /norestart /l*v "$env:SystemRoot\Temp\levee-uninstall.log"

If you don't have the original MSI, uninstall by product name:

$levee = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*' |
    Where-Object DisplayName -eq 'Vediram Levee'
if ($levee) { msiexec /x $levee.PSChildName /qn /norestart }

The uninstall stops and removes the Levee services (LeveeService, LeveeContainerEngine and LeveeFSHost), the LeveeFS driver (LeveeFs), the program files under %ProgramFiles%\Vediram\Levee\, the app, the CLI, and the Start menu shortcut. It does not touch Docker Desktop or any other container engine on the machine.

What stays on the machine

Uninstalling keeps data, so that reinstalling or upgrading after an uninstall doesn't lose anything, and so that audit records are never destroyed by removing the software:

Remove everything

To remove Levee completely, for example when decommissioning a machine, archive what you need to keep first.

1. Export the audit log if your retention rules require it:

   $dest = "\\fileserver\levee-audit\$env:COMPUTERNAME"
   New-Item -ItemType Directory -Force -Path $dest | Out-Null
   Copy-Item "$env:ProgramData\Vediram\Levee\levee-audit.*" $dest
   

2. Uninstall the MSI as shown above, then restart the machine so no container or engine file stays locked.

3. From an elevated PowerShell, remove the machine-wide data:

   Remove-Item "$env:ProgramData\Vediram\Levee" -Recurse -Force
   

   If a few files under engine\data can't be deleted, restart once more and run the command again. Don't reset permissions recursively on that folder: container layers contain links that a recursive permission change would follow outside the folder.

4. For each user, remove the app data, and the projects if they are no longer needed:

   Remove-Item "$env:LOCALAPPDATA\Vediram\Levee" -Recurse -Force
   # Only if the files are no longer needed:
   # Remove-Item "$env:USERPROFILE\LeveeProjects" -Recurse -Force
   

5. Optionally, turn off the Windows Containers feature if nothing else uses it, and restart:

   Disable-WindowsOptionalFeature -Online -FeatureName Containers -NoRestart
   

6. If the device was connected to Vediram Cloud, you can revoke its provisioning key in the Portal once no other machine uses it. See Connecting to Vediram Cloud.