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.
Mises à jour gérées