About
Built for teams that need the platform handled, not hidden.
Percy’s Platforms exists for teams that need Kubernetes in AWS without spending the next quarter building the platform around it.
Boring Kubernetes
Prefer platform behaviour your team can understand over a stack that only looks strong in a diagram.
Upgrade-first thinking
Design around safe change and repeatable upgrades, not just the initial build.
Why this exists
Kubernetes should not turn into a second product backlog.
Many teams need the control and reliability benefits of Kubernetes, but not the drag of building the whole operating model themselves.
If the platform only works because a few people remember the right sequence, it becomes another dependency. The service is built to make the common paths visible and repeatable.
Principles
Plain engineering choices over inflated platform promises.
01
Boring Kubernetes
Prefer platform behaviour your team can understand over a stack that only looks strong in a diagram.
02
Upgrade-first thinking
Design around safe change and repeatable upgrades, not just the initial build.
03
Clear boundaries
Responsibility clarity is an engineering control, not a slogan.
04
Customer-account-native control
The customer keeps AWS account ownership, access boundaries, and data control.
AWS Founders evidence
Specific enough for review, careful enough not to overclaim.
The site stays narrow on purpose: an AWS-native managed Kubernetes service, a pilot-first path, documented responsibility boundaries, and no unsupported claims.
01
AWS-native product
The service is built for customer AWS accounts, private-by-default EKS, managed node groups, IAM-aware access, and separate AWS billing.
02
Pilot-stage path
The public path is discovery, fit confirmation, scoped pilot, onboarding, and ongoing service rather than a vague self-serve promise.
03
Operator evidence
The offer is backed by runbooks, validation artifacts, security baselines, and a documented platform/application split.
04
Honest exclusions
The site does not claim customer traction, certifications, funding, application ownership, or unlimited custom platform work.
Why not build this internally right now?
Building internally can be right later. It is not always right first.
The decision is about timing. If the platform path is still being invented, the real cost is senior engineering attention.
Build it now
Use the service
Build it now
Early momentum goes into bootstrap choices, ownership debates, and the first fragile path through the platform.Use the service
The first phase can focus on access, handover, and moving the first workload onto a known path.Build it now
Senior engineers split attention between product delivery and platform decisions that will keep returning.Use the service
Recurring platform work has a service owner, so your engineers stay closer to customer-facing delivery.Build it now
Upgrade, access, and recovery paths can stay theoretical until a change window exposes the gaps.Use the service
Upgrade handling, validation, and handover are part of the operating model from the start.Build it now
Incidents and access failures become coordination work when ownership is still settling.Use the service
The platform/application split is agreed early, so support questions have a clear route.Next step
If the model fits how your team wants to work, start with discovery.
Use the first call to test the workload mix, ownership split, and level of platform help you actually need.