Skip to content
Adventive Adventive Engineering

Infrastructure as Code (Terraform)

Adventive’s shared, cross-cutting infrastructure — the pieces not owned by any single product team — is managed as code in the adventive-platform-infra repository (Adventive/adventive-platform-infra). It holds Terraform modules and the operational scripts they consume: the Cloudflare Tunnel fleet, the cloudflared AMI pipeline, the Hyperdrive connectors, the status Worker’s edge resources, and similar shared concerns.

Application logic lives in the individual Worker repos; this repo owns the infrastructure those Workers run on and reach through.

Modules

Section titled “Modules”

Each module under infra/ is applied independently, parameterized by environment.

ModuleWhat it provisions
infra/imagebuilder/EC2 Image Builder pipeline that produces the adv-cflared AMI — the hardened image the tunnel ASGs boot.
infra/cflared-asg/Per-environment Launch Template + Auto Scaling Group that boots the AMI, fetches tunnel credentials from Secrets Manager at instance boot, and starts cloudflared. The subnet/AZ each ASG launches into is set here — relocating a connector to a different availability zone is a change to this module.
infra/cloudflare-tunnels/The Cloudflare Tunnel resources and per-environment cloudflared ingress configuration (which hostname proxies to which private database endpoint).
infra/cloudflare-hyperdrive/The per-role Hyperdrive configs, their Access apps, and the Secrets Manager entries behind them — the provisioning side of the Hyperdrive standard.
infra/cloudflare-status-worker/The DNS record, Worker route, and Cloudflare Access app for status.adventive.dev (the Status Dashboard).
infra/cloudflare-newrelic-proxy-worker/Edge resources for the New Relic proxy Worker.
scripts/Helper scripts uploaded to the artifacts S3 bucket and consumed by Image Builder components (e.g. cflared-bootstrap.sh).

Conventions

Section titled “Conventions”

These hold across every module and are the rules to know before running an apply:

  • One terraform apply per environment, parameterized by var.env (dev, stg, prd). Terraform workspaces map 1:1 to environments.
  • State backend: S3 + DynamoDB locking. The backend block lives in each module’s versions.tf. State bucket adventive-tfstate-<account-id>, lock table adventive-tfstate-lock.
  • Region: us-east-1 primary; us-west-2 for DR resources only.
  • No secrets in state. All credentials live in AWS Secrets Manager and are fetched at instance boot via user-data, or by application code at runtime from Secrets Store — never written into Terraform state as plaintext.
  • Tag standard: every resource carries adv:env, adv:owner, adv:project, and Name.

Applying a change

Section titled “Applying a change”
Terminal window
git clone git@github.com:Adventive/adventive-platform-infra.git
cd adventive-platform-infra/infra/<module>
terraform workspace select <dev|stg|prd>
terraform plan     # review every change before applying
terraform apply

Production applies are gated: review the plan, and for anything that recreates a resource (for example a tunnel whose config_src changes, which forces replacement) confirm the blast radius before applying. Repo-local ADRs and runbooks under docs/ are the source of truth for module-specific behavior.

Section titled “Related”