DevSecOps · Cloud-native DevOps
Kubernetes releases your team can read, review and roll back
We set up the path from a merge to a running workload. Images are built once, each service gets a Helm chart, and a GitOps controller promotes the same image through SIT, UAT and PROD. Your engineers own every file it runs on.
The problem
Where this usually breaks down
Every service deploys differently
One team runs kubectl from a laptop, another has a shell script in its pipeline, and a third edits the cluster by hand. Nobody can say what is running where.
Images rebuilt for each environment
Rebuilding the image for production can pick up a newer base layer or library. What passed testing in UAT is then not quite what ships, and nobody notices until it fails.
Secrets living in the repository
Credentials sit in pipeline variables, values files or a private branch, so rotating one means a search across repositories, and everyone with clone access can read them.
What we do
What we set up, and how each part works
We work in your repositories and through your change process, so everything we set up can be reviewed, run and changed by your engineers after we leave.
Images built once and promoted unchanged
CI builds each image once from a pinned base, scans it and pushes it to your registry with an immutable tag. SIT, UAT and PROD all run that same image, retagged for release rather than rebuilt.
Helm charts and plain manifests
Simple services get plain Kubernetes manifests, and services with real configuration variety get a Helm chart. Values per environment live beside the chart, so a reviewer sees exactly what changes between UAT and PROD.
GitOps promotion with Argo CD
Argo CD reconciles each cluster to the state declared in Git, so a release is a reviewed merge rather than a command someone typed. Promotion from SIT to UAT to PROD follows one path, with an approval before each step.
Managed clusters defined in code
We define Google Kubernetes Engine or Azure Kubernetes Service clusters in Terraform, with private nodes, workload identity and a namespace per team. Nodes pull images from the registry over a private endpoint where the platform supports it.
Secrets issued at deploy time
HashiCorp Vault issues secrets to workloads at start-up, so the repository describes every environment without holding a single credential. Rotating one becomes a change in Vault, not a search through repositories.
Reference architecture
The architecture as it was delivered
Figures from published engagements, reproduced unchanged. Open any figure full size, or read the write-up it comes from.
- Read the write-up: Security gates inside every pipeline, not after them
Figure 1 — The toolchain by stage, from a developer’s machine to a GitOps-managed production cluster.
Open full-size image: Figure 1 — The toolchain by stage, from a developer’s machine to a GitOps-managed production cluster. - Read the write-up: Omnichannel banking on Microsoft Azure, private by default
Figure 2 — Application architecture: every channel enters through one controlled edge, and every data service is reachable only through a private endpoint.
Open full-size image: Figure 2 — Application architecture: every channel enters through one controlled edge, and every data service is reachable only through a private endpoint.
What you keep
What stays with your team when we finish
Everything is committed to your repositories or written into your documentation, under your access controls. Nothing depends on us to keep running.
Pipeline and GitOps configuration
The CI definitions, Argo CD applications and environment values in your repositories, with every change to a cluster arriving as a reviewed merge request.
Helm charts and a service template
A chart or manifest set for each service, and a starter template the next team copies to get the same build, scan and promotion path.
Cluster Terraform and namespace baseline
Terraform for the clusters, node pools, namespaces and access, plus the baseline every namespace receives: network policies, resource quotas and the Vault integration.
A promotion and rollback runbook
Who approves each promotion, how to roll back by reverting a commit, what to do when Argo CD reports drift, and how to rotate a secret in Vault.
How we work
How an engagement runs, phase by phase
Each phase ends with something your team reviews and signs off before the next one starts. We work inside your change control, not around it.
01
Trace the current path
We follow a change from a developer’s machine to production and note every manual step, credential and environment difference on the way. That map decides what to standardise first and what can wait.
02
Agree the promotion model
With your engineering leads we agree the environments, who approves each promotion, and how an image moves from SIT to UAT to PROD. Each decision is written down before any tooling is configured.
03
Take one service end to end
We take one real service through the whole path first: image, chart, Argo CD application, secrets and approvals. Problems surface on that one service, where they are cheap to fix, before the pattern spreads.
04
Onboard teams and hand over
Further services move onto the path from the template, with your engineers doing the work and ours reviewing it. By the end, your platform team owns the clusters, the GitOps configuration and the runbook.
Technology
The tools this work runs on
Each group says whether a tool appears in our published work, so you can tell what we have shown from what we offer.
Run in production
- Kubernetes
- Google Kubernetes Engine
- Azure Kubernetes Service
- Docker
- Helm
- Argo CD
- GitLab
- HashiCorp Vault
- Terraform
Evidence
Published work behind this service
Each statement below points to a write-up you can read in full, with the architecture and the stack as they were delivered.
For a DevSecOps delivery platform, we built GitOps deployment with Argo CD, which reconciles SIT, UAT and production on Google Kubernetes Engine, with Helm charts and secrets from HashiCorp Vault.
For a bank’s omnichannel platform, we designed the application tier on Azure Kubernetes Service behind an internal load balancer, pulling images from a container registry over a private endpoint.
Questions
What teams ask before we start
Do we have to use Argo CD for GitOps?
No. Argo CD is what we reach for first, because it shows clearly how each cluster differs from Git and suits approval-based promotion. If your team already runs another GitOps controller, we keep it and apply the same promotion model.
We run clusters on more than one cloud. Does that change the approach?
Very little. The image, the chart and the promotion path stay the same whether the cluster is Google Kubernetes Engine, Azure Kubernetes Service or self-managed Kubernetes. What differs is the cluster Terraform, the identity integration and how nodes reach the registry privately.
Who can deploy to production once this is in place?
Nobody deploys by hand. A release to PROD is a merge to the production configuration, approved by the people you name, and Argo CD applies it. Cluster administrator access is kept for break-glass use, and every use of it is logged.
What happens when a release goes wrong?
You revert the commit that promoted it, and Argo CD returns the cluster to the previous image. That image already passed every earlier gate, so rolling back never means rebuilding anything under pressure.
Who owns the platform after handover?
Your platform team. The Terraform, charts, Argo CD configuration and runbook sit in your repositories from the first commit, and your engineers onboard the later services themselves. We can stay on for reviews, but nothing depends on us.
Related services
What teams often need alongside this
CI/CD pipelines with enforced gates
Pipelines that run unit tests, SCA, SAST, quality and image scans in cost order, and send every failed gate to the team that owns it.
Security gates inside the pipeline
SCA, SAST, image scanning, DAST and a penetration test placed as pipeline gates, each result owned by development, QA or security.
Google Cloud foundations
A Google Cloud hierarchy with folders, organisation policies and Shared VPC, plus Google Kubernetes Engine clusters your pipeline deploys to.
Next step
Plan your Kubernetes delivery path with us
Tell us how services reach your clusters today and where releases get stuck. We will come back with the first changes worth making to the promotion path.