Kiro IDE et Kiro CLI peuvent chacun être redirigés vers un serveur de mise à jour autohébergé afin que vous contrôliez quelles versions atteignent votre parc. Les deux produits utilisent des mécanismes distincts et indépendants — configurez la ou les surfaces que votre organisation utilise.
Contrôlez quelles versions de Kiro IDE atteignent vos utilisateurs en hébergeant un site de mise à jour autogéré. Définissez la politique gérée UpdateUrl pour diriger Kiro vers votre serveur, servez des manifestes JSON par plateforme et hébergez les binaires d'installation n'importe où accessible via HTTPS.
Définissez la politique UpdateUrl à l'URL de base de votre serveur.
Utilisez les préférences gérées de macOS pour définir la politique :
sudo defaults write dev.kiro.desktop UpdateUrl -string "https://updates.example.com"
Ou déployez via un profil MDM ciblant le domaine dev.kiro.desktop.
| Exigence | Détail |
|---|---|
| Schéma | https:// seulement. Les valeurs non-HTTPS ou mal formées sont journalisées et Kiro revient à la valeur par défaut intégrée. |
| Barre oblique finale | Retirée automatiquement. |
| Moment d'application | Résolu au démarrage — redémarrez Kiro pour que le changement prenne effet. |
| UpdateMode | UpdateMode=none l'emporte toujours et désactive complètement les mises à jour, quelle que soit la valeur de UpdateUrl. |
Kiro demande un manifeste JSON à un chemin propre à chaque plateforme, construit à partir de l'URL de base, du canal, du système d'exploitation et de l'architecture :
| Plateforme | Chemin |
|---|---|
| macOS | {base}/{quality}/metadata-darwin-{arch}-{quality}.json |
| Linux | {base}/{quality}/metadata-linux-{arch}-{quality}.json |
| Windows | {base}/{quality}/metadata-{win-variant}-{quality}.json |
Où :
{quality} est le canal de diffusion — toujours stable pour les serveurs de mise à jour autohébergés{arch} est x64 ou arm64{win-variant} est win32-{arch} plus un suffixe de type d'installation : -system (par défaut), -user, ou -archive (portable)Exemples :
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 ajoute ?bg=true lors des vérifications automatiques en arrière-plan. Votre serveur peut ignorer ce paramètre sans problème.
Kiro lit la première entrée de releases. Voici un exemple de manifeste :
{ "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" } } ] }
| Champ | Description |
|---|---|
currentRelease | Chaîne de la dernière version |
releases[0].version | Comparée à la version installée — une mise à jour n'est proposée que si cette version est supérieure |
releases[0].updateTo.url | URL de téléchargement du binaire signé. Doit être en HTTPS. N'a pas besoin de partager l'hôte du manifeste. |
updateTo.pub_date | Date de publication au format AAAA-MM-JJ |
updateTo.name / notes | Métadonnées affichées à l'utilisateur dans l'invite de mise à jour |
| Plateforme | Type de binaire |
|---|---|
| macOS | .zip signé — téléchargé, installé et relancé automatiquement |
| Windows | Installateur .exe — Kiro le télécharge et le lance directement |
| Linux | URL d'archive — Kiro l'ouvre dans le navigateur par défaut pour une installation manuelle |
Diffusez d'abord à un groupe pilote, puis déployez à l'échelle de l'organisation après une période de validation.
Étape 1 : Miroiter la version
Lorsqu'une nouvelle version de Kiro est publiée, téléchargez les binaires d'installation depuis prod.download.desktop.kiro.dev et créez des manifestes pointant vers vos copies hébergées.
Étape 2 : Groupe pilote
Configurez les machines de votre groupe pilote avec UpdateUrl pointant vers un manifeste qui annonce la nouvelle 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" } } ] }
Étape 3 : Valider
Surveillez le groupe pilote pour détecter des problèmes pendant votre période de validation (habituellement 3 à 7 jours).
Étape 4 : Déploiement à grande échelle
Mettez à jour les manifestes sur votre point de terminaison de production pour annoncer la nouvelle version. Tous les utilisateurs restants reçoivent la mise à jour lors de leur prochaine vérification.
Pour maintenir votre parc sur une version spécifique, définissez releases[0].version à la version que votre parc exécute actuellement. Kiro n'offre une mise à jour que lorsque la version du manifeste est supérieure à la version installée, donc annoncer la même version l'épingle efficacement.
Cela contrôle uniquement la vérification de mise à jour automatique — cela n'empêche pas un utilisateur d'installer manuellement une version différente. Pour verrouiller complètement les versions, combinez l'épinglage avec des contrôles réseau qui bloquent l'accès au serveur de téléchargement officiel.
Définissez UpdateMode=none via une politique gérée (le même mécanisme de diffusion que UpdateUrl). Lorsque UpdateMode est none, Kiro ignore toutes les vérifications de mise à jour, quelle que soit la valeur de UpdateUrl.
Vous pouvez combiner la politique UpdateUrl avec des règles de pare-feu pour vous assurer que Kiro ne peut atteindre que votre serveur de mise à jour interne. Bloquez l'accès sortant vers prod.download.desktop.kiro.dev et autorisez uniquement votre point de terminaison personnalisé. Cela garantit qu'aucun utilisateur ne contourne votre gouvernance de version.
Redirigez les mises à jour de Kiro CLI vers votre propre serveur en définissant une valeur de politique gérée update.baseUrl. Sur une machine gérée, une politique imposée l'emporte sur les autres configurations d'URL de publication.
Définissez la politique update.baseUrl à la racine de votre serveur de publication.
Déployez update.baseUrl comme valeur forcée dans le domaine de préférences gérées dev.kiro.cli au moyen d'un profil de configuration MDM.
Les valeurs non forcées (au niveau utilisateur) dans ce domaine sont ignorées ; un defaults write local n'a donc aucun effet sur une machine gérée.
Une URL de base peut inclure un préfixe de chemin (par exemple, https://artifacts.example.com/mirrors/kiro-cli). Les barres obliques finales sont normalisées. Les valeurs qui échouent à la validation d'URL sont ignorées au profit du serveur de publication par défaut.
Une politique update.baseUrl imposée l'emporte sur les autres configurations d'URL de publication.
Kiro CLI récupère les métadonnées de publication depuis votre serveur pour décider s'il doit se mettre à jour. Le fichier qu'il demande et le schéma qu'il attend diffèrent selon la plateforme ; un miroir doit donc servir le bon fichier pour chaque plateforme que vous prenez en charge. Chaque packages[].download est un chemin résolu par rapport à votre URL de base.
macOS demande un registre de versions cumulatif à <base>/index.json :
{ "supported": [ { "architecture": "universal", "targetTriple": "universal-apple-darwin", "variant": "full", "fileType": "dmg" } ], "versions": [ { "version": "2.13.0", "packages": [ { "kind": "dmg", "os": "macos", "architecture": "universal", "targetTriple": "universal-apple-darwin", "variant": "full", "fileType": "dmg", "download": "2.13.0/KiroCLI.dmg", "sha256": "0000000000000000000000000000000000000000000000000000000000000000", "size": 52428800, "channel": "stable" } ], "rollout": { "start": 1731000000, "end": 1731600000 }, "updateConditions": [{ "allowedAutoUpdateProductNames": ["Kiro CLI"] }] } ] }
Le registre est cumulatif — il liste chaque version publiée sur le canal et exige un tableau supported de premier niveau décrivant les cibles de compilation que vous publiez. Chaque élément de supported exige architecture et variant (targetTriple, os et fileType sont des champs de sélection facultatifs). macOS distribue un DMG. rollout est une fenêtre { start, end } en secondes epoch, et updateConditions encadrent les mises à jour automatiques — la valeur de produit Kiro CLI est la valeur exacte utilisée (sensible à la casse). Remplacez sha256 et size par l'empreinte et la taille en octets de votre artefact.
Un miroir doit servir le fichier de métadonnées de chaque plateforme ainsi que les fichiers d'artefacts que déclarent ses chemins packages[].download :
<base>/index.json # cumulative version registry <base>/<version>/<artifact> # artifact files at the paths packages[].download declare
Les chemins download sont résolus par rapport à <base>, de sorte qu'un miroir contrôle sa propre disposition d'artefacts en écrivant des chemins correspondants dans les métadonnées qu'il héberge.
Par défaut, Kiro CLI ne se met à jour que vers une version plus récente que celle installée. Vous régissez donc le déploiement par les métadonnées que votre miroir sert (sous Windows, --force peut passer outre) :
Avant rollout.start, Kiro CLI ne sélectionne pas la version. À partir du début, un simple kiro-cli update contourne la sélection par pourcentage échelonné, tandis que kiro-cli update --rollout la respecte. Les deux formes manuelles ignorent updateConditions. Les mises à jour automatiques respectent la planification du déploiement et appliquent updateConditions. Pour épingler, ne publiez pas d'entrée versions[] supérieure à la version que votre parc exécute.
Définissez app.disableAutoupdates pour désactiver les mises à jour automatiques :
kiro-cli settings app.disableAutoupdates true
Sous Windows, définir la variable d'environnement KIRO_NO_AUTO_UPDATE avec n'importe quelle valeur désactive aussi les mises à jour en arrière-plan.
Les options de kiro-cli update diffèrent selon la plateforme :
Prend en charge --non-interactive, --relaunch-dashboard et --rollout. N'accepte pas --check ni --force.
Associez la politique update.baseUrl à des règles de pare-feu afin que Kiro CLI ne puisse atteindre que votre miroir. Bloquez l'accès sortant vers les points de terminaison de téléchargement de la CLI par défaut et autorisez plutôt l'hôte de votre miroir :
prod.download.cli.kiro.dev — téléchargements et mises à jour de la CLIdesktop-release.q.us-east-1.amazonaws.com — téléchargements de l'installateur de la CLIBloquer les points de terminaison de téléchargement par défaut empêche l'outil de mise à jour et l'installateur intégrés de Kiro CLI de s'y rabattre. Utilisez des contrôles de distribution logicielle supplémentaires si votre organisation doit empêcher les utilisateurs d'installer des versions par d'autres sources.
Mises à jour gérées