Cloudflare Migration: Frontend Infrastructure Approaches

Context: We are migrating our AWS frontend infrastructure (CloudFront + S3) to Cloudflare as part of moving to AWS Sovereign Cloud (Berlin region), which does not support CloudFront. We already have domains, Workers, Pages, and Zero Trust configured in Cloudflare.

1. Background and Goals

AWS Sovereign Cloud (eu-central-2, Berlin) does not support CloudFront or S3 static hosting in the same way. We need an alternative CDN and edge platform for all our frontend apps.

Why Cloudflare? We already use it for DNS, Zero Trust, and some Workers. Consolidating there reduces the number of platforms we operate.

Key goals from team feedback:

• Avoid Terraform in every app repo — too much overhead per project
• Keep app code and deployment config in the same repo where possible
• Reduce the number of shared/infrastructure repos
• Support microstage environments: one full deployment per open PR, automatically

2. What We Need to Manage

Not all Cloudflare resources are equal. Some belong to individual apps; others belong to the whole organisation. This distinction drives every architecture decision below.

Resource scope diagram

3. Approach 1 — Wrangler Only

What is it?

Wrangler is Cloudflare's own CLI tool. You put a wrangler.toml file in each app repo, and Wrangler handles deploying the app to Cloudflare Pages or Workers. No separate IaC tool is needed for the app itself.

How it works

Every app repo gets a wrangler.toml that describes the Pages project name, environment variables, KV/R2 bindings, and routes. The GitLab CI pipeline runs wrangler pages deploy on every push. That's it.

# wrangler.toml — lives in the app repo
name = "my-frontend-app"
compatibility_date = "2024-01-01"
pages_build_output_dir = "dist"

[env.production]
vars = { APP_ENV = "production" }

[env.staging]
vars = { APP_ENV = "staging" }

What it covers

• Deploying static sites and SPAs to Cloudflare Pages
• Deploying edge logic (Workers, Pages Functions)
• KV namespace bindings and R2 bucket bindings
• Environment variables per environment
• Preview deployments per branch (microstage)

What it cannot cover

Verdict

Use this approach only for app deployments. It must be combined with something else for org-level config.

4. Approach 2 — Terraform + Wrangler (Two-layer)

What is it?

A clean split: one shared platform infra repo uses Terraform (or Pulumi) to manage everything at the organisation and zone level. Each app repo uses only Wrangler for its own deployment. App teams never see or touch Terraform.

Architecture diagram

The platform infra repo structure

cloudflare-platform-infra/
├── dns/
│   ├── main.tf          # MX records, subdomains, CNAMEs
│   └── variables.tf
├── waf/
│   ├── main.tf          # Custom WAF rules per zone
│   └── rules.tf
├── zero-trust/
│   ├── applications.tf  # Zero Trust app policies
│   └── policies.tf
├── rate-limiting/
│   └── main.tf
├── ssl/
│   └── main.tf          # TLS strictness, min version
└── README.md

Why keep Terraform here?

For standing infrastructure that changes rarely but must be correct, Terraform gives you three things the other approaches cannot:

• Drift detection: terraform plan tells you if someone changed something in the dashboard without going through code review.
• Declarative state: The code describes what should exist. If you delete the repo and re-apply, you get the same result.
• Dependency ordering: Terraform works out that a DNS record must be created before a Zero Trust policy that references it.

Pulumi as an alternative to Terraform

If the team finds Terraform's HCL syntax unfamiliar, Pulumi does the same job with TypeScript. The state file can be stored in S3 (eu-central-1) which fits our AWS Sovereign Cloud setup cleanly. Coverage is identical — the Cloudflare provider is available for both.

Verdict

5. Approach 3 — Cloudflare SDK in CI

What is it?

Cloudflare publishes SDKs in Node.js, Python, and Go that wrap their REST API. They have full coverage of everything the API supports. The idea is to use the SDK in GitLab CI scripts instead of Wrangler or Terraform.

The honest problem with this approach

