Control which Kiro IDE versions reach your users by hosting a self-managed update site. Set the UpdateUrl managed policy to point Kiro at your server, serve per-platform JSON manifests, and host the installer binaries anywhere reachable over HTTPS.
Set the UpdateUrl policy to your server's base URL.
Use macOS managed preferences to set the policy:
sudo defaults write dev.kiro.desktop UpdateUrl -string "https://updates.example.com"
Or deploy via an MDM profile targeting the dev.kiro.desktop domain.
| Requirement | Detail |
|---|---|
| Scheme | https:// only. Non-HTTPS or malformed values are logged and Kiro falls back to the built-in default. |
| Trailing slash | Stripped automatically. |
| When it applies | Resolved at startup — restart Kiro for the change to take effect. |
| UpdateMode | UpdateMode=none always wins and disables updates entirely, regardless of UpdateUrl. |
Kiro requests a JSON manifest at a per-platform path built from the base URL, channel, OS, and architecture:
| Platform | Path |
|---|---|
| macOS | {base}/{quality}/metadata-darwin-{arch}-{quality}.json |
| Linux | {base}/{quality}/metadata-linux-{arch}-{quality}.json |
| Windows | {base}/{quality}/metadata-{win-variant}-{quality}.json |
Where:
{quality} is the release channel — always stable for self-hosted update servers{arch} is x64 or arm64{win-variant} is win32-{arch} plus an install-type suffix: -system (default), -user, or -archive (portable)Examples:
https://updates.example.com/stable/metadata-darwin-arm64-stable.jsonhttps://updates.example.com/stable/metadata-win32-x64-user-stable.jsonhttps://updates.example.com/stable/metadata-linux-x64-stable.jsonKiro appends ?bg=true on automatic background checks. Your server can safely ignore this parameter.
Kiro reads the first entry in releases. Here is an example manifest:
{ "currentRelease": "1.2.0", "releases": [ { "version": "1.2.0", "updateTo": { "version": "1.2.0", "pub_date": "2026-07-10", "notes": "Kiro-darwin-arm64-1.2.0", "name": "Kiro-darwin-arm64-1.2.0", "url": "https://updates.example.com/releases/stable/darwin-arm64/signed/1.2.0/kiro-ide-1.2.0-stable-darwin-arm64.zip" } } ] }
| Field | Description |
|---|---|
currentRelease | Latest release version string |
releases[0].version | Compared against the installed version — an update is offered only if this is greater |
releases[0].updateTo.url | Download URL for the signed binary. Must be HTTPS. Does not need to share the manifest's host. |
updateTo.pub_date | Publish date in YYYY-MM-DD format |
updateTo.name / notes | Metadata shown to the user in the update prompt |
| Platform | Binary type |
|---|---|
| macOS | Signed .zip — downloaded, installed, and relaunched automatically |
| Windows | .exe installer — Kiro downloads and launches it directly |
| Linux | Archive URL — Kiro opens it in the default browser for manual install |
Release to a pilot group first, then roll out organization-wide after a validation period.
Step 1: Mirror the release
When a new Kiro version is published, download the installer binaries from prod.download.desktop.kiro.dev and create manifests pointing to your hosted copies.
Step 2: Pilot group
Configure your pilot group's machines with UpdateUrl pointing to a manifest that advertises the new version:
{ "currentRelease": "1.3.0", "releases": [ { "version": "1.3.0", "updateTo": { "version": "1.3.0", "pub_date": "2026-07-15", "notes": "Kiro-darwin-arm64-1.3.0", "name": "Kiro-darwin-arm64-1.3.0", "url": "https://updates.example.com/releases/stable/darwin-arm64/signed/1.3.0/kiro-ide-1.3.0-stable-darwin-arm64.zip" } } ] }
Step 3: Validate
Monitor the pilot group for issues over your validation period (commonly 3–7 days).
Step 4: Broad rollout
Update the manifests on your production endpoint to advertise the new version. All remaining users receive the update on their next check.
To hold your fleet on a specific version, set releases[0].version to the version your fleet currently runs. Kiro only offers an update when the manifest version is greater than the installed version, so advertising the same version effectively pins it.
This controls the auto-update check only — it does not prevent a user from manually installing a different version. To fully lock versions, combine pinning with network controls that block access to the official download server.
Set UpdateMode=none via managed policy (same delivery mechanism as UpdateUrl). When UpdateMode is none, Kiro skips all update checks regardless of the UpdateUrl value.
You can combine the UpdateUrl policy with firewall rules to ensure Kiro can only reach your internal update server. Block outbound access to prod.download.desktop.kiro.dev and allow your custom endpoint only. This guarantees that no user bypasses your version governance.
Managed updates