Managed CI/CD across clouds
The cloud-native pipeline services - CodePipeline, CodeBuild and CodeDeploy, Azure DevOps, Cloud Build and Cloud Deploy, OCI DevOps - with build logs kept, artifacts signed or scanned, and deploy approval where it belongs.
7 verified modules, 3 of them live-tested apply→verify→destroy; the rest are static-validated, live-test pending.
Compare by provider
| Provider | Module | Verification |
|---|---|---|
| AWS | A Build Project that Is Not Root on Its Host | static-validated |
| AWS | CodeDeploy CI/CD (EC2 / ECS / Lambda) | ✓ live-tested |
| AWS | CodePipeline + CodeBuild CI/CD | ✓ live-tested |
| Azure | Azure DevOps Project + Repo + Pipeline | ✓ live-tested |
| Google Cloud | A Delivery Pipeline whose Production Target Waits for a Person | static-validated |
| Google Cloud | Builds that Run as a Named Account, Privately, with Approval to Deploy | static-validated |
| Oracle Cloud | A DevOps Project whose Pushes Build, on Your Network | static-validated |
How to choose
Start from where the code lives: a pipeline in the same cloud as the repository and the runtime needs no cross-cloud credential. Then compare what the build runs as (an identity you scope, or a shared one), whether a stage can require a person, and how long logs and artifacts are kept.
When not to use
A managed pipeline still runs whatever the repository tells it to. The service protects the credentials it holds; it does not review the build script, and a pull request from a stranger is the classic way in.