CI/CD Pipeline Services for GitHub Actions and GitLab CI
PlatOps designs and rebuilds deployment pipelines for companies with 10–200 employees and funded SaaS startups: the path from pull request to production, including who can approve it and how to undo it.
We replace stored cloud keys with short-lived OIDC credentials, put production behind an approval, add security scans that block real problems, and test the rollback before you need it.
What you get
Delivered as code, reviewed by your team
- Pull request checks and security scans
- One signed artifact per commit
- OIDC cloud roles, no stored keys
- Approval-gated production environment
- Rollback tested with your team
- Runbook and pipeline code in your repos
Deploys to AWS, Azure or GCP, on Kubernetes or simpler platforms.
Signs your pipeline needs work
Most small teams have a pipeline. Fewer have one that is safe to hand to a new developer, survives a compromised dependency and can undo a bad release in minutes.
It fits if this sounds familiar
- Deploys happen from one developer's laptop, or only one person knows how to run them
- Long-lived AWS, Azure or GCP access keys sit in CI secrets or repository variables
- Production deploys need no approval, or the approval lives in a chat message
- Nobody has rolled back a release on purpose, so nobody knows if it works
- Builds take long enough that developers stop waiting for them
- A customer or auditor asked how code reaches production and the answer was a diagram from memory
Probably not a fit if
- You need test suites written for your application. We wire tests into the pipeline; your developers own them
- You want to move CI platforms for its own sake. If GitHub Actions or GitLab CI already works, we improve it in place
The pipeline we build
Five stages, the same on GitHub Actions or GitLab CI, adapted to whether you deploy to Kubernetes, ECS, Cloud Run, App Service or plain virtual machines.
1. Pull request checks
Build, unit tests, linting, plus static analysis, dependency, secret and infrastructure-as-code scans on every pull request.
Why: Problems are cheapest to fix before merge. Branch protection makes green checks and a second reviewer mandatory.
2. Build once, sign, store
One immutable artifact per commit, usually a container image tagged with the commit SHA, with an SBOM and a signature where the platform supports it.
Why: Staging and production run the exact same bytes. Rebuilding per environment is how "it worked in staging" happens.
3. Automatic deploy to staging
Merges to the main branch deploy to staging with no manual step, followed by smoke tests against the running service.
Why: Staging stays current, and the deploy path is exercised dozens of times before it matters.
4. Gated production release
Production is a protected environment. Its cloud role can only be assumed by that environment, and a named reviewer approves the job.
Why: No one, including the pipeline, can reach production from a feature branch or a forked pull request.
5. Verify and roll back
Post-deploy health checks, and a rollback that redeploys the previous artifact in one step. Blue-green or canary where your platform supports it.
Why: A rollback you have never run is a hope, not a plan. We test it during handover.
Cloud access without long-lived keys
Your pipeline holds the keys to production, which makes it a target. These four practices close the most common ways in, and each comes straight from the platform or government guidance linked below.
OIDC instead of stored cloud keys
GitHub Actions and GitLab CI can both exchange a signed job token for short-lived AWS, Azure or GCP credentials. GitHub's documentation puts it plainly: the cloud provider issues a token valid for a single job that then expires automatically.
GitHub: OpenID ConnectRoles scoped to repository and environment
The cloud trust policy checks the token's subject claim, so the production role accepts only one repository's production environment. GitLab exposes the same idea through ID tokens and their claims.
GitLab: connect to cloud servicesThird-party actions pinned to a commit SHA
GitHub calls pinning to a full-length commit SHA the only way to use an action as an immutable release. In March 2025 the tj-actions/changed-files compromise leaked CI secrets into workflow logs for repositories that used a moving tag.
CISA alert on CVE-2025-30066Read-only tokens by default
The default GITHUB_TOKEN gets read-only repository access, and individual jobs ask for more only when they need it. Workflows avoid pull_request_target with untrusted code, which GitHub warns can expose secrets and write access.
GitHub: secure use referenceWhat a scoped trust policy looks like
The condition block on an AWS IAM role that GitHub Actions assumes through OIDC. Only jobs running in the production environment of one repository can get credentials. A forked pull request or a feature branch cannot.
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
"token.actions.githubusercontent.com:sub": "repo:your-org/your-app:environment:production"
}
}For the wider picture of how attackers get in through dependencies and build tools, read the software supply-chain attack playbook for SMBs.
Environments and approvals
Production gets its own environment, its own cloud role and its own secrets, and a person approves what reaches it. Both major CI platforms support this natively.
GitHub environments
Required reviewers (up to six people or teams, any one of whom can approve), deployment branch rules and environment-scoped secrets. On private repositories some protection rules depend on your GitHub plan, which we check before designing around them.
GitHub: managing environmentsGitLab protected environments
Deploy access limited to named users, groups or roles, with optional manual approvals before a production job runs. Protected environments need GitLab Premium or Ultimate; on the Free tier we rely on protected branches and scoped variables instead.
GitLab: protected environmentsNeed the pipeline to satisfy SOC 2, HIPAA or PCI DSS? Policy-as-code gates and audit evidence are covered by our DevOps compliance checklist, which maps each pipeline control to the requirement it meets.
What an engagement delivers
Everything below ends up in your repositories and cloud accounts. Nothing depends on a PlatOps login to keep working.
- Pipeline definitions in your repositories, with reusable workflows or templates shared across services
- OIDC trust and cloud roles defined in Terraform, one per repository and environment
- No long-lived cloud keys left in CI, and the old ones revoked
- Branch protection or rulesets requiring review and passing checks
- Security scans with agreed severity thresholds and a written exception list
- Staging and production environments with approvals and scoped secrets
- A deploy and rollback runbook, and one rollback performed with your team watching
- Build caching and parallel jobs where they shorten the feedback loop
Review
We read your workflows, CI settings, cloud credentials and branch rules, then write down the gaps in order of risk. If the pipeline is mostly fine, the fix list is short and we say so.
Build
A fixed-scope project to put the reference pipeline in place, service by service, without stopping your releases. Changes arrive as pull requests your team reviews.
Hand over or run
Your team keeps the pipeline with the runbook, or we keep it green under a Managed DevOps retainer: failed builds, runner and action updates, and new services.
Pipeline builds are quoted as fixed projects once we have seen your setup. Keeping pipelines running afterwards is part of a retainer plan: Essential at $3,500–$7,500 a month, Professional at $8,000–$15,000 and Enterprise priced to scope. Not sure where to start? The Cloud & DevOps Audit Sprint is a fixed $5,000, 30-day engagement that finds cost, security and reliability risk and ships three quick wins.
Several product teams copying each other's pipelines is usually the point where shared templates turn into a platform. Our guide to platform engineering vs DevOps for SMBs explains when that investment pays off.
Related services
The pipeline is the path to production. These services cover what sits on either side of it.
Managed DevOps
The monthly service that keeps pipelines, infrastructure code and on-call running after the build.
Learn moreDevOps Compliance
SOC 2, HIPAA and PCI DSS gates and evidence in the pipeline, with an 11-control checklist.
Learn moreKubernetes
Cluster upgrades, security and GitOps for the platform your pipeline deploys to.
Learn morePlatform Engineering
Golden paths and self-service templates once several teams share the pipeline.
Learn moreCloud-Native Security
Image signing, admission control and runtime detection for what the pipeline ships.
Learn moreIncident Management
Someone answers, and fixes it, when something breaks
Learn moreCI/CD pipeline FAQ
What do CI/CD pipeline services include?
At PlatOps: pull request checks and security scans, one signed build artifact per commit, automatic deploys to staging, an approval-gated production environment, OIDC access to your cloud instead of stored keys, and a tested rollback. Everything is delivered as code in your repositories, with a runbook.
Which CI/CD platforms do you work with?
Mostly GitHub Actions and GitLab CI, plus Azure Pipelines for Azure-heavy teams, and Argo CD or Flux when the target is Kubernetes. We improve the platform you already use. Moving to a different CI system is only worth it when the current one blocks something concrete.
Why use OIDC instead of access keys in CI?
A stored access key works from anywhere until someone revokes it, so a leaked CI log or a compromised third-party action can expose it. With OIDC the pipeline gets credentials that last for one job, and the cloud role can require a specific repository and environment before it issues them.
How do approvals for production deploys work?
Production becomes a protected environment in GitHub or GitLab. The deploy job pauses until a named reviewer approves it, only the main branch can target it, and its cloud role and secrets are unavailable to any other branch or environment. The approval is recorded with the run.
Which security scans should block a build?
Static analysis, dependency scanning, secret detection and infrastructure-as-code checks on every pull request. We agree a severity threshold with you, usually failing on critical and high findings with a known fix, and record accepted risks with an owner and expiry so the gate doesn't get switched off.
How do rollbacks work?
Because each commit produces one immutable artifact, rolling back means redeploying the previous one, in a single pipeline step. Database migrations are written to stay compatible with the previous release so that rollback stays safe. We perform a rollback with your team during handover.
Do CI/CD pipelines help with SOC 2 or HIPAA?
Yes. Mandatory review, approval-gated production deploys and run history are change-management evidence auditors ask for. Our DevOps compliance service maps these controls to SOC 2, HIPAA and PCI DSS and keeps the evidence collected.
How much does a CI/CD engagement cost?
Pipeline builds are quoted as a fixed project after we review your setup, because ten services cost more than two. Ongoing pipeline upkeep is part of a Managed DevOps retainer: Essential is $3,500–$7,500 a month, Professional $8,000–$15,000 and Enterprise is custom.
Get a second pair of eyes on your pipeline
Share how code reaches production today. We will point out stored keys, unpinned actions, missing approvals and untested rollbacks, and tell you what is worth fixing first.
Related Articles
Guides and resources to help you go deeper