From repository
to production AWS.
AWS-ify reads your repository and generates reviewed, production-grade infrastructure. Templates execute. You approve. AWS stays yours.
No credit card. Connect a repo in 90 seconds.
Built on rigorous primitives
The problem
Shipping to AWS is still painful.
Console clicking
Hours lost to AWS forms: VPCs, IAM roles, target groups. Each one a chance to misconfigure production.
AI that hallucinates infra
Generic LLM output ships invalid Terraform or made-up resource names. Cool demo. Doesn't deploy.
DevOps as a bottleneck
Every new service waits for a platform engineer. The repo is ready. The infrastructure isn't.
Drift you can't see
What's in git stops matching what's in AWS. Six months in, nobody knows what's actually running.
The solution
A control plane between your repo and AWS.
Anthropic recommends. AWS-ify validates against a strict schema. Templates we own execute. You stay in the loop the whole way.
Inference, scoped.
LLMs propose plans inside a schema. No free-form AWS calls, ever.
Templates, owned.
Pulumi modules we audited generate the real resources, least-privilege by default.
Account, yours.
AWS-ify never holds your AWS credentials. Plans execute via an assumed role you control.
How it works
Four steps from repository to live service.
Connect
Install the GitHub App. Add an AWS role via CloudFormation.
$ gh app install aws-ify
$ aws cloudformation create-stack \
--stack-name aws-ify-roleScan
AWS-ify reads your repo: runtime, framework, scripts, port, env vars, and dependencies.
detected: next.js runtime: node env: required values found db: marked as planned
Plan
An AI plan is validated against a strict schema and rendered into Pulumi templates.
plan generated ecr.repository ecs.service alb.listener cloudwatch.logGroup
Approve & ship
Review the diff. One click. AWS-ify provisions the stack and returns the service URL.
awaiting approval approve plan deploy to fargate return live url
Generated output
Real infrastructure, not pseudocode.
Every plan produces a Dockerfile, a deployment workflow, and a Pulumi stack, auditable and versioned in your repo.
import * as awsx from "@pulumi/awsx";
import * as aws from "@pulumi/aws";
export const cluster = new aws.ecs.Cluster("api-cluster");
export const service = new awsx.ecs.FargateService("api", {
cluster: cluster.arn,
desiredCount: 2,
taskDefinitionArgs: {
container: {
image: image.imageUri,
cpu: 512,
memory: 1024,
portMappings: [{ containerPort: 3000 }],
environment: env,
},
},
});architecture
us-east-1resources rendered
5- ECR repositoryimmutable image tags
- ECS cluster + serviceFargate
- Application load balancerpublic HTTP
- IAM task rolescoped to ECR + logs
- CloudWatch log groupapplication logs
name: deploy
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
permissions:
id-token: write
contents: read
steps:
- uses: actions/checkout@v4
- uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: ${{ secrets.AWS_DEPLOY_ROLE }}
- run: aws-ify apply --plan plan-042Before you spend a dollar
Cost estimation, line by line.
AWS-ify simulates a month of usage from the plan and shows you exactly where the money goes.
monthly estimate / us-east-1
A conservative estimate for one small ECS Fargate service with ALB, ECR, and logs.
No resources exist before you click approve. Plans are dry-run by default.
The first production path is intentionally limited to ECS Fargate.
Security & reliability
Built for teams that can't afford mistakes.
We never touch your credentials.
AWS access is via an assumed role in your account, scoped to the resources templates own.
AI proposes. Templates execute.
Schema validation rejects any resource outside the audited Pulumi template set.
Everything lives in your repo.
Infrastructure is committed code: pull requests, reviews, blame, rollback. Like every other artifact you own.
Drift detection, by default.
Hourly checks compare real AWS state against the plan. Surprises get surfaced before they bite.
FAQ
Questions, answered.
No. You create a CloudFormation role scoped to the resources our templates manage. We don't get global IAM, billing, or org-level access.
Node.js backends and Next.js apps that build to a Docker image, deployed to ECS Fargate behind an ALB. PostgreSQL detection is shown in the plan, but RDS provisioning is not part of the first MVP path.
The MVP shows generated Dockerfile, GitHub Actions, and Pulumi plan artifacts for review. Committing generated infra back to the repo comes after the first deployment path is stable.
Those are toolkits. AWS-ify is the layer above them: it infers your stack, generates the code, validates against a strict schema, and gates execution behind approval. Pulumi is what runs underneath.
Claude proposes a structured plan. We validate it against a schema and reject anything outside the audited template set. The LLM never writes raw AWS calls.
The worker records deployment events and marks the deployment failed with the reason. Full rollback automation is planned after the first ECS Fargate path is proven.
ready when you are
The console was never the point.
Ship infrastructure the same way you ship code. Connect a repository and have your first reviewed deployment plan in under five minutes.