Add official Ravion (IDP) support for deploying modules/quilt #126

Summary

Add official support for deploying this module via Ravion, an Internal Developer Platform (IDP) that runs Terraform/OpenTofu on temporary runners inside a connected AWS account and lets platform teams expose infrastructure as typed, form-fillable modules.

An internal evaluation confirmed that Ravion can consume modules/quilt completely unmodified — driven through a custom Ravion module definition that wraps this repo's standard root-config pattern (provider, module "quilt", parameters) rather than forking any Terraform. The evaluation also validated cross-account composition (certificate + stack in one AWS account, DNS in another) and an in-place config update, both via Ravion's typed $ref module-composition mechanism.

This issue proposes turning that into supported, documented tooling.

Motivation

Deploying Quilt into a customer's AWS account today is a manual process: provision an ACM certificate, create DNS records for the catalog host and its derived registry/s3-proxy hosts, wire the certificate ARN and network into the module's parameters, then run terraform apply and watch a ~20–40 minute CloudFormation stack build. Every step is a place to get something wrong (a certificate that doesn't cover all required hostnames, a CNAME at a zone apex, a domain that doesn't match the template's parameter validation, etc.).

An IDP that encodes those rules into a typed module turns that runbook into "pick a domain," and gives ongoing visibility (stack state, plan/apply history, logs) into deployments that today are opaque once terraform apply finishes.

Proposed scope

1. A Ravion module definition (module.yaml) that wraps module "quilt" from this repo, unmodified. The definition should:
   • Expose the handful of inputs a deploy actually needs (name, catalog domain, sizing, network mode) as typed fields instead of raw HCL.
   • Accept typed references ($ref) to a certificate module and a DNS/hosted-zone module, so Ravion can auto-provision and wire them in — rather than requiring the certificate ARN and zone ID to be hand-copied.
   • Derive Quilt's actual hostname contract (catalog host + its registry/s3-proxy siblings) internally, and require the referenced certificate to cover all of them — so a customer can't accidentally deploy a stack whose registry or s3-proxy endpoint has no valid TLS.
2. An example root config (e.g. examples/ravion/) demonstrating the wrapper pattern, alongside a short README explaining the module/cert/DNS composition.
3. Documentation of the one real constraint this surfaces: when the AWS account that owns the deploy is different from the account that owns the domain (the common case for larger customers), the certificate and DNS modules run in different Ravion-connected accounts, referencing each other's outputs. This is a supported Ravion pattern and should be called out explicitly rather than left as a surprise.

Explicit non-goal: no CloudFormation template committed to this repo

The Quilt CloudFormation template must not be checked into this (or any) module-definition repo. It should be fetched at plan/apply time from wherever it is already published — for example the existing per-release S3 artifacts this project already produces — and handed to the template_file input as a generated local path. Committing the generated template is both unnecessary and a way to leak internal build metadata into whatever repo the module definition lives in.

Does this depend on any any other changes?

No. Quilt and Ravion already provide everything we need in their current, off-the-shelf products.

Acceptance criteria

• module.yaml (or equivalent) defining a Ravion module for modules/quilt, referencing this repo's module unmodified.
• Certificate and DNS composed via typed $ref inputs, not hand-copied ARNs/zone IDs.
• Module derives and requires certificate coverage for all of Quilt's hostnames (catalog + registry + s3-proxy), not just the catalog host.
• Template fetched at apply time from an existing published location — nothing generated or internal committed to the repo.
• Example config + README under examples/.