Infrastructure as Code with OpenTofu/Terraform

The by default, so you can connect to the instance without opening SSH or managing keys.

When the defaults are not what you want, you override through configuration rather than by dropping down to raw resources:

# dinghy.config.yml

servers:

  web1:

    instance_type: t4g.nano # arm64 instead of the t3.nano default

    linuxFlavor: ubuntu

  web2:

    instance_type: t3.small

That gives you two servers, on different architectures and distributions, still in the same eight lines of TSX.

The full example, with the source, the generated diagram, the complete 248-line Terraform, and the commands to deploy and connect, is at described. The composite renders the VPC, subnet, AMI lookup, and IAM role alongside the instance, and each useAws...() call reaches up the tree to find them, so you never pass references down through props by hand. The opinions and the boilerplate live in one place instead of being copied into every server you ever create.

It also creates only what you did not supply. Before rendering the instances, the composite inspects each server's props and decides which supporting resources to build on demand:

const createVpc = servers.some((s) => !s.subnet_id)

const referenceAmi = servers.some((s) => !s.ami)

const createInstanceProfile = servers.some((s) => !s.iam_instance_profile)

Pass your own iam_instance_profile and the composite uses it. Leave it out and it builds an IAM role and an aws_iam_instance_profile for you, with the SSM policy attached so dinghy aws connect can reach the instance. The VPC and the AMI lookup work the same way: supplied means reused, missing means created on demand.

Two levels, one model

That is the whole picture:

• 
  Basic components are the 1:1 building blocks. Complete control, more typing.


• 
  Composite components are ordinary components assembled from those blocks, with opinions and defaults built in. Less typing, fewer mistakes.

Neither replaces the other. A composite is built from basics, so you can always reach past it: nest a raw AwsVpcSecurityGroupIngressRule as a child of <Ec2Servers>, or swap an internal piece through the _components prop, when you need something the defaults do not cover. You start at the high level and drop down only where it matters.