Runners Scaleway natifs pour Cadence.CI

Cadence.CI suit un modèle « Bring Your Own Infrastructure » : l’orchestration s’exécute sur Cadence.CI, le calcul s’exécute sur une infrastructure que vous contrôlez. Scaleway est désormais l’un des clouds publics sur lesquels il provisionne directement des runners.

Une instance par job

Un run ne réutilise pas un pool de machines préchauffées. Pour chaque job, Cadence.CI :

• crée un groupe de sécurité dédié, ouvert uniquement sur le port dont le run a besoin,
• réserve une IP,
• génère un certificat TLS pour cette IP, pour que la connexion vers Cadence.CI soit chiffrée dès le premier octet,
• démarre une instance Scaleway et redimensionne son volume racine à ce que le job a réellement demandé,
• pousse une charge cloud-init qui démarre le moteur Mélodium avec ce certificat,
• la démarre et attend qu’elle soit opérationnelle.

Quand le job se termine, tout disparaît : l’instance, le groupe de sécurité, l’IP réservée, le volume. Rien ne traîne en attendant le prochain run.

Pourquoi cette forme

C’est ce que signifie « runner éphémère » en pratique : aucune machine inactive n’est jamais facturée, et aucune instance longue durée n’accumule d’accès ou d’état entre les jobs. L’auto-scaling découle du même mécanisme, puisque la demande se résume à « en démarrer une de plus » ou « zéro », plutôt qu’une flotte à dimensionner à l’avance.

Cela signifie aussi que le compte qui exécute le job est le vôtre. Les runners sont provisionnés dans votre propre projet Scaleway, pas dans un pool partagé, donc l’isolation, le placement géographique et le coût restent sous votre contrôle.

Ce que ça débloque

Tout pipeline ou charge de travail distribuée capable de tourner sur Cadence.CI peut désormais cibler Scaleway comme calcul, avec les mêmes garanties de cycle de vie que le reste de la plateforme : provisionné quand nécessaire, observable pendant l’exécution, et disparu une fois terminé. D’autres fournisseurs sont sur la feuille de route .