Infrastructure Agent

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.

Example tasks

• →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

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.

Example tasks

• →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

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.

Example tasks

• →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

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.

Example tasks

• →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

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.

Example tasks

• →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

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.

Example tasks

• →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

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.

Example tasks

• →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