A regulated digital-asset bank gets audited on one question above all others: show me how this changed, and who approved it. We built a platform where the answer is a single word - git.
The challenge
A regulated digital-asset bank needs two things that usually pull in opposite directions: the controls and auditability of a bank, and the release velocity of a startup. Manual change processes are too slow to keep up with the product teams. Ungoverned automation is a non-starter for a regulated institution.
The bar is unforgiving. Every infrastructure change has to be reviewable and traceable. Customer-grade data sits behind private certificate authorities and a real secrets story, not environment variables. Accounts have to be isolated the way a regulator expects to find them. On-call has to be something you can evidence, not something configured by clicking around a console. And separate compliance and regtech workloads have to flow through the same governed delivery path as everything else.
That is what makes GitOps hard here. It is not enough for automation to be fast; every link in the chain has to be reviewable, reproducible and on the record, or it fails an audit.
Our approach
The reframe at the heart of the work: in a regulated estate, the audit trail is not a report you assemble before an assessment - it is a property of how the system is built. So we made git the source of truth for as much of the platform as possible.
Isolation at the boundary
The foundation is a multi-account AWS landing zone, split the way a bank’s auditors expect to find it: dedicated accounts for the organization and Identity Center single sign-on, security, networking-core, logging-and-monitoring, billing, shared resources and observability, plus separate accounts per workload domain. Drawing isolation into purpose-built accounts puts the audit boundary in the cleanest place for a regulator to look, instead of relying on in-account guardrails to hold the line.
The compliant path is the default path
On top of the landing zone sits a large in-house Terraform module library - EKS, RDS, MSK/Kafka, OpenSearch, ElastiCache, Vault, AWS Private CA, WAFv2, immutable S3, a credential rotator, an Istio module and more. Every team builds from the same audited, versioned primitives rather than hand-rolling resources. Application CI runs on GitLab with shared pipeline templates and a merge-train to master, gated by a static-analysis tool and a dependency-vulnerability scanner. Security and quality checks are mandatory, not optional - the secure path is the easy path, so teams do not have to choose between shipping and compliance.
No out-of-band changes
Change control is what makes it bank-grade. Terraform never runs from a laptop. Changes go through Atlantis as merge-request automation, behind egress controls, scoped IAM and custom middleware in a hardened container image. The plan is on the merge request, the apply is gated by approval, and the whole thing lands in git history. There is no infrastructure mutation that did not pass through review - the plan, the approval and the apply are all on the record.
Under the hood
Delivery onto Kubernetes is GitOps. ArgoCD holds the desired state per environment - dev, test, UAT, prod and tools - and reconciles it continuously onto EKS, so the running state is always exactly what git says it should be. The mechanics are deliberately uniform:
- A change lands as a merge request, reviewed and gated by the CI quality and vulnerability gates.
- Terraform changes apply through Atlantis; application changes update the desired state ArgoCD watches.
- ArgoCD reconciles the cluster to the committed state, with an image updater promoting new builds and Istio handling the service mesh.
- Secrets and identity resolve at runtime: Vault and an AWS Private CA hierarchy issue and manage certificates, while External Secrets Operator bridges Kubernetes to AWS Secrets Manager so nothing sensitive ever lives in a manifest.
- Break-glass logins raise security notifications automatically, so the rare manual access is itself logged and alertable.
What stands out is how much of the operational surface is itself code. The GitLab structure - groups, repositories and branching across every business domain - is Terraform-managed, so source-control governance is reproducible. PagerDuty is fully managed in Terraform too: services, schedules, escalation policies, event orchestration and the ticketing integration. The soft, click-driven parts of a platform become reviewable, versioned artifacts like everything else.
The same model carried a separate compliance and regtech stack onto EKS - workflow-driven evaluation services backed by their own data stores - delivered through the same ArgoCD GitOps path.
The outcome
Changes are fast and safe at the same time. Every deployment is a merge request - reviewed, logged, and a single revert away from rollback - which is exactly the trail a regulated platform needs. Promotion across environments and additional deployment targets is repeatable rather than bespoke, because everything runs the same reconciliation loop. Velocity without giving up control, and an audit story that is built in rather than bolted on.
Key takeaways
- Git is the answer to “who changed this.” Route every infrastructure change through PR automation so the audit trail is a property of the system, not a reporting exercise.
- Make the compliant path the default path. A versioned module library plus mandatory quality and vulnerability gates means teams never choose between shipping and compliance.
- Isolate at the account boundary. A multi-account landing zone puts the audit boundary where a regulator looks first.
- Manage the soft surfaces as code too. Source-control structure, on-call and PKI in Terraform are reproducible and auditable in a way consoles never are.
- One reconciliation loop, many destinations. Per-environment GitOps makes promotion and additional deployment targets repeatable from a single platform definition.