Skip to content

Cloudflare Infrastructure

Purpose

Account-level Cloudflare resources and how they're first provisioned - distinct from Cloudflare Platform, which covers day-to-day Workers/D1/R2 usage. This page incorporates infrastructure/cloudflare/README.md's content in full rather than discarding it - see "Original source" below for the file itself, preserved untouched.

Account-level resources

Resource Name Created by
D1 database akshaya-group-global scripts/cloudflare-bootstrap.sh, once
R2 bucket (see workers/api/wrangler.jsonc's r2_buckets[0].bucket_name) scripts/cloudflare-bootstrap.sh, once
7 Workers akshaya-group-global, akshaya-software, akshaya-logistics, akshaya-commerce, akshaya-embroidery, akshaya-admin, akshaya-investors, plus the API Worker wrangler deploy, via CI or manually
6 custom domains See Applications table custom_domain: true in each app's wrangler.jsonc, applied on deploy

Bootstrap script: scripts/cloudflare-bootstrap.sh

Run once, by whoever first provisions the Cloudflare account for this project (not part of any CI workflow):

npx wrangler whoami                                    # [READ-ONLY] confirm account first
bash scripts/cloudflare-bootstrap.sh                    # [MUTATING] [REMOTE]

What it does, in order: 1. wrangler d1 create akshaya-group-global - if this is the first run, patches the resulting database_id into workers/api/wrangler.jsonc in place of REPLACE_AFTER_D1_CREATE (via an inline Python heredoc). Already applied in this repository - a real database_id is committed; re-running wrangler d1 create today would create a second, unused database rather than patching anything further. 2. wrangler r2 bucket create <bucket> - idempotent; safe to re-run, no-ops if the bucket exists. 3. wrangler d1 migrations apply --remote - applies all pending migrations to the just-created (or existing) database.

Since the database and bucket already exist, re-running this script today is only useful for step 3 (applying any new migrations) - and deploy-cloudflare.yml's deploy-api job already does that on every manual deploy, and ci.yml's deploy-production does it on every push to main. There is normally no reason to run this script again by hand.

Custom domains and routes

Each app's wrangler.jsonc declares its own routes entry with custom_domain: true - Cloudflare handles the DNS + TLS + routing automatically once the Worker is deployed with that config; no separate manual DNS step is documented or required. See Cloudflare Platform → Domains for the exact domain list and per-app routing detail.

Original source: infrastructure/cloudflare/README.md

The original bootstrap notes remain in the repository, unmodified, at infrastructure/cloudflare/README.md. It lists 5 of the 7 domains (predates the Embroidery and Admin apps) - this page and Applications are the up-to-date reference; the original file is kept as historical/source material, not deleted or rewritten in place.

Security considerations

  • The bootstrap script requires an account-scoped CLOUDFLARE_API_TOKEN capable of creating D1 databases and R2 buckets - broader than the token scoped for routine deploys. Use a separate, narrowly-scoped token for this one-time step if practical, per Security.
  • Never re-run wrangler d1 create/wrangler r2 bucket create against production without first confirming (wrangler whoami, wrangler d1 list) which account you're authenticated against.