Safer, repeatable delivery
Getting a change from a commit to production without it depending on one person remembering the steps.
All 2 situations
AWS-led cloud and platform engineering · UK
Cloud engineering for business-critical systems.
When product growth outruns the infrastructure work behind it, InfraEdge takes on defined cloud and platform projects — delivery, security, reliability, IaC and cloud cost — and leaves the result in your repositories.
Not sure where you fit? Find your path in seven questions
83 seconds · how an engagement runs
- You talk to the engineerThe first call is with the person who would do the work.
- One lead engineer, start to finishAssessment, changes, review questions and handover.
- Tools gather evidence. Engineers decide.Automation collects, checks and drafts. An engineer decides, reviews and explains.
Your stack, not ours
The work lands in the tools your team already runs — followed here the way a change travels.
01Defined inIaC
- Terraform
- CloudFormation
- AWS CDK
- Pulumi
- Other IaC
02Shipped byCI/CD
- GitHub Actions
- GitLab
- Azure DevOps
- Argo CD
- Other pipelines
03Runs onCloud
- AWS
- Kubernetes
- Docker
- Other platforms
04Watched byObservability
- Datadog
- Prometheus
- Grafana
- Other tooling
+ more we work with
AzureGoogle CloudOpenTofuTerragruntHelmJenkinsVaultPackerAnsibleCloudflarePostgreSQLRedisSentryNGINXand what your team already runs
Most teams arrive with one of these
01 / 5
What brought you here?
The problems teams describe — each with a bounded first package, and what we will not take on.
Control and governance
Knowing what exists, who owns it, and how it changes — across accounts, identity, network, spend and the agents you let in.
- Infrastructure that is not defined as code
- An account and identity structure that has been outgrown
- Spend rising without an owner
Readiness and resilience
Being able to show a customer, an auditor or yourselves that the thing works, and recovers.
- A customer security review with a date on it
- Backups that have never been restored
- A launch that needs a foundation under it
Delivery capacity and handover
Senior platform work that is agreed, funded and not getting done — and making sure it outlives us.
All 3 situationsThe work
02 / 5
Anonymised prior delivery, described by technical shape.
No client names, no logos, and no figures we did not measure.
Terraform adoption
Years of hand-built AWS, imported rather than rebuilt
VPCs, RDS, S3 and IAM roles brought under Terraform state without a risky start-again migration, on an estate carrying live traffic.
Recovery proven
Backups that had never actually been restored
Critical workloads mapped, recovery objectives agreed per workload, controlled restore tests run, and the timings written down.
Customer assurance
An audit date, and an estate with no consistent policy
IAM hardened, logging extended, encryption made consistent and exposure removed — the engineering behind the findings, not a document describing them.
What a project leaves behind
03 / 5
What you keep when we stop.
No managed service to keep paying for, and nothing important in a tool only we can log into. The work is in your repository, with the runbooks and the backlog beside it.
your-org/infra
main · yours
- infra/ Your repository. Ours is not in the loop.
- terraform/ Every account described in modules you can read
- accounts/ management · identity · log-archive · staging · prod
- modules/ Written to be changed by your team, not admired
- .github/workflows/ plan on pull request, apply behind an approval
- docs/ Runbooks and decision records, versioned with the code
- runbooks/ Written for whoever holds the pager at 03:00
- decisions/ Why, not only what — one file per decision
- inventory/ Every account, workload and owner, regenerated on demand
- BACKLOG.md What we did not do, ranked, with the reasoning
History of the engagement
5 of 61 commits
- a7f21c4 docs: add the restore runbook, with the timing we measured
- 3f9ac21 feat: separate staging and production accounts
- 91be0d7 fix: scope the deploy role trust policy (IAM-014)
- 5c40a18 feat: org trail into a log archive account
- 0e8d33b chore: import the estate into Terraform state
Every change we made is a commit with a message, a plan hash and a named approver. You can reconstruct the whole engagement from git log without calling us — which is the point.
Not just code in Git — identity, recovery and automation that keep running in your accounts after we leave.
Permission-set policies
Scoped to the roles you actually have
- PlatformReadRead-only across the estate
- PlatformDeployCI through OIDC — no stored keys
- PlatformBreakGlassTime-boxed, alerts when used
- PlatformAuditAuditor view, no shared login
Backup and DR plan
RPO and RTO per tier, rehearsed
- DatabasesPoint-in-time restore, timed
- Object storageVersioned, deletion-protected
- Backup isolationOff the workload credential path
- Infrastructure stateTerraform state locked
Repeatable jobs and schedulers
Running in your accounts, not ours
- nightly-planDrift caught before it is a finding
- dev-schedulerNon-prod off outside hours
- restore-drillRestore proof on a schedule
- expiry-watchCerts and secrets before expiry
A working, tested process in your cloud — not a PDF and a login to somebody's portal. Everything above is a file in the repository beside it, not a separate system you have to trust us to keep running.
How the work is controlled
04 / 5
We do the engineering. Your team keeps every decision that binds the business.
One engineer leads your project from the first call to the handover: reads the evidence, writes the changes and answers your reviewer on the pull request. A named person on your side approves the exact plan that gets applied.
Your InfraEdge engineer does
The delivery work, through your process.
- Discovery through a scoped read-only role
- Walking your team through the findings, on a call
- Writing the change as code, as a pull request in your repository
- Answering your reviewer’s questions on that pull request
- Testing, and exercising the failure cases
- Writing the runbooks and the decision record
- Saying when we think something is a bad idea
You keep
Every decision that binds your business.
- Whether the work happens at all, and in what order
- Reviewing and merging the pull request
- Approving the plan that gets applied, by name
- What risk the business is willing to carry
- Who holds the pager afterwards
- Whether the handover is good enough to accept
Normal changes use this gate. If the path itself is broken, break-glass is separately authorised, time-bound and logged; lasting changes are reconciled back into code.
Automation where it helps. An engineer where it matters.
What the tooling does
Collection, checks and first drafts, done the same way every time.
- Collects configuration through the read-only role
- Runs the same checks on every account in scope
- Drafts repetitive code and report text, for an engineer to review
- Re-checks each fix after it is applied
What an engineer does
Everything that needs judgement, and every conversation.
- Ranks the findings by what they put at risk for you
- Decides what is worth changing, and what is not
- Writes or reviews every line, and tests every change, before it reaches you
- Explains it, and answers your team’s questions
No tool of ours approves a change or applies one to your production. Every decision and every change is attributable to a named person.
Judge the deliverable
05 / 5
An assessment report, before you commission one.
Judge the shape of the deliverable: each finding tied to the evidence behind it, with a plain statement of what could not be checked.
See the deliverable first
Read a sample EdgeAssess report
The complete deliverable, unabridged: maturity across six pillars, fourteen worked findings with the evidence behind each, a cost baseline and a 30/60/90 plan. The subject company is invented; the structure and the rigour are exactly what you would receive.
Name and work email, then it lands in your inbox. Two required fields, and we do not run a nurture sequence off them.
Who this fits
A good fit, and where we are the wrong shape.
From a first platform hire to a platform group that is outnumbered. The common thread: something specific is due.
It fits when
- Production is already running, on AWS, Azure or GCP.
- Something specific is due: a deadline, a customer review, a hire, a funded backlog that is not moving.
- There is a named technical owner to work with.
- You want changes reviewed and approved by your own people.
We are the wrong shape if you need
- A 24/7 on-call rota. We do not run one.
- A compliance certificate. That comes from an auditor or an accredited body, not from us.
- A supplier that holds production authority. A named person on your side approves every change.
Capable teams are the normal case: most of this work exists because the people who could do it are committed elsewhere. Starting somewhere other than a project? Delivery partners, hiring and handover and investor diligence each have their own route. Or answer seven questions and get a written recommendation.
Describe your project
Twenty minutes, no charge, with the engineer who would do the work. We work out what would actually help — which is sometimes us and sometimes not. Nothing is priced on the call; if there is work worth doing, a written scope and a price reach you within 24 hours.