How does Tallywyrm read my Terraform repo?

Tallywyrm reads the customer’s Terraform, Pulumi or Crossplane repo via a GitHub App installed on the repo the platform team owns (for GitHub) or a project access token (for GitLab), brokered through the customer’s OIDC trust so the credential is issued and rotated by the customer’s IdP — long-lived static keys are not accepted. The read scope is restricted to the .tf and .tfvars paths the audit pass identified; read-only is enforced by policy and “apply” is never reached from the agent. `terraform apply` is the customer’s CI’s job, not the agent’s, and the same posture is restated on /methodology and /security-and-compliance.

Which resource types does the Terraform connector map?

The Terraform connector maintains a per-resource-type dictionary that names the safe attribute key the agent writes against. For AWS: aws_db_instance (instance_class, RDS family graviton + x86), aws_instance (instance_type), aws_nat_gateway (delete or consolidate when VPC egress is below 1 GB/week), and aws_eks_node_group (instance_type + autoscaling min/max). For GCP: google_container_cluster / google_container_node_pool (machine_type + node_count), google_sql_database_instance (tier), google_compute_instance (machine_type), and google_compute_router_nat (NAT consolidation). For Azure: azurerm_sql_database / azurerm_mssql_database (SKU + DTU), azurerm_virtual_machine / azurerm_linux_virtual_machine (vm_size), azurerm_kubernetes_cluster_node_pool (vm_size + node_count), and azurerm_nat_gateway (NAT consolidation across PIPs).

How does a Terraform PR row link back to /dashboard/savings?

Every Terraform PR the agent opens becomes one row on /dashboard/savings the moment the customer’s CI applies the diff: the row carries the PR id, the merge actor, the deploy timestamp, the PR diff, the post-deploy cloud-bill re-read, the verified delta in cents and the bundle_sha256 of the row bundle. The weekly export on /dashboard/audit-trail is the byte-for-byte projection of this row order, so the finance, security and procurement teams all reconcile against the same artifact. Forecast and realized are surfaced on separate lines on the same row, and the verified delta reads from the realized side via the same verified-cents formula the methodology pillar on /methodology publishes. The connector is therefore not a separate export or a parallel ledger — it is the same row, the same CSV, and the same hash.

What does a sample Terraform PR diff look like?

A sample Terraform PR diff is a real, scoped HCL diff that the agent opens against the customer’s repo. Two illustrative shapes: (1) an aws_db_instance class rightsize from db.r6g.4xlarge to db.r6g.2xlarge, with a tallywyrm:-prefixed comment citing the baseline-week CPU p95 and the expected post-change p95, and a rollback command embedded in the same .tf block; (2) a google_container_node_pool diff that drops node_count from 3 to 2 and steps the machine_type down from n2-standard-4 to n2-standard-2, with the same tallywyrm: comment shape and a rollback command. Both diffs are the shape the agent opens against a production repo — placeholder IDs are illustrative, the platform writes the real resource address from /inventory at PR open time.

Deep dive · Terraform

How Tallywyrm opens a scoped `.tf` PR against the repo your platform team already owns.

Tallywyrm reads the customer’s GitHub or GitLab repo as a read-only GitHub App or project access token brokered through your OIDC trust, opens a small rightsizing PR against the .tf / .tfvars files the audit pass identified, and never reaches terraform apply. The same row lands on /dashboard/savings with the deploy timestamp, the bundle_sha256 and the cloud-bill delta finance already reconciles against.

Read-the-repo contract
·
Resource families
·
Sample diffs
·
/dashboard/savings

Shape of the diff

One attribute key per resource family. PR-only delivery.

AWS RDS / EC2 / NAT, GCP Cloud SQL / GKE / NAT, Azure SQL DB / VM / NAT — each resource family writes against a single attribute key the dictionary recognises, so the diff is never a free-form string. Same wording as /integrations and the pillar posts that link into /methodology.

