Native Scaleway runners for Cadence.CI

Cadence.CI follows a “Bring Your Own Infrastructure” model: orchestration runs on Cadence.CI, compute runs on infrastructure you control. Scaleway is now one of the public clouds it provisions runners on directly.

One instance per job

A run doesn’t reuse a pool of pre-warmed machines. For each job, Cadence.CI:

• creates a dedicated security group, open only on the port the run needs,
• reserves an IP,
• generates a TLS certificate for that IP so the connection back to Cadence.CI is encrypted from the first byte,
• spins up a Scaleway instance and resizes its root volume to what the job actually asked for,
• pushes a cloud-init payload that bootstraps the Mélodium engine with that certificate,
• boots it and waits for it to come up.

When the job ends, all of it goes away: the instance, the security group, the reserved IP, the volume. Nothing sits around waiting for the next run.

Why that shape

This is what “ephemeral runners” means in practice: no idle machine is ever billed, and there’s no long-lived instance accumulating access or state between jobs. Auto-scaling falls out of the same mechanism, since demand is just “spawn one more” or “spawn zero,” not a fleet to size in advance.

It also means the account running the job is yours. Runners provision inside your own Scaleway project, not a shared pool, so isolation, region placement, and cost are all under your control.

What this unlocks

Any pipeline or distributed workload that can run on Cadence.CI can now target Scaleway as its compute, with the same lifecycle guarantees as the rest of the platform: provisioned when needed, observable while it runs, and gone when it’s done. More providers are on the roadmap .