What can agents upgrade?

Kubernetes versions and add-ons on EKS, database engine versions on RDS and Aurora, runtimes on Lambda and containers, and the infrastructure code that defines them.

Do agents change production directly?

No. Upgrades arrive as merge requests that roll out to staging first. Nothing reaches production without the approval you set.

How does it handle drift?

Agents compare what runs with what Terraform or CloudFormation says should run, then propose a change that brings the two back in line.

What if an upgrade goes wrong?

Every change ships with a rollback plan, and agents verify health after each step. If checks fail, the rollout stops and your team is paged with the evidence.

AWS Partner

SOC 2 Reports

Frontier Remediationfor Modernization and Upgrades

End-of-life runtimes, engine versions and IaC drift fixed at scale.

Connect your accounts and repositories. Agents find every end-of-life runtime, engine version and drifted resource, work out what each upgrade will break, and open changes ready to review and merge. The upgrade backlog shrinks every week instead of growing.

Book a Demo See how it works

EKS version scanupgrade plan ready

payments-prod on Kubernetes 1.29, end of standard support

Scope: 3 clusters, 41 workloads, 9 add-ons
Blockers: 2 manifests use a removed autoscaling API
Add-ons: CoreDNS and VPC CNI need newer versions
Evidence: API usage, add-on matrix, release notes
Change: Merge request: fix manifests, bump add-ons, upgrade staging first

Plan built in 6m. Waiting for platform team review

[The work behind every upgrade]

End-of-life dates keep coming.Upgrades keep slipping to next quarter.

01The manual work

Audit

Someone lists every runtime and engine version, reads release notes, hunts for breaking changes and estimates the risk. Then the roadmap pushes it back.

02The agent handoff

Change ready

Frontier agents map what is out of date, find what each upgrade breaks and open the code and config changes to fix it.

03Your engineers’ role

Merge

Set the order and the maintenance windows. Review each change and decide when it reaches production.

[Where CloudThinker fits]

Your stack stays.Agents work inside it.

01What is aging

Already in your estate

Amazon EKSCluster versions and deprecated APIs
Azure Kubernetes ServiceAKS version and support window
Google Kubernetes EngineGKE release channels
Amazon RDS and AuroraEngine versions near end of support
AWS LambdaRuntimes near end of life

Inventory from what you run

02Code and config

Your system of record

GitHub and GitLabManifests, charts and app code
TerraformCluster and database definitions
HelmChart versions in use
Jira and ServiceNowChange requests and approvals

Source of truth stays put

03Remediation

CloudThinker

Map the blast radiusEvery workload the upgrade touches
Prepare the changesPull requests per team and repo
Stage the rolloutLower environments first
VerifyHealth checked after each step

Changes go through review

04Response

Upgrades, not tickets

GitHubPull requests ready to merge
SlackWave status for owners
JiraProgress on the upgrade epic
Argo CDRollouts synced per cluster

Each wave runs on approval

Logos show common stacks. CloudThinker connects to each one through read-only access you approve.

[Example scenario]

Monday, 10:00. Kubernetes 1.29 support ends in 6 weeks.The upgrade has slipped twice already.

A 4-person platform team running 3 EKS clusters for 41 workloads. Product teams own the manifests. Extended support fees start when standard support ends.

10:00
Version scan flags itSignal
Weekly scan: payments-prod, payments-staging and tools run Kubernetes 1.29, 6 weeks from end of standard support.
10:02
Agent maps the blast radiusAgent
Reads every manifest and Helm chart, checks add-on versions and compares them with the 1.30 and 1.31 release notes.
10:06
Blockers foundAgent
2 manifests use a removed autoscaling API. CoreDNS and the VPC CNI need newer versions first.
10:08
Changes openedAgent
Merge requests for the 2 manifests to the owning teams, and an upgrade plan: add-ons, then staging, then production.
Wed 14:00
Platform lead approves stagingYour team
Reviews the plan, books the staging window and approves. The agent upgrades staging and runs the smoke tests.
Thu 22:00
Production upgradedAgent
Node groups rolled one at a time. All 41 workloads healthy. The ticket closes with the full change log attached.

