Infrastructure Agent

Your senior DevOps engineer — from code to cloud-live in one session

What it does

Reads the existing codebase first — finds the framework, port, health check endpoint, and every env var the app needs. Then takes real action: creates the Fly.io app, sets secrets, generates production fly.toml, Dockerfile, and a GitHub Actions workflow that deploys on every push to main. For teams moving to Kubernetes, generates the full manifest suite (Deployment, Service, Ingress, HPA, PDB). For AWS or GCP, generates Terraform modules with VPC, ECS/Cloud Run, IAM, and load balancer. Every config is committed to GitHub as a PR so your team reviews before it goes live.

What it can do

Codebase Discovery Before Any Config

Reads the repository structure, entry point, framework, and all environment variable references before writing a single config file. Identifies the port the server binds to, whether a health check endpoint exists (and creates one if not), and every secret the app needs. Nothing is guessed — every config value is derived from what is actually in the code.

“Read our codebase and tell me exactly what Fly.io will need before we deploy”
“Audit our current Dockerfile and fly.toml — what is wrong and what needs fixing?”
“Identify all environment variables our service needs so I can set them up before deploying”

Fly.io End-to-End Deployment

Creates the Fly.io app, sets all secrets via the Fly API, generates a production fly.toml (correct internal_port, health check, auto-stop to save cost, TLS forced), writes the Dockerfile and .dockerignore, wires a GitHub Actions CI/CD workflow that deploys on every push to main, then deploys the first machine and confirms the health check passes. Hands back the live URL and a summary of every secret that was set.

“Deploy our Fastify API to Fly.io from scratch — create the app, write all configs, deploy, and confirm it is live”
“Our Fly.io deploy keeps failing — read the logs, find what is broken, fix the config, and redeploy”
“Set up auto-deploy on Fly.io so every push to main goes live automatically”

Multi-Service Fly.io Setup

When an app has multiple services — API, background worker, Postgres, Redis — sets each up as a separate Fly.io app with private networking. Services communicate via Fly's internal DNS (<app-name>.internal) so they are never exposed to the public internet. Generates a separate fly.toml per service, organized into infra/fly/ in the repo, with one GitHub Actions workflow per service.

“Set up our API + Postgres + Redis stack on Fly.io with proper private networking between them”
“Add a background job worker as a separate Fly.io app that connects to our existing database app”
“Migrate our 4-service architecture from Railway to Fly.io — set up all services with internal networking”

Kubernetes Manifest Suite

Generates a complete, production-correct Kubernetes manifest suite committed to k8s/ in the repo: Deployment (with resource limits, liveness/readiness probes, non-root securityContext), Service, Ingress with TLS via cert-manager, ConfigMap for non-secret config, Secret stub with placeholder values, HorizontalPodAutoscaler (min 2, max 10, target CPU 70%), PodDisruptionBudget (minAvailable: 1), and a Kustomize kustomization.yaml tying it all together. PR description includes the exact kubectl apply steps.

“Generate a full Kubernetes manifest suite for our Node.js API — we are deploying to GKE next month”
“We are migrating from Heroku to EKS — write the K8s manifests and Ingress config for our service”
“Add an HPA and PodDisruptionBudget to our existing deployment so we survive cluster upgrades”

Terraform IaC for AWS or GCP

Generates production-ready Terraform modules: for AWS — VPC, ECS cluster and task definition, ECR repository, Application Load Balancer with target groups, IAM task execution role with least-privilege policies, and a GitHub Actions pipeline with plan-on-PR and apply-on-merge. For GCP — Cloud Run service, Cloud SQL, IAM bindings, and artifact registry. Committed as a PR with step-by-step apply instructions and the IAM permissions required for the CI service account.

“Write Terraform for an AWS ECS deployment of our Docker service — VPC, ECS, ECR, ALB, IAM, and CI/CD”
“Generate GCP Terraform for our API: Cloud Run, Cloud SQL Postgres, and artifact registry”
“Create a Terraform module that can be reused across staging and production environments”

Docker Compose for Dev/Prod Parity

Generates a docker-compose.yml that mirrors the production topology exactly — same service names, same environment variable names, same port mappings as fly.toml or K8s manifests. Adds a separate docker-compose.override.yml for local dev with volume mounts for hot reload and debug flags. Includes a Makefile with dev, build, test, docker-up, and docker-down targets so any engineer can get the full stack running with one command.

“Create a docker-compose.yml that mirrors our Fly.io production setup so local dev matches production”
“Our local setup uses a different database name than production and it keeps causing bugs — fix the docker-compose to match”
“Write a Makefile that wraps docker-compose so any engineer can run the full stack with make dev”

CI/CD Pipeline Wiring

Generates GitHub Actions workflows that build the Docker image, push to the appropriate registry (GHCR, ECR, GCR, or Fly's own registry), and deploy — on push to main. For Fly.io: uses flyctl with the FLY_API_TOKEN secret. For ECS: uses aws-actions/amazon-ecs-deploy-task-definition. For GKE: uses google-github-actions/deploy-cloudrun. PR description lists the exact repository secrets that need to be added to GitHub before the workflow will run.

“Wire up a GitHub Actions CI/CD pipeline that deploys our service to Fly.io on every push to main”
“Our current CI builds the Docker image but does not deploy it — add the deploy step for ECS”
“Set up a pipeline that deploys to staging on push to develop and to production on push to main”

Good for / not for

Great for

First Fly.io deployment — skip the learning curve entirely
Multi-service setups that need private networking between services
Teams moving from PaaS (Railway, Heroku, Render) to real cloud infrastructure
Generating K8s manifests for a GKE or EKS migration
Writing Terraform for AWS or GCP when the team has no IaC experience
Creating local dev environments that actually match production
Deploying the output of the Architect or Code Generator agents to production

Not the right fit for

Railway deployments (that is the Backend Agent)
Database provisioning and migrations (that is the Database Agent)
Creating cloud accounts, IAM users, or billing setup — needs a human admin
Kubernetes cluster provisioning (EKS/GKE setup) — agent writes the app manifests, not the cluster itself

Example tasks

“Read our Fastify API repo and deploy it to Fly.io — create the app, write fly.toml, set secrets, deploy, and confirm the health check passes”
“We have 3 services (API, Postgres, Redis) — set them up on Fly.io with private networking so they can talk to each other securely”
“Generate a complete Kubernetes manifest suite for our Node.js API: Deployment, Service, Ingress with TLS, HPA, PDB, ConfigMap, and Secret stubs”
“Write Terraform for an AWS ECS deployment: VPC, ECS cluster + task definition, ECR repo, ALB, IAM roles, and a GitHub Actions CI/CD pipeline”
“Create a docker-compose.yml that mirrors our Fly.io production setup exactly so local dev has the same topology”