# Overview > UiPath Platform Installer governance: how IT and CoE administrators control update channels, version rollout, and network handling for UiPath desktop clients. This guide is for IT and CoE administrators who manage how UiPath desktop clients are installed and kept up to date across an organization. It describes the governance model behind UiPath Platform Installer — how updates are delivered, who controls them, and how they adapt to enterprise network and compliance requirements. For a general overview of the product and how updates work, see the [UiPath Platform Installer introduction](../user-guide/introduction.md) in the user guide. ## Responsibility model UiPath Platform Installer separates rollout control from version visibility: - **IT owns rollout and governance** — which machines update, to which version, and when. - **The CoE retains visibility** into installed versions through Orchestrator, as today, but does not change versions from there. - **End users take no action** — eligible updates download and apply in the background. ## Update channels Channels control how updates are delivered. The **Community** channel serves community users. The **Enterprise** edition offers two channels — **Short-Term Support (STS)** for the latest features and **Long-Term Support (LTS)** for a stable, patch-only line (identified by a version line such as 25.10 or 26.10). STS and LTS are Enterprise-only. A dedicated installer is provided for each channel (`UiPathPlatformCommunity`, `UiPathPlatformSTS`, `UiPathPlatformLTS-25.10`, `UiPathPlatformLTS-26.10`) purely as a convenience to set the channel up front — the channel can be changed after installation, and the installer updates itself as the desktop clients are updated. This documentation currently covers the STS channel. ## Governance controls For enterprise adoption, particularly long-term support, UiPath Platform Installer is designed to be governed centrally. All governance controls are applied through Group Policy Objects (GPO) or direct registry writes under: ``` HKEY_LOCAL_MACHINE\SOFTWARE\Policies\UiPath\Connected ``` The control areas and their corresponding registry values are: - **Channel selection** (`Channel`, REG_SZ) — assign machines to a Community, Enterprise STS, or Enterprise LTS channel. - **Version pinning** (`MaxAllowedVersion`, REG_SZ) — cap the maximum version a machine may update to within a channel. Updates are filtered to versions at or below this value; if the cap excludes all available versions, no update is offered. - **Artifact mirroring** (`DownloadRootLocation`, REG_SZ) — serve update binaries from an internal URL or UNC path for restricted-bandwidth or air-gapped networks, while update metadata remains cloud-hosted. - **Update deferral** (`MaxPostponeDays`, REG_DWORD) — set the maximum number of days end users may postpone an update. Set to `0` to disable postponement entirely. If the policy is absent, the default is one day. - **Auto-update** (`AutoUpdateDisabled`, REG_DWORD) — set to `1` to disable automatic updates entirely. If the policy is absent or unreadable, automatic updates remain enabled. ### Precedence over command-line parameters GPO policy values take precedence over command-line parameters. When `Channel` is set through Group Policy, the locally configured channel is overridden and attempts to change it via the command line return an error. When `DownloadRootLocation` is set through Group Policy, it overrides the download root provided by the channel definition. `MaxAllowedVersion`, `MaxPostponeDays`, and `AutoUpdateDisabled` have no command-line equivalents and are exclusively controlled through Group Policy. ## Restricted-bandwidth and air-gapped environments For networks with limited outbound access, an organization can host update binaries on an internal HTTPS mirror. Compatibility metadata and channel definitions remain cloud-hosted, so the platform can still determine valid versions and upgrade paths while large binary payloads are served locally. ## Staged rollout Rollout uses existing directory and group-policy infrastructure to target updates to groups of machines — for example, a pilot ring before a production ring — so organizations can validate a version on a subset of machines before wider deployment.