DevOps on autopilot

TL;DR — Bring a Git repo and a Dockerfile. The Kuberly autopilot provisions EKS, ECS, Lambda, or Bedrock in your own AWS account, ships OpenTofu + Terragrunt into your repo, and reviews every PR with an MCP-powered AI agent. Live in hours, not weeks — and you own every line of IaC.

The pitch in one paragraph

Bring a Git repo and a Dockerfile. The Kuberly autopilot deploys it to your own AWS account as EKS, ECS, Lambda, or Bedrock and provisions every layer around it: VPC, DNS, secrets, observability, GitOps. OpenTofu + Terragrunt commit straight to your Git provider — GitHub or Bitbucket today, GitLab coming. GCP and Azure runtimes are in beta. Live in hours, not weeks.

What "autopilot" actually means

Three distinct surfaces, all grounded in your real cluster state:

1. Dashboard chat — operational answers from your live cluster. Loki, Prometheus, pod events, all queried directly. Answers ship with the raw data they're built from.
2. AI in your IDE — Cursor, Claude Code, Copilot, OpenCode. Open the IaC repo, ask for a change, the autopilot comments the full plan output on the PR and auto-applies on merge.
3. In-repo agent toolkit — two MCP servers. One exposes the IaC repo's blast radius and dependencies. One is scoped to your monitoring stack (Loki, Prometheus, Grafana) for live troubleshooting from any MCP client. The architecture under the hood is described in Teaching an Agent to Think in Graphs.

The PR flow

01  Developer       — edits the IaC repo from Cursor/Claude Code, opens a PR
02  kuberly-ci      — terragrunt plan succeeded, 12 changes; diff posted as a comment
03  kuberly-ai      — risk: low. No production impact. Recommendation: safe to merge
04  Reviewer        — reads the AI summary and the raw plan, approves
05  kuberly-ci      — applied on merge, output posted back to the commit as proof

You set the policy: auto-apply on merge, or require a human approval first. Audit trail is the PR thread.

Humans in the loop, AI doing the work

Kuberly isn't only the autopilot. It's a managed DevOps service powered by AI. We supervise. The autopilot operates 24/7. Your team self-serves in the dashboard. The result: one Kuberly DevOps engineer comfortably handles tens of customers across hundreds of clusters because the autopilot handles the work that used to need a person. For why we structure this as one orchestrator with a fleet of short-lived workers, see When one agent isn't enough.

What stays yours

• The cloud account
• The Git repo
• The OpenTofu + Terragrunt code
• The Kubernetes secrets in AWS Secrets Manager / GCP Secret Manager / Azure Key Vault
• The IAM role (you can revoke our access at any time — we keep nothing on our side)

If you stop using Kuberly tomorrow, the cluster keeps running and the repo stays yours. No migration project. That's the eject path — it's real, it's in the contract, and we wrote about it at length in You own the IaC. You own the infra.

---

Further reading

• GitOps principles — the OpenGitOps working-group spec.
• OpenTofu manifesto — why we ship OpenTofu, not Terraform.
• Terragrunt features — DRY backends, dependency graphs, run-all.
• Model Context Protocol — the open standard the autopilot speaks.
• AWS EKS best practices — the baseline we ship by default.
• You own the IaC. You own the infra — the eject path, in detail.
• Production AWS in hours, not weeks — the onboarding timeline.

Want the autopilot working on your AWS today? Talk to us.