Everything as a platform
AWS landing zone, security, networking, and the Kubernetes app-delivery layer - all defined as code in Git from day one and shipped through automated pipelines, not GitOps added on later.
What's included
- AWS landing zone as code. A Terraform/OpenTofu, AWS Organizations-first foundation built with NTC - accounts, networking, and identity, OPA-governed and mapped to C5/GDPR from the start if needed.
- Kubernetes app layer as code. An EKS cluster and application delivery through a GitOps controller (ArgoCD or Flux), defined in Git alongside the infrastructure it runs on.
- One reviewed Git history. Infrastructure and application changes go through the same pull-request review and CI validation like every other change in the platform.
- Self-services from the beginning. Platform capabilities are exposed through well-defined APIs and GitOps workflows, enabling teams to provision and manage resources independently without waiting for central platform engineers.
- Team onboarding in minutes. One request creates a team's namespace, role bindings, quota, identity groups, bootstrapped repository, CI, and catalog entry, with an audit trail and team leads managing their own members.
- Developer portal and golden paths. A Backstage software catalog and versioned scaffolder templates that start a service with CI, observability, and infrastructure claims already wired in.
- Self-service infrastructure. Crossplane definitions and per-environment compositions, so a team declares a database in a claim next to its application code and gets the platform's defaults, tags, and guardrails.
- CI/CD as a platform service. Reusable pipeline workflows, blue-green and canary releases, and automated rollback on health signals, instead of a hand-written pipeline per team.
- Policy as code, audit first. Gatekeeper constraints that start in audit mode and move to enforcement one policy at a time, with the same rules checked in the pull request.
- Observability and SLOs. OpenTelemetry, Prometheus, and Grafana with SLOs as code, burn-rate alerts, and error budgets that inform deployment decisions.
- Cost visibility and right-sizing. Required cost labels, showback by team, autoscaling, and quota tiers per environment.
- Backups and drills. Scheduled cluster backups and restore drills that measure real recovery time, plus scoped chaos experiments.
- OIDC-federated pipelines. GitHub Actions / GitLab CI or other CI systems authenticate to AWS via OIDC - no long-lived AWS credentials sitting in CI after bootstrap, for infrastructure or application deploys.
- Handover. Runbooks, infrastructure as code, and pairing time with your team, so operating the platform does not depend on us.
Why we earn the right
Credentials behind the engineering - current, verified, and earned in production.
Both layers, one platform
GitOps from day one, not added on later
AWS foundation
NTC landing zone, day one
The AWS Organizations-first foundation - accounts, networking, identity - defined as Terraform/OpenTofu via NTC, not stood up by hand and documented after the fact.
App delivery
EKS through GitOps
Application deployment on EKS through a GitOps controller - ArgoCD or Flux - so the app layer ships through the same reviewed, automated path as the infrastructure beneath it.
Governance
OPA gates every change
Open Policy Agent validates infrastructure changes against organizational standards before they land - the same policy-as-code guardrail across the whole stack.
Pipeline security
OIDC-federated, no static keys
GitHub Actions federate to AWS via OIDC - no long-lived AWS credentials sitting in CI after bootstrap, for infrastructure and application pipelines alike.
One history
Infra and apps, one Git history
Landing zone and application manifests are reviewed through the same pull requests and the same CI - GitOps designed in from day one, not added onto an existing platform later.
The platform layers
Nine layers, one Git history
Each layer is defined as code and reviewed like any other change. You can start with the foundation and the first few layers and add the rest as teams need them.
- Access and identity.
- People sign in through your identity provider over OIDC, roles bind to groups instead of individuals, and pipelines deploy through a least-privilege role with short-lived credentials.
- Portal and team onboarding.
- A Backstage catalog and versioned golden-path templates, plus one onboarding request that creates a team's namespace, role bindings, quota, repository, CI, and catalog entry, with an audit trail.
- Self-service infrastructure.
- Crossplane definitions and per-environment compositions, so a team declares a database in a claim next to its application code and gets the platform's defaults, tags, and guardrails.
- Delivery as a service.
- Reusable pipeline workflows composed from a short config file, blue-green and canary releases through the GitOps controller, and automated rollback on objective health signals.
- Policy as code.
- OPA Gatekeeper constraints rolled out from audit to enforce, the same rules checked with conftest in the pull request, unit-tested Rego, and compliance visible in Prometheus.
- Observability and SLOs.
- A platform-owned OpenTelemetry Collector, Prometheus and Grafana with dashboards per audience, and SLOs written as code with burn-rate alerts that gate risky deploys.
- Cost and scale.
- Required cost labels on every workload, OpenCost showback by team, HPA and VPA right-sizing, Karpenter node pools with spot capacity, and quota tiers and budget guardrails per environment.
- Resilience.
- Scheduled cluster backups with restore drills that measure real recovery time, and scoped chaos experiments against services that have SLOs.
- Measured developer experience.
- DORA metrics, a developer survey, and a friction analysis of the delivery workflow, so the platform is judged by whether teams ship faster, not by what was installed.
Why day one matters
GitOps added onto an existing platform after the fact means two operating models: one for infrastructure, one for applications, with different review paths and different trust boundaries. Defining both layers as code from the start collapses that into a single reviewed history and a single deployment path.
How the layers are sequenced
- Foundation and identity. The landing zone, the cluster, and sign-in through your identity provider, so every later layer has an owner and an audit trail.
- Delivery. The GitOps controller, reusable pipeline workflows, and OIDC-federated CI, so the next layers ship through the path they are meant to use.
- Policy in audit mode. Constraints report violations on real workloads before anything is blocked, and the same rules run in the pull request.
- Observability and SLOs. Telemetry and reliability targets exist before teams depend on the platform, not after the first incident.
- Self-service. Team onboarding, golden paths, infrastructure claims, and the portal are added once there is something dependable behind them. A portal in front of an unfinished platform only hides the gaps.
- Enforcement, cost, and resilience. Policies move from audit to enforce one at a time, cost labels feed showback, and backup and chaos drills run against services that already have SLOs.
Developer experience is measured from the first step: delivery metrics and a short survey before the work begins, then again as each layer lands, so the platform is judged by what changes for the teams using it.
The Kubernetes and application-delivery layer of this offering is not yet backed by a published deployment write-up the way the AWS foundation is.
In partnership with Nuvibit
Delivered with Nuvibit AG, the team behind the Nuvibit Terraform Collection (NTC) - a real delivery partnership.
Frequently asked questions
Just need the AWS foundation, without the Kubernetes layer?
AWS cloud migration including EU
NTC landing zone with EU data residency and GDPR compliance built in from day one.
Ready to ship faster on AWS?
Tell us what you are building. We will map the fastest safe path to production and the platform to keep it there.