01 · Read-the-repo contract

One credential, your repo, scoped diffs.

The agent reads only the Terraform / Pulumi / Crossplane repo and only the .tf / .tfvars paths the audit pass identified. No static long-lived keys are stored — the credential model on /security-and-compliance names the same posture from the controls side.

Credential model

GitHub App or GitLab project token, brokered through your OIDC trust.

For GitHub, Tallywyrm is installed as a GitHub App on the repo your platform team owns — short-lived installation tokens, no per-user PAT. For GitLab, a project access token scoped to the same repo. The same credential opens the Terraform, Pulumi and Crossplane flows.

OIDC trust boundary

The credential is brokered, not held.

The token rotates through your IdP. Long-lived static keys are not accepted, and the scope cannot be expanded from inside the agent. Same wording on /methodology and the access-control grid on /security.

File-path scope

.tf and .tfvars only — never your whole repo.

The agent reads the resource blocks the audit pass identified and writes the diff to the same .tf file. .tfvars and modules are read for context; everything else in the repo is outside the agent’s read scope.

Read-only contract

No apply, no terraform plan against your account.

The agent emits an HCL diff and opens a PR — nothing more. `terraform apply` is your CI’s job. The agent has no execution surface against your cloud; the policy gates on /methodology#policy-gates name the same posture.

02 · Resource families mapped

Per-resource-type dictionaries for AWS, GCP and Azure.

Each rightsizing recommendation targets one resource family — instance_class, machine_type, node_count, SKU, DTU or NAT consolidation. The agent knows the safe attribute keys for each family from a per-cloud dictionary, so the diff is always against a recognised field.

Snippet registry on /security-and-compliance.

AWS

RDS · EC2 · NAT · EKS

Attribute keys the agent writes against.

aws_db_instance
instance_classRDS class rightsizing
aws_instance
instance_typeEC2 family graviton + x86
aws_nat_gateway
—Delete or consolidate
aws_eks_node_group
instance_type + autoscaling min/maxEKS node group rightsizing

GCP

GKE · Cloud SQL · GCE · NAT

Attribute keys the agent writes against.

google_container_cluster / google_container_node_pool
machine_type + node_countGKE node-pool shapes
google_sql_database_instance
tierCloud SQL tier
google_compute_instance
machine_typeGCE family
google_compute_router_nat
—NAT consolidation

Azure

SQL DB · VM · AKS · NAT

Attribute keys the agent writes against.

azurerm_sql_database
sku + dtuAzure SQL DB
azurerm_mssql_database
skuAzure SQL managed instance
azurerm_virtual_machine / azurerm_linux_virtual_machine
vm_sizeAzure VM family
azurerm_kubernetes_cluster_node_pool
vm_size + node_countAKS node pool
azurerm_nat_gateway
—NAT consolidation across PIPs

Sample diffs

The shape of the diff the agent opens against your repo.

These look like real PRs because they are — the same shape the agent opens against your repo, with placeholder IDs replaced for illustration. Thetallywyrm:-prefixed comments are part of the PR description, not a separate trail; reviewers see them in the same .tf file the diff edits.

Sample diff · AWS RDS class

aws_db_instance · db.r6g.4xlarge → db.r6g.2xlarge

Baseline-week avg CPU 17.4 % (p95 22.1 %). Storage, engine and security group unchanged. Rollback is a single attribute flip in the same block.

@@
 resource "aws_db_instance" "orders_warehouse" {
   engine               = "postgres"
   engine_version       = "15.7"
   allocated_storage    = 500
-  instance_class       = "db.r6g.4xlarge"
+  instance_class       = "db.r6g.2xlarge"
   storage_type         = "gp3"
   iops                 = 12000
   apply_immediately    = true

+  # tallywyrm: baseline-week avg CPU 17.4 % (p95 22.1 %) across 2026-02-03 → 2026-02-09.
+  # tallywyrm: r6g.2xlarge carries the same workload — expected sustained 44.6 % p95,
+  # tallywyrm: well under the 80 % throttle threshold for the r6g family.
+  # tallywyrm: rollback by setting instance_class = "db.r6g.4xlarge" and re-applying.
 }

