I know what you mean, but there seems to be some kind of misplaced fear about this which has led us down the garden path of unmaintainable config (or even trying to jinja template it!)
If your config is turing complete and consumed as-is, then without a lot of discipline you can dig yourself into a hole, sure.
If you're producing YAML that is not turing complete, that constraint means you have to code in a way that produces deterministic output. It's actually very safe, and YAML maps 1:1 to types in something like Python.
My favourite go-to example is for AWS Cloudformation:
https://github.com/cloudtools/troposphere
In What twenty years of DevOps has failed to docloudtools
troposphere
Python2014–2026
cloudtools / troposphere
troposphere
troposphere - Python library to create AWS CloudFormation descriptions
24Distinct people
27Mentions
0Explicit recommenders
4.9KGitHub stars
What to know before exploring
What it is
troposphere - Python library to create AWS CloudFormation descriptions
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- cloudtools/stacker · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year27 dated mentions
Observed mentions: 2014-07-28 19:37:23 UTC to 2026-01-18 01:27:01 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 5 | 1 | 4 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 1 | 0 | 1 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
troposphere
About
troposphere - library to create AWS CloudFormation descriptions
The troposphere library allows for easier creation of the AWS CloudFormation
JSON by writing Python code to describe the AWS resources. troposphere also
includes some basic support for OpenStack resources via Heat.
To facilitate catching CloudFormation or JSON errors early the library has
property and type checking built into the classes.
Installation
troposphere can be installed using the pip distribution system for Python by
issuing:
$ pip install troposphere
To install troposphere with awacs
(recommended soft dependency):
$ pip install troposphere[policy]
Alternatively, you can use setup.py to install by cloning this repository
and issuing:
$ python setup.py install # you may need sudo depending on your python installation
Examples
A simple example to create an instance would look like this:
>>> from troposphere import Ref, Template
>>> import troposphere.ec2 as ec2
>>> t = Template()
>>> instance = ec2.Instance("myinstance")
>>> instance.ImageId = "ami-951945d0"
>>> instance.InstanceType = "t1.micro"
>>> t.add_resource(instance)
<troposphere.ec2.Instance object at 0x101bf3390>
>>> print(t.to_json())
{
"Resources": {
"myinstance": {
"Properties": {
"ImageId": "ami-951945d0",
"InstanceType": "t1.micro"
},
"Type": "AWS::EC2::Instance"
}
}
}
>>> print(t.to_yaml())
Resources:
myinstance:
Properties:
ImageId: ami-951945d0
InstanceType: t1.micro
Type: AWS::EC2::Instance
Alternatively, parameters can be used instead of properties:
>>> instance = ec2.Instance("myinstance", ImageId="ami-951945d0", InstanceType="t1.micro")
>>> t.add_resource(instance)
<troposphere.ec2.Instance object at 0x101bf3550>
And add_resource() returns the object to make it easy to use with Ref():
>>> instance = t.add_resource(ec2.Instance("myinstance", ImageId="ami-951945d0", InstanceType="t1.micro"))
>>> Ref(instance)
<troposphere.Ref object at 0x101bf3490>
Examples of the error checking (full tracebacks removed for clarity):
Incorrect property being set on AWS resource:
>>> import troposphere.ec2 as ec2
>>> ec2.Instance("ec2instance", image="i-XXXX")
Traceback (most recent call last):
...
AttributeError: AWS::EC2::Instance object does not support attribute image
Incorrect type for AWS resource property:
>>> ec2.Instance("ec2instance", ImageId=1)
Traceback (most recent call last):
...
TypeError: ImageId is <type 'int'>, expected <type 'basestring'>
Missing required property for the AWS resource:
>>> from troposphere import Template
>>> import troposphere.ec2 as ec2
>>> t = Template()
>>> t.add_resource(ec2.Subnet("ec2subnet", VpcId="vpcid"))
<troposphere.ec2.Subnet object at 0x100830ed0>
>>> print(t.to_json())
Traceback (most recent call last):
...
ValueError: Resource CidrBlock required in type AWS::EC2::Subnet (title: ec2subnet)
Currently supported resource types
AWS Resource Types
OpenStack Resource Types
Duplicating a single instance sample would look like this
# Converted from EC2InstanceSample.template located at:
# http://aws.amazon.com/cloudformation/aws-cloudformation-templates/
from troposphere import Base64, FindInMap, GetAtt
from troposphere import Parameter, Output, Ref, Template
import troposphere.ec2 as ec2
template = Template()
keyname_param = template.add_parameter(Parameter(
"KeyName",
Description="Name of an existing EC2 KeyPair to enable SSH "
"access to the instance",
Type="String",
))
template.add_mapping('RegionMap', {
"us-east-1": {"AMI": "ami-7f418316"},
"us-west-1": {"AMI": "ami-951945d0"},
"us-west-2": {"AMI": "ami-16fd7026"},
"eu-west-1": {"AMI": "ami-24506250"},
"sa-east-1": {"AMI": "ami-3e3be423"},
"ap-southeast-1": {"AMI": "ami-74dda626"},
"ap-northeast-1": {"AMI": "ami-dcfa4edd"}
})
ec2_instance = template.add_resource(ec2.Instance(
"Ec2Instance",
ImageId=FindInMap("RegionMap", Ref("AWS::Region"), "AMI"),
InstanceType="t1.micro",
KeyName=Ref(keyname_param),
SecurityGroups=["default"],
UserData=Base64("80")
))
template.add_output([
Output(
"InstanceId",
Description="InstanceId of the newly created EC2 instance",
Value=Ref(ec2_instance),
),
Output(
"AZ",
Description="Availability Zone of the newly created EC2 instance",
Value=GetAtt(ec2_instance, "AvailabilityZone"),
),
Output(
"PublicIP",
Description="Public IP address of the newly created EC2 instance",
Value=GetAtt(ec2_instance, "PublicIp"),
),
Output(
"PrivateIP",
Description="Private IP address of the newly created EC2 instance",
Value=GetAtt(ec2_instance, "PrivateIp"),
),
Output(
"PublicDNS",
Description="Public DNSName of the newly created EC2 instance",
Value=GetAtt(ec2_instance, "PublicDnsName"),
),
Output(
"PrivateDNS",
Description="Private DNSName of the newly created EC2 instance",
Value=GetAtt(ec2_instance, "PrivateDnsName"),
),
])
print(template.to_json())
Community
We have a Google Group, cloudtools-dev, where you can ask questions and
engage with the troposphere community. Issues and pull requests are always
welcome!
Licensing
troposphere is licensed under the BSD 2-Clause license.
See LICENSE for the troposphere full license text.
Read the full README on GitHubWhat Hacker News says
27 sourcesThere are probably two use cases.
Configuration files for programs. These tend to be short.
DSLs which are large manifests for things like cloud infrastructure. These tend to be long, they grow over time.
My pet hypothesis is these DSLs exist mostly for neutrality - the vendor can't assume you have Python or something present. But as a user, you can assume just that and gain a lot by authoring in a proper language and generating YAML.
See https://github.com/cloudtools/troposphere for a great example for AWS CloudFormation.
In YAML: The Norway Problem (2022)Seems like an interesting generalized mix of something like https://github.com/cloudtools/troposphere and Ansible from a glance.
The value add would be unifying provisioning and configuration management in a Python-y experience? The lifecycle of each is distinct and that's traditionally where the headaches of using a single tool for both has come in
In Pyinfra: Automate Infrastructure Using PythonWouldn't using troposphere[1] be easier?
[1] https://github.com/cloudtools/troposphere
In Terraform should have remained stateless> Not to mention, CloudFormation actually allows ~transactions, which is something you can't really get without cooperation from the cloud provider (terraform and pulumi both use cloudformation on AWS for exactly this reason)
Terraform doesn't use CloudFormation on AWS (and I thought Pulumi used Terraform under the covers in some capacity?). I've also seen a lot of CloudFormation stacks get into completely unrecoverable states because AWS was trying to roll back a transaction, but the rollback failed. If you have a premium support contract, someone can un-stick it for you, but for the rest of us we just had to create a new stack. I've been off AWS for a year and change, so maybe this has improved?
In whichever case, I've only dabbled with CDK, but I was disappointed. What I really want is a better Troposphere[0]--sort of an AST library fo
Read the rest
r CloudFormation, ideally type-safe. I don't care that the backend is CloudFormation in particular, but the idea is that we should have a clean separation between the backend diff engine and the abstraction layer that humans use to DRY the input to the backend diff engine.
[0]: https://github.com/cloudtools/troposphere
Troposphere – A Python library which allows you build cloudformation templates
2 points · Open discussionTo me it reminds me of troposphere[1]. It's similarly using an imperative language (also python) to generate a declarative file (CloudFormation).
[1] https://github.com/cloudtools/troposphere
In Write Gitlab CI Pipelines in Python CodeFor anyone writing bash scripts to manage CloudFormation templates (eek), there are tools out there like Troposphere to make CF manageable [0].
[0]: https://github.com/cloudtools/troposphere
In AWS services to avoidFor cloudformation; my team a few years ago got a lot of mileage out of using troposphere.
https://github.com/cloudtools/troposphere
The basic type checking done was quite helpful, and avoided some of the dumb errors that we had run into when we attempted to do everything by hand.
In YAML: Probably not so great after allI'm in charge of cloud infrastructure at my company, and I've found that sticking with CloudFormation on AWS is more powerful and versatile than TerraForm, since TF isn't always a perfect mapping, where CFN is, with the caveat that it's sometimes months behind what their API can do.
To that end, over the years, I've come across a couple of tools which help write CFN templates and manage rollout keeping cross-stack dependencies in mind. If anyone does a lot of CFN, I highly recommend Troposphere (python abstraction for cloudformation) [1] and Stacker (manager stack rollout via dependency DAG) [2]
1: https://github.com/cloudtools/troposphere
2: https://github.com/cloudtools/stacker
In How I use the good parts of AWSTroposphere: library to create AWS CloudFormation descriptions with Python
3 points · Open discussionI've been thinking about this sort of thing a lot recently in terms of our heavy use of Troposphere[1] which is a Python abstraction over AWS CloudFormation and how much better that abstraction is than just writing HTML (in the case of this library) or JSON/YAML (in the case of CloudFormation) directly.
Ultimately, for me, it comes down to what makes sometimes complicated declarative code easier to reason about, read and understand - it's a simple as that.
Some things are just _easier_ to write when you've got the power of a Turing-complete language with a decent standard library behind you; if for example you want to dump out a sorted list and then be able to easily update it later, or print a list of links alongside a hash of the contents of their targets.
I guess if you're building a simple website, anything like this tool could be ove
Read the rest
rkill and you'd risk spending more time setting things up - and maintaining it in the future - than you'd be likely to save by using the tool in the first place. But for more complicated output having more tools to use lets you be arguably more declarative; you just change the input data to generate the desired output. You describe and allow automation of the _transition_ from input data to the desired end point.
I could definitely see how libraries like this would be tremendously useful for generating HTML. As it happens for our AWS infrastructure generation we enforce the use of Troposphere everywhere, because in that case the cost of setting up and maintaining it is essentially just copy-pasting an existing Makefile.
[1] https://github.com/cloudtools/troposphere/
Most people probably think of Terraform[0] or Fugue[1] here, but it also includes the more venerable likes of CloudFormation[2] and OpenStack Resources[3], both writeable in Troposphere[4].
It also includes any random mess of shell scripts and the like that manage the lifecycle of infrastructure.
[0] https://www.terraform.io/
[1] https://www.fugue.co/
[2] https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui...
[3] https://docs.openstack.org/heat/latest/template_guide/openst...
[4] https://github.com/cloudtools/troposphere
In Lessons Learned from Writing Over 300k Lines of Infrastructure CodeThe real advantage of CloudFormation comes in combining it with the AWS APIs -- you can define your infrastructure as code in Python, NodeJS, Java, Ruby, &c.
* troposphere (Python): https://github.com/cloudtools/troposphere
* cloudform (JavaScript, TypeScript): https://github.com/bright/cloudform
Driving infrastructure with a general purpose programming language actually works pretty well in practice.
As things have developed, I've come to question infrastructure-specific external DSLs, like Salt, Terraform, even Chef to some extent. Infrastructure is not any less programmable than payments, machine learning, graphics, app servers. Why can't the tooling be provided as libraries, consumable from ordinary programming languages?
In Terraforming 1PasswordShowing the 15 most recent of 27 sources. Enable JavaScript to search and browse every indexed mention.