Elliot is an AI DevOps agent by Dcode. Give it a ticket in Jira, monday.com or GitHub, from a full AWS landing zone to a 2 a.m. alarm. It reads your code and your cloud, does the work and opens a pull request. Your team merges it, or Elliot does in Autonomous mode.
Build our AWS landing zone: EKS in a private VPC, reached only over AWS Client VPN
Opened #412 for the network, EKS and Client VPN. The security baseline follows in #413.
landing-zone: private VPC, EKS and Client VPN #412
network/vpc/main.tf+74eks/cluster/main.tf+96eks/karpenter/main.tf+48vpn/client-vpn/main.tf+58iam/vpn-sso/main.tf+31README.md+22 −3networkeks-clustereks-karpenteraws-vpnNo ticket? Your team can also email elliot@elliot.services or message Elliot in Slack.
Elliot works like a DevOps engineer on your team. You give it a ticket, it does the work, and you stay the one who decides.
Write what you need in Jira, monday.com or GitHub, like you would for a teammate. Then assign the ticket to Elliot, or add the Elliot label.
It clones your infrastructure repo and looks at your AWS account with read-only access. Then it decides: is this a change to make, or a problem to investigate?
It makes the change on a new branch, checks it and opens a pull request, then comments on the ticket. You review and merge, or let Elliot merge in Autonomous mode.
A data center move is a project, not a ticket. Elliot plans it, Dcode helps you fund it, and Elliot builds it, one pull request at a time.
Upload the RVTools export of your VMware servers and give Elliot a ticket: plan our move to AWS.
Plan our move from the Frankfurt data center to AWS
rvtools-export.xlsxElliot decides what happens to each server, groups them into waves, prices the AWS run cost and lists the risks. Dcode turns the plan into a SOW with you.
Migration plan
Dcode is an authorized AWS reseller. We use the SOW to apply for AWS funding programs like MAP, and work with your AWS account team. Credits land in your account as the project meets its milestones.
AWS MAP
Migration Acceleration Program
Credits from $25K to $250K+25% of eligible spend, if you qualify
AWS funding with DcodeGive Elliot the SOW. It builds each phase as pull requests: the landing zone first, then the AWS targets for every wave. You review each one.
From a new AWS foundation to the small ticket nobody has time for this week.
Accounts, a private VPC, EKS, Client VPN with single sign-on, and the security baseline. Elliot builds it with Dcode Autopilot, our own Terraform module library, and runs terraform validate, tflint and the Autopilot checks before every pull request.
Example ticket: “Build our AWS landing zone: EKS in a private VPC, reached only over Client VPN”
Upload the RVTools export of your VMware servers. Elliot picks a path for every server, plans the waves, prices the AWS run cost and lists the risks. Dcode turns the plan into a SOW and uses it to apply for AWS funding.
Example ticket: “Plan our move from the data center to AWS”
See the whole projectInstall and upgrade kubeadm, RKE2 and k3s clusters with Ansible, as pull requests in your Ansible repo. Before an upgrade, Elliot checks etcd, versions and the drain order. It finds certificates before they expire and opens the renewal. It reaches your servers through a small runner in your network, or through your AWX.
Example ticket: “Our cluster certificates expire next month. Renew them.”
Elliot checks if a cluster is ready and plans the upgrade one version at a time. The pull request is the runbook. After you apply it, Elliot checks the cluster.
Example ticket: “Upgrade the staging EKS cluster to the next version”
When one service can’t reach another, or a role gets AccessDenied: security groups, routes, DNS, flow logs, CloudTrail, SCPs and IAM policy simulation.
Example ticket: “The CI role gets AccessDenied when it pushes to ECR”
Everyday changes in the style your repos already use, checked with terraform validate, tflint, actionlint and helm lint.
Example ticket: “Add a versioned S3 bucket for the reports service”
Elliot starts the investigation the moment the alarm fires. When your on-call engineer opens the alert, the root cause and the fix are already in the thread.
Investigating alerts is off until you turn it on, and you set a daily limit.
critical checkout-api: 5xx errors above 5%
Elliot
Root cause: the 02:05 deploy (#884) moved the load balancer health check to /healthz, but the app answers on /health.
Evidence: all 6 targets fail the health check with 404. AWS’s diagnostic runbook shows the load balancer controller itself is fine.
Fix: set the path back. Pull request #527 is ready for review. Confidence: high.
Elliot can read a lot and change very little. You decide how far it goes, one repo at a time.
Elliot does the work. Your team decides what ships.
Every repo starts here. Elliot never merges its own pull requests in this mode.
Elliot ships the change end to end, inside limits you set.
Production needs one human approval, unless an owner turns that off for the repo. After a failed deploy, the repo pauses until a person looks. Elliot can also review your team’s pull requests.
Changes reach your code only as pull requests that pass your CI, in Autonomous mode too. Elliot never runs terraform apply and never reads your Terraform state.
Elliot’s role in your AWS account can read, but it can’t change resources, read secrets or decrypt data. Your CI deploys, never Elliot.
For your own servers, a small runner inside your network connects out to Elliot. No inbound ports. It runs only read-only checks.
Elliot can open pull requests only in the repos you select. Autonomous mode is off until you turn it on for a repo.
Each ticket runs in its own short-lived, isolated runner, with short-lived credentials for that job only.
Every action is in the audit log. Un-assign Elliot and the job stops. Anyone on your team can pause Autonomous mode.
Talk to Dcode to set up Elliot for your team, or to plan a bigger project together. Already have an account? Sign in to connect your tools, repos and AWS accounts.