The SDK is an API client, not an infrastructure manager. Using it as a replacement for Terraform means you have to write code that does what Terraform does automatically:

// With Terraform: you write what you want, Terraform figures out the rest
resource "cloudflare_ruleset" "waf" {
  name = "WAF rules"
  rules = [...]
}

// With the SDK: you write every step manually
const existing = await cf.rulesets.list({ zoneId });
const rule = existing.find(r => r.name === "WAF rules");
if (rule) {
  await cf.rulesets.update(rule.id, { zoneId, rules: [...] });  // update
} else {
  await cf.rulesets.create({ zoneId, name: "WAF rules", rules: [...] });  // create
}
// And you still need to handle: errors, retries, ordering, cleanup, drift

For each resource type (WAF, DNS, Zero Trust, rate limiting) you write this logic from scratch. At scale this becomes a fragile, hard-to-maintain custom IaC system.

Where the SDK genuinely belongs

The SDK is the right tool for dynamic, event-driven operations — not standing infrastructure management. Specifically in our case:

The SDK runs inside GitLab CI as part of the Wrangler-based pipeline — not as a standalone replacement for anything.

Example: protect a preview URL with Zero Trust on PR open

# .gitlab-ci.yml (in shared CI library)
protect-preview:
  stage: post-deploy
  script:
    - node scripts/protect-preview.js
  variables:
    PREVIEW_URL: "${CI_MERGE_REQUEST_IID}.${CF_PAGES_PROJECT}.pages.dev"
  only:
    - merge_requests

// scripts/protect-preview.js
import Cloudflare from "cloudflare";

const cf = new Cloudflare({ apiToken: process.env.CF_API_TOKEN });

await cf.zeroTrust.access.applications.create({
  accountId: process.env.CF_ACCOUNT_ID,
  name: `Preview - MR ${process.env.CI_MERGE_REQUEST_IID}`,
  domain: process.env.PREVIEW_URL,
  type: "self_hosted",
  policies: [{ id: process.env.CF_TEAM_POLICY_ID }],
});

Verdict

6. Side-by-Side Comparison

7. Recommendation

This gives us:

• Zero IaC in app repos. App teams only write a wrangler.toml and reference the shared CI template.
• One Terraform repo. Platform team manages org-level config with full auditability and drift detection.
• Dynamic microstage automation. SDK scripts in the shared CI library handle per-PR Zero Trust policies automatically.

8. Proposed Repo and CI Structure

Repos

App repo layout

my-frontend-app/
├── src/                     ← React / Vue / etc.
├── dist/                    ← build output
├── wrangler.toml            ← Cloudflare Pages config (infra-as-code for this app)
├── package.json
└── .gitlab-ci.yml           ← references shared CI templates only

wrangler.toml example

name = "my-frontend-app"
compatibility_date = "2024-01-01"
pages_build_output_dir = "dist"

[[kv_namespaces]]
binding = "CONFIG"
id = "abc123"

[env.production]
vars = { APP_ENV = "production", API_URL = "https://api.example.com" }

[env.staging]
vars = { APP_ENV = "staging", API_URL = "https://api.staging.example.com" }

.gitlab-ci.yml example (in app repo)

include:
  - project: "platform/gitlab-ci-cloudflare"
    ref: main
    file:
      - "/templates/deploy-pages.yml"
      - "/templates/protect-preview.yml"
      - "/templates/cleanup-preview.yml"

variables:
  CF_PAGES_PROJECT: "my-frontend-app"

9. Microstage / Per-PR Environments

Microstage environments deploy a complete, independent version of the app for every open MR. Reviewers can test the exact code in the PR without running anything locally.

How Cloudflare Pages handles this natively

Every push to any branch automatically gets a unique preview URL:

https://<branch-name>.<pages-project-name>.pages.dev

No extra configuration needed. The URL is stable for the lifetime of that branch.

Full per-PR lifecycle in GitLab CI

What the shared CI templates do

Last updated: June 2026 · Owner: Platform / Infrastructure team · Feedback: open an MR against this page