#platform-upgrades4 messages

CloudThinker10:08
EKS 1.29 to 1.31 plan ready for 3 clusters. Blockers: 2 manifests on a removed API (MRs !311, !312 sent to owners), CoreDNS and VPC CNI bumps. Order: add-ons, staging, production.
Platform leadWed 14:00
Both manifest MRs merged. Staging approved for now.
CloudThinkerWed 14:52
Staging on 1.31. Smoke tests pass, 0 restarts. Production window proposed for Thursday 22:00.
CloudThinkerThu 23:10
payments-prod on 1.31. 41 of 41 workloads healthy. PLAT-482 closed with the change log.

from scan to production in this example: 4 days
breaking changes caught before staging: 2
release notes read by hand: 0

An illustrative example. Team, systems and times are representative, not a specific customer.

[Frontier remediation agents]

Every outdated component found.Every upgrade planned before it starts.

Agents keep an inventory of what runs where, so an end-of-life date turns into a reviewed change well before the deadline, and drift gets fixed in code instead of in the console.

Inventory every version: Runtimes, Kubernetes versions, database engines and add-ons listed per account, with their support dates.
Find what breaks: Removed APIs, deprecated flags and incompatible add-ons found before the upgrade, not during it.
Fix drift in code: Resources changed by hand traced back to Terraform or CloudFormation, with a change that brings them in line.
Open the change: Upgrades delivered as merge requests that roll out to staging first, at the approval level you set.

[What changes]

Same team. Same tools.Far less of the work by hand.

Moment	Today	With frontier agents
Knowing what is outdated	A spreadsheet updated once a year	A live inventory with support dates
Breaking changes	Found during the upgrade	Found and fixed before it starts
Infrastructure drift	Discovered in the next outage	Traced to code and corrected
Doing the upgrade	A project nobody has time for	A merge request ready to review
The backlog	Grows every quarter	Shrinks every week

[Integrations]

Connects to the rest of your stack.Read-only to start.

Amazon EKS
Amazon RDS
Amazon Aurora
AWS Lambda
Amazon ECS
AWS CloudFormation
Terraform
GitHub
GitLab
Jira
ServiceNow
Slack

[Adoption path]

One pilot.Then company-wide.

The rollout follows the four phases of the AWS Cloud Adoption Framework, so it fits the plan your cloud team already runs.

01Envision
Pick one upgrade
Choose the deadline that worries you most. Connect read-only and let agents build the plan and the changes.
02Align
Agree the rollout rules
Decide the order of environments, the maintenance windows and who approves each change.
03Launch
Roll out account by account
Add each team’s accounts and repositories on the same policies, plan format and audit trail.
04Scale
Make it the default
New end-of-life dates turn into planned changes automatically, long before they become urgent.

[Customer proof]

NextPay.Results on the record.

NextPay upgraded its production EKS clusters with zero downtime and kept its payment-critical apps running throughout.

Read the case study

clusters upgraded with zero downtime: 3
cost reduction on RDS replicas: 50%

[AWS guidance]

Built the way AWS says to run it.Reviews start from a known reference.

[Trust and control]

Agents do the work.Your team keeps control.

You approve every change: Agents propose. Nothing touches production until someone on your team says yes, and you set that rule per system.
Every action on the record: Each step is logged, attributed and reversible, ready for your auditors.
Certified for enterprise: SOC 2 Type II and ISO 42001, with reports in our trust center.
Runs where you need it: In our cloud, through AWS Marketplace, or inside your own account.

[Questions]

What teams askbefore they start.

What can agents upgrade?: Kubernetes versions and add-ons on EKS, database engine versions on RDS and Aurora, runtimes on Lambda and containers, and the infrastructure code that defines them.
Do agents change production directly?: No. Upgrades arrive as merge requests that roll out to staging first. Nothing reaches production without the approval you set.
How does it handle drift?: Agents compare what runs with what Terraform or CloudFormation says should run, then propose a change that brings the two back in line.
What if an upgrade goes wrong?: Every change ships with a rollback plan, and agents verify health after each step. If checks fail, the rollout stops and your team is paged with the evidence.

[Go deeper]