Sample diff · GCP GKE node-pool

google_container_node_pool · n2-standard-4 → n2-standard-2

Baseline-week avg CPU 18.7 % (p95 26.3 %). Node_count drops 3 → 2;max_capacity retained at 4 for the Friday load-test burst window.

@@
 resource "google_container_node_pool" "primary_nodes" {
   cluster    = google_container_cluster.primary.name
   location   = "us-central1"
   node_count = 3
-  node_config {
-    machine_type = "n2-standard-4"
-  }
+  node_count = 2
+  node_config {
+    machine_type = "n2-standard-2"
+  }

+  # tallywyrm: baseline-week avg CPU 18.7 % (p95 26.3 %) across 2026-02-17 → 2026-02-23.
+  # tallywyrm: max_capacity retained at 4 for the Friday load-test burst window.
+  # tallywyrm: rollback by setting node_count = 3 and machine_type = "n2-standard-4".
 }

03 · Link-back to /dashboard/savings

The same row that opened the PR lands on /dashboard/savings.

The row that opens the PR in your repo carries the deploy timestamp, thebundle_sha256 and the measured cloud-bill delta. It appears on /dashboard/savings the same week, with the same PR diff and the same verified cents the page above prints. Finance reconciles against the same row; methodology backs the verification definition.

Deploy timestamp + PR diff + bundle_sha256, on one row.The deploy timestamp attaches to the audit row the moment your CI applies the diff. The PR diff and the bundle_sha256 of the row bundle travel on the same row — the export that /dashboard/audit-trail and the weekly CSV produce is the byte-for-byte projection of this row order.
Post-deploy measurement reads the same workload, same window.The same workload, in the same account, in the same cloud region, over the same time-of-week window. Verified_cents = re_read_bill_baseline − re_read_bill_post_change. Forecast and realized are surfaced separately so drift is visible at the same time.

See it on the report

The audit row is the same artifact every reconciliation framework already asks for.

Same wording on /methodology and /security/compliance. Forecast and realized stay on separate lines on the same row so a forecast inflation cannot pass for a saving.

→ /methodology → /dashboard/savings

Proof

Cross-checked on /methodology and /security/compliance.

Nothing on this page is a new attestation — it is a public mapping from the credential contract and the weekly export that /methodology and /security/compliance already publish. The audit row is the same artifact every reconciliation framework already asks for.

/methodology →Proof · pillar 1 + 2

Verified-savings definition: one PR, one deploy timestamp, one measurement window.
Audit-row schema: who, what, when, IP, PR diff, deploy timestamp,bundle_sha256, post-deploy measurement.
Drift detection: forecast and realized surfaced as separate lines on the same row, the credit reversed on the next invoice if the merged recommendation regresses.

/security/compliance →Proof · pillar 3 + 4

Five-framework matrix: SOC 2 Type II CC7.2, ISO 27001 Annex A.12.1.2, FedRAMP Moderate CM-3/CM-5, EU CSRD ESRS E1 §62–§66, SEC climate disclosure Scope 3 cat. 1.
Sub-processor list: AWS, Cloudflare R2, Stripe, email proxy, session library — lifted verbatim from the per-framework page.
Retention windows: 13 months minimum per workspace, configurable per workspace; bounds the same export on /privacy.

Get Tallywyrm

One signup. Broker the OIDC trust. The first scoped PR lands the same day.

Create a workspace, install the GitHub App or grant the GitLab project token, and the first diff lands as a PR the same day. Pay a percentage of verified savings against the same audit row finance already reconciles against.

Deep dive for /integrations → · playbook library on /blog → · PR loop on /how-it-works →.