Product — InfraHouse

// what you get

InfraHouse gives startups selling to enterprise a production-ready AWS foundation. Bring a Dockerfile; about 30 minutes later we hand back a running app on ECS with GitHub-managed CI/CD, infrastructure you own from day one, and a clean graduation path into your own AWS Organization — no rebuild.

This page is what that actually looks like.

// day one

What lands in your hands.

A dedicated AWS account inside the InfraHouse AWS Organization (Nursery).
A containerized service running on ECS Fargate, behind an ALB with ACM TLS.
A *.infrahouse.app URL pointing at your service.
ECR for your container images.
CloudTrail enabled across the account with the right retention.
Baseline CloudWatch alarms.
A GitHub Actions CI/CD pipeline deploying on push.
A runbook describing how to operate, deploy, and roll back.
About 69 production-grade Terraform modules under github.com/infrahouse, used to build all of the above.

All of it is Terraform-managed in repositories you own from minute one.

environments/production/main.tf

# provisioned in ~30 min, owned by you from day one module "ecs_service" { source = "infrahouse/ecs-service/aws" version = "3.12.1" # ECS Fargate · ALB · ACM · ECR wired up } module "cloudtrail" { source = "infrahouse/cloudtrail/aws" version = "1.4.0" # 365-day retention, audit-ready }

apply complete 69 modules · 0 drift

// shipping a change

A real PR, end to end.

Here is a real production PR — #21 in our own aws-service-infrahouse-app repo. It is small, ordinary, and merged. The workflow is the same on customer repos.

PR #21 context — a merged pull request in aws-service-infrahouse-app — A pull request, like any other. Authored by Aleks, reviewed and merged into main.

PR #21 diff — plain Terraform IAM policy — The change itself. Adding a scoped IAM policy that lets GitHub Actions deploy ECS services in production. Plain Terraform; you can review it like application code.

PR #21 ih-plan bot comment — Terraform plan posted on the PR — github-actions posts the Terraform plan back on the PR, with the state file it ran against and every affected resource broken out by action. No surprises at apply time.

PR #21 approval — code-owner review required before merge — A review from a code owner is required before merge. Merge deploys. The same Git flow your engineers already use, with the infrastructure plan posted alongside the diff.

Every Terraform change to your stack flows through a PR like this one.

// the repos

Opinionated structure, predictable across customers.

Two repos do most of the work. github-control orchestrates the others; service repos like aws-service-infrahouse-app follow a predictable shape so any one of them looks like all of them.

github-control modules directory — four pattern modules — github-control is the meta-repo. The modules directory holds the patterns we maintain: local-repo, plain-repo, repo-template, and service-repo. Each is a real Terraform module, versioned and used across every InfraHouse customer.

aws-service-infrahouse-app repo shape — environments and modules directories — aws-service-infrahouse-app is one of our own service repos — yes, infrahouse.com runs on InfraHouse. Every service repo has the same shape: environments/production, environments/sandbox, modules/, and a Makefile. Predictable across repos means you (or a future hire) can read any one of them without an orientation call.

Opinionated structure is the product. It is also what makes the workflow above repeatable.

// ownership

Nothing lives inside an InfraHouse-only system.

Your GitHub organization, with every repo, every Terraform module, every workflow file.
Your AWS account — operated inside our Organization during Nursery, transferred to yours at graduation, with no rebuild.
The Terraform state, the IAM roles, the secrets, and the runbook.
The right to read, fork, copy, or walk away with any of it at any time.

If you hire a DevOps engineer next year, they inherit a stack that looks like every other competent AWS setup. No retraining on a proprietary system, because there is no proprietary system.

// from repo to production

About 30 minutes to first deploy. Same day, you have everything.

// beyond v1

More than a single service? That is consulting.

v1 is intentionally narrow — one containerized service, one environment, deployed with the patterns above. It ships fast and audit-clean because the boundary is tight. Anything wider is a scoped consulting engagement.

If you need multiple environments per service, custom domains, managed databases beyond MySQL, background workers, or multi-service deployments under one account, those are the senior-engineer consulting engagements — different shape, different price, same engineer.

See the consulting offering →

// graduation

$0 rebuild when you move.

When you are ready, the AWS account you have been running on transfers from our AWS Organization into yours. Same account. Same Terraform. Same GitHub workflows. The only thing that changes is the parent Organization and the billing relationship.

Graduation diagram: account moves from InfraHouse Nursery to your own AWS Organization — Today — Nursery — you run inside our AWS Organization, AWS bills us, we bill you with no markup. After Graduation, your account moves into your own Organization, AWS bills you directly. The stack does not change.

No contract traps you in Nursery. Graduation is a button push, not a project.

// signal from customers

Engineers who've shipped with us.

postgres at scale

"They surfaced issues we hadn't fully seen and validated instincts our engineers already had. We left with better observability and a concrete roadmap to make our database layer more resilient."

VP

Vivek Patel

CTO · Check Technologies

iso 27001

"InfraHouse let us move blazingly fast by automating provisioning with Terraform. Their leadership integrating security best practices was pivotal to our ISO 27001 certification."

SZ

Shuhao Zhang

CEO · Tiny Fish

reliability

"Their expertise and clear recommendations helped us refine our approach and move forward with confidence. Efficient, insightful, and exactly what we needed."

EM

Engineering Manager

Airtable

// who delivers

You deal directly with Aleks.

Aleks Kuzminskyi designs and operates your stack — the same engineer who built the patterns in the screenshots above, ships the ih-plan bot, and runs the TinyFish environment. You deal directly with him, not a ticket queue. Before InfraHouse, Aleks ran database infrastructure at Dropbox, Box, and Pinterest.

linkedin.com/in/akuzminsky →

// questions

Questions we get on every call.

We were going to hire a DevOps engineer.

You can, and eventually you might. Until then, InfraHouse gives you a senior-level production stack faster and cheaper than hiring — and your stack is ready to hand to that engineer the day you do.

Why not Heroku or Render?

Because the next enterprise prospect is going to ask where your data lives and whether you can pass a SOC 2. Heroku will not help you answer that. We deliver on AWS from day one.

We do not want lock-in.

You will not have any. Your GitHub org owns your code and Terraform from day one. Graduation moves your AWS account into your own Organization with no rebuild.

Can you run our database?

MySQL today, in v1 scope. Postgres and Redis are quoted as part of the consulting engagement until they land in the productized envelope. If your database is something else, say so on the call — we will tell you honestly whether we are the right fit.

What about custom domains?

v1 uses *.infrahouse.app as the default URL. Custom domains are handled in the consulting engagement today; on the roadmap for the productized service.

// next step

Book a 20-minute call.

Bring a Dockerfile or a question. We will spend twenty minutes on what your stack would look like.

Book a 20-minute call Or see pricing →