- Terraform modules
- Helm charts
- ArgoCD pipeline configuration
- Runbook for adding a new environment
Cloud-Native & GitOps
Infrastructure you can rebuild from git, not from memory.
If your infrastructure only exists because someone remembers how they clicked it together in the console, it's a liability, not an asset.
We set up Terraform for infrastructure, Helm and ArgoCD for delivery, and Kubernetes on AWS or GCP so every environment is reproducible from source control — a new environment is a pull request, not a week of tribal knowledge.
01 In practice
What this looks like in practice
01
Terraform modules for your actual infrastructure, not a generic starter template.
02
Helm charts and an ArgoCD GitOps pipeline so deployments are declarative and auditable.
03
Kubernetes cluster setup sized and configured for your actual workload, on AWS or GCP.
04
Secrets management that doesn't involve a Slack message.
05
A documented path from “developer merges PR” to “running in production”.
02 Deliverables
What you get
03 Proof
This model, in production
The order-processing platform runs on GCP under this model — declarative infrastructure, GitOps delivery, 2+ years in production.
04 FAQ
Cloud-native & GitOps — frequently asked questions
What is GitOps, in practical terms?
The desired state of your infrastructure and deployments lives in git, and a controller — ArgoCD, in our case — continuously reconciles the running system towards it. The practical consequences are that every change is a reviewable pull request, every environment is reproducible from a commit, and drift between what is declared and what is running becomes visible instead of accumulating silently.
Our infrastructure was clicked together in the console. Where do we start?
With the environment that hurts most, usually a lower one, so the first Terraform modules are written against real infrastructure without production risk. Infrastructure that only exists because someone remembers how they built it is a liability rather than an asset — but the way out is incremental adoption, not a weekend rewrite of everything at once.
AWS or GCP?
We work on both, and the honest answer is that for most Java workloads the choice matters less than how you operate it. Existing commitments, the surrounding data platform and your team's familiarity usually decide it. What we hold constant across either is that the infrastructure is declared in Terraform and delivered through GitOps, so the platform underneath is a swappable detail rather than a lock-in.
How should we handle secrets?
Through a managed secret store integrated with the cluster, so secrets are referenced by the deployment rather than pasted into it — and never shared through Slack, which is the pattern this replaces. The test is whether a new engineer can stand up an environment without anyone privately sending them a credential.
How long until a new environment is a pull request rather than a project?
That is the deliverable, not a side effect. The runbook for adding a new environment is part of what we hand over, and by the time modules and the pipeline are in place, standing one up is a parameterised PR rather than a week of tribal knowledge.
Talk to an architect about your infrastructure.
Tell us how your environments get built today — we'll map the path to reproducing them from a commit.