Engineering and AI

Platform & Cloud Engineering

Cloud accounts, infrastructure as code, CI/CD, identity, secrets and observability, built so that one leaked token or one compromised build runner cannot reach production on its own.

The platform decides how much damage one mistake can do. A CI token that can deploy to production is a production credential. A build runner that can read every secret is a production host. A single shared cloud account means one over-broad role reaches everything. When we test other teams' cloud estates, the path to production often runs through this layer rather than through the application.

We build the platform as code in your accounts, starting from the account structure and identity model, because everything else inherits from them. Environments are separated, deploy credentials are short-lived and scoped to the job that uses them, and changes reach production through reviewed plans rather than console clicks. Logging and alerting go in with the resources they watch. Everything is documented so your engineers can change it, rebuild it and explain it to an auditor.

Usually, one of these is true

Production was set up by hand in a console, and nobody is confident they could rebuild it from scratch if they had to.
Every environment shares one cloud account, and developers hold long-lived keys with administrator access.
An incident or a near miss showed that the logs could not tell you who changed what, or what an attacker could have touched.
A SOC 2 or ISO 27001 audit is coming, and you need change control, access reviews and audit logging that produce evidence without a scramble.

What we build

The layer between your code and your customers. Everything below is declared in code, reviewed like code, and delivered into accounts you own.

Accounts and network foundation. Account or project structure per environment, organisation-level guardrails, network layout, private connectivity, DNS, and the baseline every new account inherits.
Infrastructure as code. Modules and state management in a tool such as Terraform, OpenTofu or Pulumi, with plan review, policy checks and drift detection so the repository matches what runs.
CI/CD and supply chain. Pipelines that deploy with short-lived federated credentials, protected branches, pinned dependencies, signed artefacts and provenance for everything that reaches production.
Identity and secrets. SSO for people, workload identity for services, least-privilege roles with audited break-glass access, and secrets in a manager with rotation rather than in variables and repositories.
Containers and Kubernetes. Image builds, registries and scanning, and, where a cluster is justified, RBAC, admission policy, network policy, pod security and a tested upgrade path.
Observability. Logs, metrics and traces, for example via OpenTelemetry, with audit logs kept centrally, alerts tied to runbooks, and enough context to reconstruct an incident after it ends.

How the build runs

We scope it with you in the chat, then send a written scope with a fixed price and fixed dates. Every change lands as a pull request from the first day, so your team can review all of it.

Current state. We read your existing accounts, pipelines and infrastructure code, list who and what can reach production today, and agree the target design and migration order in writing.
Privilege map. We draw the account structure, identity model, network and pipeline trust boundaries, and record every credential: what it can reach, who holds it and how it is revoked.
Build as code. Foundations first, then pipelines, then workloads, each delivered as a reviewed pull request with its plan attached and applied to non-production before production.
Security test pass. Before cutover, the team that runs our cloud and Kubernetes assessments tries to reach production from a developer laptop, a pull request or a single workload. What they find is closed before go-live.
Cutover and handover. We move workloads in stages with a rollback at each step, run restore and failover drills with your team, and hand over runbooks and administrative access.

What you get

Infrastructure code. Modules, environments and pipeline definitions in your repositories, able to rebuild the platform from an empty account.
Privilege map. A diagram and inventory of every human and machine identity, what it can reach and how it is rotated or revoked, for your security lead and your auditors.
Delivery pipeline. CI/CD with federated credentials, required reviews, artefact provenance and a documented rollback, owned and operated by your team.
Observability and alerting. Dashboards, log retention and alerts wired to runbooks, set up in your own tooling and accounts.
Runbooks and drill notes. Procedures for deploys, rollbacks, restores, secret rotation, onboarding and offboarding, with notes from each drill we ran with your team.

What we need from you

Administrative access to the cloud organisation, or the ability to create accounts and projects in it, plus visibility of billing.
Admin access to source control and the CI system, and a list of the services and environments in scope.
An engineer or team who will own the platform after handover and can review pull requests during the build.
Your compliance obligations, data residency constraints and any change-management process that production changes must follow.
Agreed maintenance windows, or rules for how live workloads may be moved, for anything already serving customers.

What we can show you

We attack this layer too. Our cloud and Kubernetes assessments look for the routes from CI tokens, build runners and over-broad roles into production. The platform is designed to close those routes first.
Evidence an assessor can use. We do not issue certifications. We build the platform so that access, change and logging evidence exists when a SOC 2 or ISO 27001 assessor asks for it, and we work alongside whoever signs off.
No lock-in. Everything runs in your accounts and is declared in code in your repositories. There is no platform or managed layer of ours in the middle.
Finding to fix, same team. When the pre-cutover test finds a path to production, the engineers who built the platform fix it. One team runs testing, hardening and engineering, so nothing waits on a hand-over.

Standards we work to

The benchmarks, frameworks and open specifications the platform is built against, so assessors, customers and future engineers recognise the choices.

CIS Benchmarks
SLSA
NIST SP 800-190
NIST SP 800-207
NSA/CISA Kubernetes Hardening Guidance
OpenTelemetry

Common questions

Which clouds and tools do you work with?

The major public clouds, and the infrastructure-as-code and CI tools teams commonly run, for example Terraform or OpenTofu with GitHub Actions or GitLab CI. Where you already have a working toolchain, we build on it rather than replace it. Tool choices are written down with the reasons, so they can be revisited.

Do we need Kubernetes?

Often not. A managed container service or a platform-as-a-service runs many products with far less to operate and secure. We recommend a cluster when the number of services, scheduling needs or portability requirements justify the operating cost, and we explain that reasoning in writing.

Can you work on our existing infrastructure rather than starting again?

Yes, and that is usually the right call. We import existing resources into code, fix the most dangerous access first, and migrate in stages with a rollback at each step, so production keeps running throughout.

Will this get us through a SOC 2 or ISO 27001 audit?

We do not issue certifications or act as your auditor. We build the controls an assessor looks for, such as reviewed changes, least-privilege access, central audit logs and tested restores, and document where the evidence lives. We work alongside whoever signs off.

Do you run the platform for us after handover?

The default is that your team runs it, using the runbooks and the drills we did together. If you want continued help, such as reviewing changes or handling major upgrades, we scope that separately. Detection and response on top of the platform is our Security Operations service.

Related services

Tell us about the system in the chat or on the contact page. Yaali, our AI agent, answers first and brings in an engineer.