aws-cf-templates: full CloudFormation stacks you can read before you deploy them

One directory per complete stack, not a snippet collection

The repository is organised by what you are deploying, and each top-level directory is a self-contained stack:

ec2/
ecs/
fargate/
jenkins/
operations/
security/
state/
static-website/
test/
vpc/
wordpress/

That last detail is the point. There is no `snippets/` directory and no `examples/` folder of fragments. A stack in `vpc/` is the VPC you would actually stand up, with its subnets, routing and gateways wired together, and a stack in `fargate/` is a working container platform rather than an ECS task definition in isolation. For someone who wants to know what a complete deployment of something looks like, that difference is worth more than the number of templates.

The naming tells you the scope of ambition. `wordpress/` implies a database, a web tier and presumably some way to reach it. `jenkins/` implies a controller and possibly agents. `security/` and `operations/` are the less obvious ones and are where monitoring, logging and baseline hardening templates tend to live. `state/` is a small category but the one most people overlook: CloudFormation needs somewhere to keep its own state, and templates that provide it are rarer than they should be.

The repository is licensed Apache 2.0, with a LICENSE file at the root and a README line stating that all templates are published under that license. The primary language GitHub reports is Java, which is a quirk of how the language detector classifies this repository rather than a statement about what is in it; the topic list is unambiguous instead, running from `aws` and `aws-cloudformation` through `cloudformation-yaml` and `infrastructure`.

The documentation lives at cloudonaut, in stable and latest flavours

The README opens by pointing somewhere else twice, and the distinction between those two links is the first thing to understand. There is a documentation site for the latest stable release and a separate one for the unstable master branch. The homepage field in the repository metadata is the stable one, templates.cloudonaut.io.

That split is a versioning decision rather than an accident. Reading the latest documentation tells you what master does today, which may include templates that have not shipped in a release. Reading the stable documentation tells you what v14.20.0 does. If you are planning a deployment rather than studying the project, the stable site is the honest reference and you should pin your checkout to the matching tag.

The documentation site itself is built from this repository. The tree contains `docs/`, an `mkdocs.yml`, a `.readthedocs.yaml` configuration file and a `.yamllint` configuration, which is what a MkDocs site hosted on Read the Docs looks like from the inside. The `test/` directory is a separate concern again and is presumably where template validation lives.

So the README is not pretending to be documentation. It is an index that hands you a versioned manual and an issue tracker, and the manual is where you will spend your time. That is a defensible arrangement for a project whose real content is the stacks themselves rather than the prose.

Releasing by tag, with a manual step that points at another repository

The README documents its own release process in two steps, and the first is a single command:

git tag vX.Y.Z && git push --tags

The second step is to create the release on GitHub, select the tag, and write a changelog by summarising the commits since the last release. Both steps are manual, and there is no automation described in the repository for tagging or changelog generation.

There is a detail in that second step worth flagging, because it will send you to the wrong page if you follow it literally. The URL given for creating the release points at `widdix/aws-ec2-ssh`, a different repository, rather than at this one. The intent is clear, since both projects are maintained by the same engineer and the release flow is evidently shared, but the link as written does not match the repository you are in. The safe move is to create the release from your own repository's releases page using the tag you just pushed.

The release history shows a steady but unhurried cadence: v14.18.1 on 2025-06-24, v14.19.0 on 2025-07-24, and v14.20.0 on 2025-10-14. The minor version has reached fourteen, which suggests a long-lived project that has accumulated breaking changes to templates along the way rather than one that has held a stable interface since the start.

Master is ahead of the last release

The last push to this repository was on 2026-03-04, and the most recent tagged release is v14.20.0 published on 2025-10-14. Those two dates are almost five months apart, which means the master branch contains work that has never been in a release, and it lines up exactly with the README's decision to publish separate documentation for the unstable master branch.

For an infrastructure repository this gap matters more than it would for a library. A template in master might reference an AWS feature that your account region does not have yet, or a parameter whose default changed, or a nested stack layout that the stable documentation does not describe. Since CloudFormation creates real billable resources, treating master as a deployment target rather than a development branch is the mistake to avoid.

The repository is not archived, and nothing in it suggests abandonment. But a fair reading of the dates is that tags land a few times a year rather than monthly, so a template you find useful may sit unchanged for months and then move when a release does. If you depend on one of these stacks, vendoring the template into your own repository after you have adjusted it is the safer habit.

Where the CloudFormation and Terraform question actually lands

Searches around this project tend to ask whether CloudFormation is better than Terraform, and the README does not answer that, because it is not the question the repository is built to answer. These templates are CloudFormation, full stop. What they offer is a readable example of a working architecture.

The comparison worth making is not between tools in the abstract but between what you get from reading one of these stacks versus writing the equivalent yourself. A `vpc/` template shows parameter naming, export and import conventions, and the specific way this author sequences dependent resources, which is knowledge you cannot get from reading the AWS documentation alone. The cost is that the choices are one engineer's opinions and are not argued for anywhere in the repository.

Two related projects extend the same work and are linked from the README. The widdix CLI manages these templates, which suggests the templates are parameter-heavy enough to need a wrapper rather than being typed into the console. cfn-modules is described as rapid CloudFormation, modular, production ready and open source, and is where you would look if you want composition rather than one large stack. The relationship is division of labour: this repository gives you whole deployments, cfn-modules gives you reusable pieces, and the CLI gives you a way to drive either.

A commercial flank to an open source repository

The README closes the loop by pointing at the author's other work. Four commercial products are listed on the AWS Marketplace: bucketAV, antivirus for Amazon S3 and Cloudflare R2; attachmentAV, antivirus for SaaS and cloud platforms; HyperEnv, self-hosted GitHub Actions runners for AWS; and marbot, event-driven AWS monitoring.

None of this changes the license. The templates are Apache 2.0 and usable as such, and Apache 2.0 permits commercial use without obligation to the author. What it does tell you is where the incentive lies, which is worth weighing when you are deciding how much to rely on the project.

Antivirus for object storage and event-driven monitoring are both things a CloudFormation template could plausibly have contained. They are not here, because they are sold. So the repository gives you the infrastructure and the paid products occupy the operational layer above it. That is a coherent business model rather than an open source one being held back, and for a template collection it is a reasonable arrangement: you get the boring, testable parts free and pay for the parts that need to keep working at three in the morning.

The About section attributes the project to cloudonaut.io, engineered by widdix. Combined with the hosted documentation at templates.cloudonaut.io and the separate CLI and module projects, the picture is of one maintainer running a small, coherent product family rather than a community foundation.

Editorial conclusion

These templates are most useful to a reader who wants to understand how a working AWS deployment is wired, because each directory holds a complete stack with the parameter interface exposed rather than an excerpt. They are least useful if you want a managed opinion about your architecture, since the choices are one engineer's and the documentation is a separate site. Two practical checks come first. The latest tagged release is v14.20.0 from 2025-10-14 while the last push was on 2026-03-04, so the master branch carries changes that are not in any release, and you should decide deliberately between the stable docs and the latest docs. Second, the deployment instructions live in a separate repository, so clone the matching version tag before you plan a rollout rather than reading master documentation against an older stack.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. widdix/aws-cf-templates on GitHub