Orchestration et Native Runner
Apportez votre CI. Ou exécutez tout ici.
Cycloid n’est pas un second outil de CI/CD. Chaque Action s’exécute sur le Native Runner intégré ou dans la CI que vous opérez déjà, et Cycloid suit l’ensemble dans une seule vue de statut.
Une seule vue d’état pour tous les pipelines
La taxe de la seconde CI
Votre CI fonctionne. N’en ajoutez pas une autre.
La plupart des équipes ont déjà choisi leur CI et se sont organisées autour. Une plateforme qui impose son propre runner et ses propres pipelines ajoute des coûts à trois endroits à la fois.
Personne ne veut d’une seconde CI
Vos équipes se sont standardisées sur GitHub Actions ou GitLab CI. Adopter et sécuriser un runner de plus est une taxe, pas une capacité.
Pipelines d’infra et d’application séparés
L’application tourne dans votre CI, l’infrastructure ailleurs, et c’est précisément dans l’écart entre les deux qu’un changement passe entre les mailles du filet.
Une exécution, cinq écrans de statut
Le travail se répartit entre exécution native, un pipeline externe et un ou deux webhooks. Le statut aussi.
Cycloid pour votre équipe
Ce que le Native Runner change pour votre équipe
Orchestrer sans exploiter une seconde CI
Le problème
Un pipeline par service, des runners à faire monter en charge et à sécuriser : tout cela reposait sur vous.
Avec Cycloid
Les Actions s’exécutent sur le Native Runner ou passent la main à la CI que vous opérez déjà. Une seule couche de coordination, pas une flotte de pipelines à surveiller.
Le résultat
Vous orchestrez l’infrastructure sans monter une seconde CI.
Lancer l’infrastructure et la suivre au même endroit
Le problème
L’infra tourne dans un outil, votre pipeline applicatif dans un autre, et le statut n’est jamais au même endroit.
Avec Cycloid
Déclenchez l’infrastructure depuis la même plateforme et suivez-la à côté de tout le reste, exécution native ou pipeline externe.
Le résultat
Un seul endroit pour lancer et suivre, pas un onglet par outil.
Gardez la CI que vous avez choisie
Le problème
Un second système de CI/CD, c’est plus de coûts, plus de surface à sécuriser et plus de choses à maintenir.
Avec Cycloid
Gardez GitHub Actions ou GitLab CI, et atteignez n’importe quelle autre CI via un appel HTTP. Cycloid les coordonne, sans leur faire concurrence.
Le résultat
Pas de table rase, et aucune nouvelle plateforme à justifier auprès de la finance.
Comment ça fonctionne
Comment une Action choisit où elle s’exécute
01 · Une Action déclare son backend
Chaque Action de Blueprint indique où elle s’exécute : en natif, dans un pipeline externe ou via un appel HTTP.
02 · En natif, votre CI ou un appel HTTP
Le Native Runner exécute Terraform et OpenTofu, Ansible, Helm, des scripts et Docker. Sinon, l’Action déclenche GitHub Actions ou GitLab CI, ou n’importe quelle CI ou API via un appel HTTP.
03 · Les identifiants arrivent à l’exécution
Les identifiants d’accès sont résolus à la soumission et injectés au lancement de l’étape, jamais figés dans un pipeline.
04 · Cycloid coordonne
Quel que soit le backend, la plateforme suit l’état, gère les nouvelles tentatives et les points d’approbation, et diffuse les logs en continu.
05 · Une seule vue de statut
Le Workflow Status Sync Engine rassemble progression, logs et statut dans une seule vue. Une exécution Terraform et un pipeline GitLab se lisent de la même façon.
Gardez GitHub Actions ou GitLab CI pour ce qu’ils font bien. Cycloid fait le pont entre vos pipelines sans les remplacer, et comble l’écart entre votre pipeline applicatif et votre infrastructure sans vous demander de renoncer à l’un ou à l’autre. C’est la séparation entre l’ordonnanceur et des workers sans état qui permet au Native Runner de monter en charge sur ses propres workers. Les pipelines Concourse continuent de tourner pendant que vous passez au Native Runner.
Comment une Action choisit où elle s’exécute
En bref
Tous les pipelines, une seule vue
8
types d’étapes intégrés, de Terraform aux points d’approbation
5–10
déploiements par jour chez Hotel Spider, autrefois manuels
1
vue de statut, quel que soit l’exécutant
0
identifiant figé dans un pipeline
Pourquoi le déploiement staging d’hier soir a-t-il échoué ?
Il a tourné sur votre workflow GitHub Actions et a remonté son statut ici.
Exécution 4821 · deploy · staging
Échec
Backend
GitHub Actions
Étape en échec
terraform-apply
Erreur : quota dépassé pour le type de ressource
instance dans la région fr-par-2 (6 demandées, limite 4)
Travailler avec votre assistant
Votre assistant lit les logs, où que le job ait tourné
L’assistant a-t-il ses propres droits ?
Non. Il n’y a ni compte de service ni rôle d’assistant aux droits étendus. Si vous ne pouvez pas déployer en production, l’assistant avec lequel vous échangez ne le peut pas non plus, que ce soit dans l’assistant de Cycloid ou dans n’importe quel hôte MCP compatible.
Votre assistant déclenche les Actions que vous avez déclarées et récupère statut et logs auprès de ce qui les a exécutées : une exécution GitHub Actions, un pipeline GitLab ou le Native Runner. Ce n’est pas une seconde manière d’exécuter des pipelines. C’est la même couche de coordination, avec une conversation en façade.
Toute opération lourde de conséquences revient d’abord sous forme d’aperçu de ce qui va s’exécuter, et où, et ne s’exécute qu’une fois votre accord donné.
Questions fréquentes
Non. Une Action peut déclencher votre pipeline existant dans GitHub Actions ou GitLab CI, ou dans n’importe quelle autre CI via un appel HTTP ; Cycloid le suit et diffuse les logs en continu. Le Native Runner est une option, pas une obligation.
Terraform et OpenTofu, Ansible, Helm, des scripts, des appels HTTP et des étapes Docker, sur plusieurs clouds comme sur site. Les identifiants d’accès sont injectés à l’exécution : rien ne reste dans une définition de pipeline, d’où il pourrait fuiter.
Oui. Le Native Runner se déploie sur plusieurs clouds comme sur site, et toute la plateforme fonctionne en auto-hébergé ou entièrement air-gapped. La page souveraineté détaille ce déploiement, qui démarre par un simple docker compose up.
Le Workflow Status Sync Engine rassemble progression, logs et statut des exécutions natives, de la CI externe et des webhooks dans une seule API et une seule interface. Une exécution native et un pipeline GitLab se lisent de la même façon.
Une seule vue d’état pour tous les pipelines
Apportez le pipeline que vous ne voulez pas reconstruire. En vingt minutes, nous exécuterons une Action Terraform sur le Native Runner, déclencherons l’un de vos pipelines existants et vous montrerons les deux dans la même vue.