former2: reverse engineering AWS infrastructure into Infrastructure as Code

The scan starts from what is already running in the account

Most Infrastructure as Code tooling assumes you begin with a template and push it outward. former2 runs the other direction. You point it at an account that already has resources in it, it calls the AWS JavaScript SDK to enumerate what is there, and it presents that inventory as a list you can select from. Once you have chosen the resources worth capturing, the tool writes the equivalent template and hands it to you as text.

The workflow the README describes is deliberately manual at the selection step. You authenticate with an IAM key pair, navigate to a service through the dashboard or the sidebar, tick the resources you want, then press the Generate button at the top of the screen. There is no filter expression, no tag query and no bulk everything mode described. That constraint turns out to be a reasonable design: an account that has drifted for years contains a lot of resources that nobody would want in a template, and picking by hand is the cheapest way to decide what belongs.

Two badges at the top of the README set expectations before you install anything. CloudFormation coverage reads 84 percent and Terraform coverage reads 49 percent, both linking into RESOURCE_COVERAGE.md. Those two numbers are the most useful thing on the page, because they tell you the generated Terraform will hit unsupported resource types sooner than the generated CloudFormation will.

Why the browser extension is not an optional extra

The installation section is one paragraph long and it is load-bearing. Former2 Helper is a browser extension published for Chrome, Firefox and Edge, and the README states plainly that although some AWS services do not require it, you need the extension in order to have support for all of them. The stated reason is a lack of CORS on some services, S3 and IAM named explicitly.

The reason this matters is architectural. If the tool called every AWS endpoint from a server, CORS would not come up at all. Instead the calls are made either directly from the page with the SDK or through the extension, and both paths talk to AWS endpoints rather than to any backend belonging to the project. That design is what makes the security story in the next section possible, and it is also why self hosting has a wrinkle you will hit later.

The extension is also available as source if you would rather not install from a store. The README links a separate former2-helper repository, which matters for anyone with a policy against extensions from web stores or a need to audit what the extension is permitted to see.

Eight output targets from one selection of resources

The output list is longer than the AWS Infrastructure as Code ecosystem usually gets credit for. The README enumerates CloudFormation, Terraform and Troposphere, then adds CDK V1 and CDK V2 using Cfn primitives in TypeScript, Python, Java and C#, plus CDK for Terraform in TypeScript, plus Pulumi in TypeScript. The last entry is different in kind: a diagram, an embedded version of draw.io, so you get a picture of the resource graph next to the code that produces it.

Troposphere deserves a note because it is the least fashionable item on that list. Troposphere generates CloudFormation from a Python DSL, and it predates most of the alternatives. Its presence tells you the project has been maintained across a long shift in how people write AWS infrastructure, and it also gives you an escape hatch if the generated raw CloudFormation is not what your pipeline consumes.

One feature is conspicuously absent from the output list: Get and List outputs. The README addresses this directly in its FAQ section, where it says AWSConsoleRecorder still fills that gap and that both tools will be maintained. Read that as a boundary rather than a bug report. former2 reconstructs resource definitions from API calls, which is the right tool for a load balancer or a security group, and the wrong tool for the transient output of an API action.

Credentials stay in the browser and no resource is ever created

The security section is unusually specific for a project in this category, and the claims are checkable by reading the architecture rather than trusting a promise. Former2 does not create any resources within your AWS account. Calls to AWS service endpoints are made directly with the JavaScript SDK or through the extension, which also hits endpoints directly. Resource data and credentials are kept in memory and are never sent over the internet, and the credentials are used only to sign requests to AWS endpoints.

That last point depends on the credential choice the README recommends. If you are not planning to import resources directly, it suggests supplying read-only access with the ReadOnlyAccess policy. If you do intend to use the Import feature, which creates a stack, you need permissions to create that stack instead. The recommendation to strip passwords and other sensitive values before sharing generated code is worth repeating, because generated templates capture whatever was in the resource properties, and resource properties include secrets more often than people expect.

The pricing note is short and honest. Former2 is free to access or to self host, but some AWS services charge for API calls, so usage may add a couple of cents to your bill. There is no per-seat pricing and no account to create.

Self hosting is a static site in front of nginx

If you would rather not hand your AWS credentials to a publicly hosted page, the README points at HOSTING.md and the answer is pleasantly small. You run an HTTP server from the root of the repository. The Dockerfile in the repository root is two meaningful lines:

FROM nginx:stable
COPY . /usr/share/nginx/html

The comments above it give the build and run pair, where the port variable stands in for whatever host port you want to expose:

docker build -t former2_local:1.0 .
docker run --name former2 -p $host_port:80 -d former2_local:1.0

There is a docker-compose.yml alongside it that maps the working directory into the nginx html directory and binds the published port to 127.0.0.1 only, which is the right default when something in front of it is doing TLS. The repository tree shows why this is sufficient: index.html, js/, css/, plugins/, lib/ and util/ are static assets with no server-side component to run.

One caveat is called out for self hosting. Extension support is also available if you host on 127.0.0.1 or localhost. Anywhere else, HOSTING.md explains how to modify the extension, because the extension has to be allowed to talk to your origin.

A separate CLI package with a narrower job

The root package.json in this repository is not the web application. It describes the command line version, with the description Command-line interface for the Former2.com tool, main pointing at cli/main.js, and a bin entry named former2. The cli/ directory in the tree holds it, and the README calls it a command-line version with limited functionality, linking to cli/README.md for the instructions this page does not repeat.

The dependency list in that manifest is where you can see what the CLI leans on: aws-sdk at the v2 line, commander for argument parsing, cli-progress for progress output, deepmerge, colors and logplease. It also depends on a published package named former2 at ^0.2.48, so the CLI consumes the generator as a library rather than reimplementing it. The manifest version there is 0.2.83.

The distinction matters when you are deciding how to use this in a pipeline. The browser tool is for the discovery pass, where a person selects resources and reviews the result. The CLI exists for repeated runs against known selections. The README does not document an import or drift-detection workflow that would compare two runs, so treating the CLI as a continuous reconciliation tool would be reading capabilities into it that are not described.

Editorial conclusion

former2 is at its best on the unglamorous work: an account someone else built, a load balancer or a security group you need to start tracking in version control, and no appetite for hand-writing the template. It does not plan, it does not apply, and it deliberately cannot create resources, so treat the output as a starting draft that a human still has to review before it enters a pipeline. The RESOURCE_COVERAGE document is the file worth reading first, since the 84 percent CloudFormation badge and the 49 percent Terraform badge say more about where you will hit gaps than the feature list does. If you also need the console interactions captured as they happened, AWSConsoleRecorder is the companion piece rather than the replacement.

Frequently asked questions

Official sources

1. iann0036/former2 on GitHub
2. Issues
3. License: MIT
4. Project website
5. README