Product overview
What we manage, what your team keeps, and where the boundary sits.
The managed EKS platform covers Kubernetes setup, upgrades, guardrails, and shared services. Your team keeps the application work and the AWS account.
We run
Cluster baseline and add-ons
Access model and guardrails
Upgrades and platform maintenance
Runbooks and operational checks
You run
Application code and releases
Service-level objectives
Runtime behaviour and incidents
Product-specific requirements
What we manage
- Provision and maintain a private-by-default EKS baseline in the customer AWS account.
- Own platform lifecycle, upgrades, core add-ons, policy baselines, and access controls.
- Run the platform with validation outputs, runbooks, and a defined operating model.
What stays with your team
- Own the customer application, release logic, or application on-call.
- Turn every environment into a bespoke platform engineering project.
- Leave ownership unclear once the cluster is live.
Included baseline
More than cluster provisioning.
The starting point includes the EKS landing zone, the safety controls around it, and the shared services needed for the first workload.
01
Platform baseline
Private control plane, managed node groups, networking, and the core access model.
02
Guardrails
Policy baselines, delivery checks, and operating rules that make routine change easier to trust.
03
Shared services
Ingress, monitoring, logging, and the add-ons needed for a usable first workload path.
04
Operational evidence
Validation outputs, runbooks, and a known path for upgrades, access, and recovery.
Responsibility model
Responsibility has to be settled before go-live.
Platform lifecycle remains with us. Application runtime, release logic, and service behaviour remain with your team.
Platform team
We own the platform.
Application team
You own the application.
Good fit
- AWS teams that need Kubernetes outcomes without building a large internal platform function
- Engineering organisations that want clearer ownership boundaries
- Small product teams that need safer upgrades without building the whole platform function
Not a fit
- Teams expecting unlimited bespoke platform feature work
- Organisations that already run a mature internal platform team
- Buyers expecting a provider to own their application operations
How onboarding works
See the discovery, setup, workload, and handover path.
Security baseline
Review private access, policy guardrails, and evidence.
Discovery path
Use the discovery call to confirm fit, ownership boundaries, and whether a pilot is worth scoping.
Evidence pack
Inspect the responsibility matrix and pilot completion criteria.
Next step
Start with the boundary, then decide whether a pilot makes sense.
Bring the ownership split you need and the first workloads you want to onboard. We will use the call to confirm fit before scoping delivery.