Detect
Combine billing, utilization, tags, and account context into a defensible finding.
AWS cost remediation for engineering teams
OpsTiller will connect cloud-cost findings to their owners, route safe approvals, and prepare narrow Terraform pull requests—so savings can move from backlog to production.
A workflow, not another list
Explore how a future OpsTiller workflow could turn an unused load balancer signal into an evidence-backed, owner-approved change.
Evidence
Thirty days with no requests or healthy targets support this finding.
The missing middle
Most recommendations stop exactly where engineering work begins: proving the signal, finding the owner, changing code, managing risk, and checking the result.
Today’s backlog
With OpsTiller
How it would work
A deliberate path from observation to action, built to fit existing engineering controls.
Combine billing, utilization, tags, and account context into a defensible finding.
Recheck evidence and match the live resource to its owner and Terraform source.
Route an approval and prepare a narrow draft pull request—never merge or apply it.
Compare the accepted opportunity with observed billing data after deployment.
Initial catalog
Correlate connections, CPU, environment, and ownership before proposing a reviewed change.
Identify aging objects and draft a scoped Terraform lifecycle policy for review.
Trace detached volumes to owners, preserve recoverability, and route an approval.
Prompt to policy
Natural language could become a validated, versioned workflow—not arbitrary production code.
scope:
environments: [non-production]
excludeTags:
cost-remediation: protected
detector:
type: idle_resource
lookbackDays: 30
thresholds:
requestCountMaximum: 0
healthyTargetCount: 0
action: terraform_pull_request
approval:
required: trueSafety is the product
OpsTiller starts with constrained access and explicit control—not an autonomous agent with production credentials.
Discovery would begin with temporary credentials from a customer-deployed, read-only AWS role.
Every proposed mutation would bind an approver to a specific preview and immutable workflow version.
Owned resources would change through draft pull requests. OpsTiller would never merge or apply them.
Evidence would be revalidated immediately before a proposed action proceeds.
Direct API actions, if introduced, would use narrow adapters with declared permissions and preconditions.
Findings, decisions, workflow versions, and verification status would retain a clear history.
A note from the founder
Cloud teams rarely need one more dashboard telling them what they already suspect. They need a trustworthy way to move from opportunity to owned, reviewed work.
We’re speaking with platform and infrastructure leaders about the last optimization they tried to ship: where it stalled, who had to approve it, and what proof made the change safe.
Book a 25-minute conversation →FAQ
Not yet. OpsTiller is in product discovery. We’re inviting a small group of engineering teams to shape a read-only alpha and validate its remediation workflows.
Not autonomously. Terraform-owned resources would be changed through draft pull requests, with explicit human approval and your existing CI controls.
The proposed alpha would use a customer-deployed read-only AWS role and a GitHub App. Remediation permissions would be separate and optional later.
The product is being designed around the work after detection: evidence, ownership, approvals, reviewable changes, and verification.
AWS-heavy SaaS teams using GitHub and Terraform, especially platform, infrastructure, DevOps, and FinOps leaders responsible for cloud outcomes.
Early access
Join the waitlist for product updates and an invitation to the read-only alpha.