How this works
The platform stands up secure, observable, production-grade environments for an application without the requesting team writing any infrastructure code. The shape of a run is the same on every cloud:
- You describe the application — its name, the target environment, and which infrastructure template (archetype) to use.
- The platform fires a GitHub Actions workflow via a
repository_dispatchevent, using a token you supply in the browser. - Terraform plans and applies the archetype's modules against your cloud account, with state kept in a per-application backend the platform bootstraps for you.
- The result is verified by the archetype's own assertions, then summarised back into a tracking issue.
Only the cloud-specific details differ — the identity model, the region parameter, and the resources an archetype creates. That's why each cloud has its own form.
Choose your target cloud
Microsoft Azure
App Service
- VNet integration + Private Endpoint
- Managed Identity, Key Vault references
- Application Insights + Log Analytics
- Zone-redundant and autoscaled in prod
Amazon Web Services
ECS Fargate
- VPC with public/private subnets, NAT
- Application Load Balancer + ACM certificate
- CloudWatch logs, alarms and X-Ray
- Blue/green deployments via CodeDeploy
Before your first run
Each cloud form assumes the platform has already been wired to your accounts. That is a one-time job, split the same way these forms are:
| Guide | What it covers |
|---|---|
| Setup for GitHub | Hosting the repository, creating the dev / staging /
prod Environments, and the GH_PAT secret. Identical for every cloud —
do this first. |
| Setup for Azure | App Registration, OIDC federated credentials, RBAC roles. |
| Setup for AWS | OIDC identity provider, IAM role trust policy, state S3 bucket. |
Whichever cloud you pick, the browser token you paste into the form only ever needs permission to dispatch a workflow on this repository — never any cloud credentials. See Pages site for the exact scope.
Other ways to trigger a run
The forms are a convenience, not the only entry point:
- GitHub Actions UI — Actions → <cloud-provider> - Provision & Reconcile Application Resources → Run workflow.
- CLI wrapper —
scripts/trigger-provision-<cloud-provider>.sh, which builds and sends the samerepository_dispatchpayload. - Raw API —
POST /repos/<owner>/<repo>/dispatches. Each form previews the exactcurlequivalent as you fill it in.