CI/CD Pipelines That Deploy to the Cloud
How GitHub Actions and GitLab CI structure a deployment pipeline, how to authenticate to Google Cloud, Azure, and Vultr without long lived keys, common deploy targets, and the guard rails that keep releases safe.
A CI/CD pipeline turns a merged commit into a running deployment without anyone copying files by hand. The continuous integration half builds and tests the code; the continuous delivery half pushes the result to a cloud target such as Cloud Run on Google Cloud, App Service on Azure, or a plain VPS on Vultr. This guide covers how GitHub Actions and GitLab CI structure a pipeline, how the pipeline should authenticate to a cloud account, the common deployment targets, and the guard rails that keep an automated deploy from becoming an automated outage.
What a deployment pipeline looks like
Most pipelines have four stages. Build compiles the code or assembles a container image. Test runs unit and integration tests against that build. Publish stores the artifact somewhere the cloud can pull it from, such as Artifact Registry on Google Cloud, Azure Container Registry, or a registry the Vultr servers can reach. Deploy tells the target platform to run the new artifact and waits for a health check to pass.
The artifact built in the first stage should be the one deployed in the last. Rebuilding on the deploy step means production could run code that was never tested. Tag images with the commit hash rather than a floating label so a rollback is a redeploy of a known image rather than a rebuild.
GitHub Actions and GitLab CI side by side
Both systems describe pipelines in YAML files stored in the repository and run them on hosted runners or on machines you host yourself. GitHub Actions organises work into workflows, jobs, and steps, and pulls reusable steps from a public marketplace of actions, including official ones from Google and Microsoft for authentication and deployment. GitLab CI uses a single pipeline file with stages and jobs, offers built in container and package registries, and has an environments feature that tracks what is deployed where.
| Concern | GitHub Actions | GitLab CI |
|---|---|---|
| Definition file | One or more workflow files under the .github/workflows directory | A single .gitlab-ci.yml at the repository root, with includes for shared pieces |
| Reuse | Marketplace actions and reusable workflows | Included templates and CI/CD components |
| Secrets | Repository, environment, and organisation secrets | Project and group CI/CD variables, optionally masked and protected |
| Cloud identity | OIDC token issued per job run | ID tokens issued per job run |
| Approvals | Environment protection rules with required reviewers | Protected environments and manual jobs |
| Self hosted runners | Supported, registered per repository or organisation | Supported, registered per project, group, or instance |
Choose the one that matches where your code lives. Moving repositories to get a marginally nicer pipeline syntax is rarely worth the disruption.
Authenticating the pipeline to a cloud account
The weakest part of many pipelines is a long lived cloud key pasted into a CI secret. If the repository is compromised, the key goes with it. Both GitHub Actions and GitLab CI can instead issue a short lived identity token for each job, and the major clouds can be configured to trust that token.
On Google Cloud this is Workload Identity Federation: you create a workload identity pool, add the CI platform as a provider, and allow tokens from a specific repository and branch to impersonate a service account. No service account key is ever downloaded. On Azure the equivalent is a federated credential on an app registration or user assigned managed identity in Microsoft Entra ID, scoped to the repository and environment, which the pipeline exchanges for an access token. Both official login actions support this flow directly.
Vultr and other VPS providers authenticate through an API key, so a stored secret is unavoidable there. Reduce the blast radius by creating a key that is used only by the pipeline, restricting it to the runner’s IP addresses where the provider supports access control, and rotating it on a schedule. For deployments over SSH, use a dedicated deploy key with a passphrase held in the CI secret store, and add the server’s host key fingerprint to the pipeline so it cannot be redirected to a look alike host.
Deployment targets by provider
On Google Cloud, Cloud Run is the simplest target for containerised web services: the pipeline pushes an image to Artifact Registry and deploys a new revision, with traffic shifted all at once or gradually. Teams on GKE deploy by applying manifests or a Helm chart with a kubeconfig obtained from the authenticated service account. Static sites can go straight to a Cloud Storage bucket behind a load balancer.
On Azure, App Service and Azure Container Apps both accept a container image or a code package from the pipeline, and deployment slots on App Service allow a warm swap between staging and production. AKS follows the same kubectl or Helm pattern as GKE. Azure also offers its own pipeline service, but the GitHub Actions integration is the more common path for repositories hosted on GitHub.
On Vultr, a deployment usually means one of three things: connecting over SSH to pull a new image and restart a container, using the Vultr API to rebuild a server from a snapshot or a cloud-init script, or deploying to Vultr Kubernetes Engine with kubectl. The SSH approach is easy to start with and hard to make safe at scale, so move to image based deployments as soon as more than one server is involved.
Guard rails that keep deploys safe
- Deploy to a staging environment first and run smoke tests before the production job is allowed to start.
- Require a manual approval or a named reviewer for the production environment.
- Pin action and template versions to a commit hash or tag so a change upstream cannot alter what runs in your pipeline.
- Set a concurrency rule so two deploys to the same environment cannot overlap.
- Emit a deployment marker to your monitoring system so an error spike can be matched to a release.
- Script the rollback and test it, so the answer to a bad deploy is one click rather than an investigation.
- Store no secrets in pipeline logs; mask variables and avoid echoing environment output.
Budget for the pipeline itself. Hosted runner minutes are metered, and a test suite that runs on every push to every branch can cost more than the servers it deploys to. The guide to budgets and billing alerts explains how to watch the cloud side of that cost.
Where to go next
A pipeline needs a target account with the right services enabled. The marketplace lists Google Cloud accounts for Cloud Run and GKE, Azure accounts for App Service and AKS, and Vultr accounts for VPS and Kubernetes targets, each with its variant labels stated on the page.
If the infrastructure the pipeline deploys to is not yet defined as code, start with Terraform basics. For the environment the pipeline deploys to before production, read building staging and test environments. The Cloud Library hub collects the rest of the developer workflow series.