Deployment

You have a static site ready to go. Now you need to get it live on Cloudflare Pages with a custom domain, SSL, and automated deployments. This guide covers every deployment method, DNS configuration, and CI/CD setup.

Deployment Methods

Three ways to deploy to Cloudflare Pages, from simplest to most automated:

Wrangler CLI

Best for: Quick deploys, local testing

Setup time: 5 minutes

Auto-deploy: No (manual)

Run a single command from your terminal. Fastest way to get a site live.

Git Integration

Best for: Ongoing projects with a team

Setup time: 15 minutes

Auto-deploy: Yes (on push)

Connect GitHub/GitLab for automatic deployments on every push.

Dashboard Upload

Best for: One-off deploys, no Git

Setup time: 2 minutes

Auto-deploy: No (manual)

Upload files directly through the Cloudflare Dashboard.

Method 1: Wrangler CLI

The fastest way to deploy. Run a single command from your terminal.

Install Wrangler

npm install -g wrangler

# Or as a project dependency
npm install --save-dev wrangler

Authenticate

npx wrangler login
# Opens browser -> authorize Cloudflare account

Deploy

# Deploy the public/ directory to Cloudflare Pages
npx wrangler pages deploy public

# First deploy: creates the project (prompts for project name)
# Subsequent deploys: updates the existing project

Deploy with options:

# Specify project name (skip prompt)
npx wrangler pages deploy public --project-name=my-practice-site

# Deploy to a specific branch (creates preview deployment)
npx wrangler pages deploy public --project-name=my-practice-site --branch=staging

# Deploy with a commit message
npx wrangler pages deploy public --project-name=my-practice-site \
  --commit-message="Updated contact page"

Common package.json scripts:

{
  "scripts": {
    "build": "npm run optimize:images && npm run build:site",
    "deploy": "npm run build && npx wrangler pages deploy public",
    "deploy:staging": "npm run build && npx wrangler pages deploy public --branch=staging",
    "cf:login": "npx wrangler login",
    "cf:deploy": "npx wrangler pages deploy public"
  }
}

Method 2: Git Integration (GitHub/GitLab)

Connect your GitHub or GitLab repository to Cloudflare Pages for automatic deployments on every push.

Go to Cloudflare Dashboard -> Workers & Pages -> Create
Select Pages tab -> Connect to Git
Authorize Cloudflare to access your GitHub/GitLab account
Select the repository

Configure build settings:

Setting	Value	Notes
Project name	`my-practice-site`	Becomes `my-practice-site.pages.dev`
Production branch	`main`	Deploys from this branch go live
Framework preset	`None` (static) or `Astro`	Select your framework
Build command	`npm run build`	Or leave blank for static sites
Build output directory	`public`	Where your built files live
Root directory	`/`	Or subdirectory if monorepo

Click Save and Deploy

After setup:

Push to main — automatic production deployment
Push to any other branch — automatic preview deployment
Pull request — preview URL posted as a comment

Method 3: Dashboard Upload

For sites without Git, upload files directly through the Cloudflare Dashboard.

Go to Workers & Pages -> Create -> Pages -> Upload assets
Name your project
Drag and drop your public/ folder contents
Click Deploy

Wrangler Configuration

wrangler.toml

The wrangler.toml file configures your Cloudflare Pages project. Place it in the project root.

# wrangler.toml - Cloudflare Pages configuration
name = "my-practice-site"
compatibility_date = "2026-02-11"
pages_build_output_dir = "public"

# Optional: Cloudflare account ID (useful for CI/CD)
# account_id = "your-account-id-here"

# Environment variables for build
[vars]
SITE_NAME = "My Medical Practice"
SITE_URL = "https://www.mypractice.com"

# KV Namespace bindings (if using Cloudflare KV)
# [[kv_namespaces]]
# binding = "FORM_SUBMISSIONS"
# id = "your-kv-namespace-id"

# D1 Database bindings (if using Cloudflare D1)
# [[d1_databases]]
# binding = "DB"
# database_name = "my-database"
# database_id = "your-database-id"

Key wrangler.toml Fields

Field	Required	Description
`name`	Yes	Project name (becomes `<name>.pages.dev`)
`compatibility_date`	Yes	Cloudflare Workers runtime version date
`pages_build_output_dir`	Yes	Directory containing built files to deploy
`account_id`	No	Your Cloudflare account ID (auto-detected if logged in)
`[vars]`	No	Environment variables available during build and in Functions
`[[kv_namespaces]]`	No	Cloudflare KV storage bindings
`[[d1_databases]]`	No	Cloudflare D1 database bindings

The compatibility_date determines which Cloudflare Workers runtime features are available. Use today’s date for new projects. Only update if you need newer runtime features, and test thoroughly after changing.

# Check the latest compatibility date
npx wrangler --version

Build Environment Defaults

Set these environment variables in your Cloudflare Pages project settings or wrangler.toml:

Variable	Recommended Value	Why
`NODE_VERSION`	`20` or `18`	Default 12.18.0 will break most modern builds
`NPM_VERSION`	`10`	Matches Node.js 20 LTS
`HUGO_VERSION`	`0.128.0` (if using Hugo)	Default Hugo is outdated; pin your version

wrangler.toml
Dashboard

[vars]
NODE_VERSION = "20"
NPM_VERSION = "10"

Go to Workers & Pages > Your Project > Settings > Environment Variables > Add NODE_VERSION = 20 for both Production and Preview.

Known Build Issues

Issue	Cause	Solution
Build fails with syntax errors	Default Node.js 12 doesn’t support modern JS	Set `NODE_VERSION=20`
`sharp` module fails to install	Native dependencies need correct platform	Add `npm_config_platform=linux` and `npm_config_arch=x64` env vars
Git submodules not cloned	Pages doesn’t clone submodules by default	Use `git submodule update --init` in build command
Build times out at 20 minutes	Large sites with many images	Optimize build scripts; pre-process images
Functions not deploying via Dashboard	Known Cloudflare bug	Use Wrangler CLI or Git integration instead

Git-Based Deployment

Setting Up GitHub Integration

Create a GitHub repository

# In your project directory
git init
git add .
git commit -m "Initial commit"

# Create repo on GitHub (using GitHub CLI)
gh repo create my-practice-site --private --source=. --push

Connect to Cloudflare Pages

Go to Cloudflare Dashboard -> Workers & Pages -> Create -> Pages -> Connect to Git -> Select GitHub -> Authorize the Cloudflare Pages GitHub App -> Select your repository -> Configure build settings -> Deploy.

Verify auto-deploy

# Make a change
echo "<!-- Updated -->" >> public/index.html

# Push to main
git add . && git commit -m "Test auto-deploy" && git push

# Watch Cloudflare Dashboard -> Pages -> Deployments
# Should show "Building" -> "Success" within 1-2 minutes

Auto-Deploy on Push

Once connected, every push triggers a deployment:

Git Action	Cloudflare Action	URL
Push to `main`	Production deploy	`my-site.pages.dev`
Push to `staging`	Preview deploy	`staging.my-site.pages.dev`
Push to `feature/xyz`	Preview deploy	`feature-xyz.my-site.pages.dev`
Pull Request	Preview deploy	`<hash>.my-site.pages.dev`

Preview Deployments for Branches

Every non-production branch gets its own preview URL. This is incredibly useful for staging and client review.

# Create a staging branch
git checkout -b staging
git push -u origin staging
# Preview URL: staging.my-site.pages.dev

# Create a feature branch
git checkout -b feature/new-hero
# Make changes...
git push -u origin feature/new-hero
# Preview URL: feature-new-hero.my-site.pages.dev

# Create a PR - Cloudflare posts the preview URL as a comment
gh pr create --title "New hero section" --body "Updated hero design"

Branch Deploy Controls

Limit which branches trigger deployments:

Go to Cloudflare Dashboard -> Pages -> your project -> Settings -> Builds & deployments
Set Production branch to main (or master)
Configure Preview branches:
- All non-production branches (default)
- None (disable previews)
- Include/exclude patterns (e.g., only staging and release/*)

Custom Domains

Adding a Custom Domain

Go to Cloudflare Dashboard -> Pages -> your project -> Custom domains
Click Set up a custom domain
Enter your domain (e.g., www.mypractice.com)
Cloudflare configures DNS automatically if the domain is already on Cloudflare DNS. If not, it provides CNAME records to add at your registrar.

Domain Configuration Options

Setup	Domain	DNS Record	Example
Root domain	`mypractice.com`	CNAME -> `my-site.pages.dev`	Main website
WWW subdomain	`www.mypractice.com`	CNAME -> `my-site.pages.dev`	Main website (www)
Landing page subdomain	`lp.mypractice.com`	CNAME -> `my-lp.pages.dev`	Landing pages
Staging subdomain	`staging.mypractice.com`	CNAME -> `staging.my-site.pages.dev`	Staging preview

Setting Up Both Root and WWW

Most sites should work on both mypractice.com and www.mypractice.com:

Add mypractice.com as a custom domain on your Pages project
Add www.mypractice.com as a custom domain on the same project
Cloudflare handles both — no redirect rules needed

To redirect one to the other (e.g., mypractice.com -> www.mypractice.com), use a Cloudflare Redirect Rule (Dashboard -> Rules -> Redirect Rules):

Field	Value
Rule name	Redirect root to www
When incoming requests match	Hostname equals `mypractice.com`
Then	Dynamic redirect
Expression	`concat("https://www.mypractice.com", http.request.uri.path)`
Status code	301 (Permanent)

Subdomain Setup for Landing Pages

If your main site stays on WordPress but landing pages go to Cloudflare Pages:

mypractice.com          -> WordPress (unchanged)
www.mypractice.com      -> WordPress (unchanged)
lp.mypractice.com       -> Cloudflare Pages (landing pages)

DNS configuration:

Type    Name    Content                         Proxy
CNAME   lp      my-landing-pages.pages.dev      Proxied

DNS Configuration

Adding Your Domain to Cloudflare

Two approaches depending on whether you want Cloudflare to manage all DNS:

Full DNS Migration (Recommended)
CNAME Setup (Partial)

Move your domain’s nameservers to Cloudflare. This gives you full control over DNS, CDN, security, and performance features.

Add domain to Cloudflare

Go to Cloudflare Dashboard -> Add a site -> Enter your domain (mypractice.com) -> Select the Free plan -> Cloudflare scans existing DNS records.

Review DNS records

Cloudflare imports your existing records. Verify critical records:

Type	Name	Content	Proxy Status
A	`@`	Your server IP (if WordPress still running)	Proxied
CNAME	`www`	`my-site.pages.dev`	Proxied
MX	`@`	Mail server (e.g., `aspmx.l.google.com`)	DNS only
TXT	`@`	SPF record	DNS only
TXT	`@`	Google verification	DNS only

Update nameservers at your registrar

Cloudflare provides two nameservers (e.g., ada.ns.cloudflare.com and bob.ns.cloudflare.com). Update these at your domain registrar:

Registrar	Path
GoDaddy	My Products -> DNS -> Nameservers -> Change
Namecheap	Domain List -> Manage -> Nameservers -> Custom DNS
Google/Squarespace	My domains -> DNS -> Custom name servers
Cloudflare Registrar	Already set (no action needed)

Propagation time: 1-24 hours (usually under 2 hours).

Verify activation

# Check nameservers
dig NS mypractice.com +short

# Should show:
# ada.ns.cloudflare.com.
# bob.ns.cloudflare.com.

Keep your existing DNS provider. Only point specific subdomains to Cloudflare Pages via CNAME records.

At your current DNS provider, add:

Type    Name    Value                           TTL
CNAME   www     my-site.pages.dev               3600
CNAME   lp      my-landing-pages.pages.dev      3600

Use this when: You cannot or do not want to move nameservers (e.g., complex DNS setup, multiple services on the same domain).

DNS Records Reference

Record Type	Purpose	Proxy Status	Example
A	Points domain to IP address	Proxied (for web traffic)	`@ -> 192.0.2.1`
AAAA	Points domain to IPv6 address	Proxied (for web traffic)	`@ -> 2001:db8::1`
CNAME	Points domain to another domain	Proxied (for web traffic)	`www -> site.pages.dev`
MX	Mail server routing	DNS only (never proxy)	`@ -> mail.google.com`
TXT	Verification, SPF, DKIM	DNS only	`@ -> v=spf1 include:...`
SRV	Service records	DNS only	Various

SSL/TLS

Automatic SSL Certificates

Cloudflare Pages provides free, automatic SSL certificates for all custom domains. No configuration needed.

Add a custom domain to your Pages project
Cloudflare automatically provisions a certificate (usually within 15 minutes)
Certificate auto-renews before expiration
Supports both root domain and www

SSL Modes

If using Cloudflare DNS (full migration), configure the SSL mode:

Mode	Description	Security	Recommendation
Off	No encryption	None	Never use
Flexible	Encrypted browser->Cloudflare, unencrypted Cloudflare->origin	Partial	Avoid
Full	Encrypted both ways, origin cert not validated	Good	Acceptable
Full (Strict)	Encrypted both ways, origin cert validated	Best	Recommended

Forcing HTTPS

Ensure all HTTP traffic redirects to HTTPS:

Go to SSL/TLS -> Edge Certificates -> Enable Always Use HTTPS.

/*
  Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

curl -X PATCH "https://api.cloudflare.com/client/v4/zones/{zone_id}/settings/always_use_https" \
  -H "Authorization: Bearer {api_token}" \
  -H "Content-Type: application/json" \
  --data '{"value":"on"}'

HSTS Preload

After HSTS has been active for several weeks, submit your domain to the browser HSTS preload list so browsers always use HTTPS, even on the first visit.

Ensure HSTS header includes preload directive
Submit at https://hstspreload.org/
Inclusion takes several months (added to browser source code)

Environment Variables

Setting Environment Variables

Environment variables store configuration values and secrets (API keys, site URLs) outside your code.

Go to Pages -> your project -> Settings -> Environment variables
Click Add variable
Enter name and value
Choose scope: Production, Preview, or Both

For non-secret values only:

[vars]
SITE_NAME = "My Medical Practice"
SITE_URL = "https://www.mypractice.com"
CONTACT_EMAIL = "info@mypractice.com"

# Set a secret (prompts for value, never stored in files)
npx wrangler pages secret put SENDGRID_API_KEY --project-name=my-practice-site

# List secrets
npx wrangler pages secret list --project-name=my-practice-site

# Delete a secret
npx wrangler pages secret delete SENDGRID_API_KEY --project-name=my-practice-site

Production vs Preview Variables

Different values for production and preview environments:

Variable	Production	Preview	Purpose
`SITE_URL`	`https://www.mypractice.com`	`https://staging.mypractice.com`	Canonical URL
`SENDGRID_API_KEY`	`SG.prod_key...`	`SG.test_key...`	Email delivery
`FORM_RECIPIENT`	`info@mypractice.com`	`dev@mypractice.com`	Form submissions
`ANALYTICS_ID`	`G-PROD123`	(not set)	Google Analytics
`DEBUG`	`false`	`true`	Debug logging

Accessing Variables in Cloudflare Functions

Environment variables are available in the env parameter of Cloudflare Pages Functions:

export async function onRequestPost(context) {
  const { env } = context;

  const apiKey = env.SENDGRID_API_KEY;
  const recipient = env.FORM_RECIPIENT;
  const siteName = env.SITE_NAME;

  // Use variables in your function logic
  const response = await fetch('https://api.sendgrid.com/v3/mail/send', {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${apiKey}`,
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({
      personalizations: [{ to: [{ email: recipient }] }],
      from: {
        email: `noreply@${env.SITE_URL.replace('https://', '')}`,
        name: siteName
      },
      subject: `New form submission from ${siteName}`,
      content: [{ type: 'text/plain', value: 'Form data here...' }]
    })
  });

  return new Response(JSON.stringify({ success: true }), {
    headers: { 'Content-Type': 'application/json' }
  });
}

Preview Deployments

How Preview Deployments Work

Every push to a non-production branch creates a unique preview deployment with its own URL.

flowchart TD
    A[Push Code] --> B{Which Branch?}
    B -->|main| C[Production Deploy]
    B -->|staging| D[Preview Deploy]
    B -->|feature/*| E[Preview Deploy]
    B -->|Pull Request| F[Preview Deploy]

    C --> G["my-site.pages.dev<br/>www.mypractice.com"]
    D --> H["staging.my-site.pages.dev"]
    E --> I["feature-name.my-site.pages.dev"]
    F --> J["hash.my-site.pages.dev"]

Using Previews for Client Review

Preview deployments are perfect for getting client approval before going live:

# Create a branch with changes
git checkout -b client-review/homepage-update
# Make changes...
git add . && git commit -m "Updated homepage hero and services"
git push -u origin client-review/homepage-update

# Get the preview URL from Cloudflare Dashboard
# Or use GitHub PR comments (auto-posted by Cloudflare)

Share the preview URL with clients:

"Here's a preview of the updated homepage:
https://client-review-homepage-update.my-site.pages.dev

Please review and let us know if you'd like any changes."

Preview Environment Variables

Preview deployments use their own set of environment variables:

Forms can send to a test email address instead of production
Analytics tracking can be disabled
Debug mode can be enabled

Preview Deployment Limits

Feature	Free Plan	Pro Plan
Preview deployments	Unlimited	Unlimited
Concurrent builds	1	5
Build minutes/month	500	5,000
Preview retention	30 days	30 days

Rollback Procedures

One-Click Rollback in Dashboard

Every deployment to Cloudflare Pages is preserved. Rolling back to a previous version takes seconds.

Go to Cloudflare Dashboard -> Pages -> your project -> Deployments
Find the deployment you want to revert to
Click the three-dot menu (…)
Select Rollback to this deploy
Confirm

Speed: Instant (seconds)

Git history: No change

Side effects: None

Best for: Emergencies when you need to revert immediately.

Speed: 1-2 minutes (triggers rebuild)

Git history: Creates revert commit

Side effects: Clean Git history

Best for: Planned rollbacks where you want a clean audit trail.

# Find the commit to revert
git log --oneline -10

# Revert the problematic commit
git revert abc1234

# Push to trigger auto-deploy
git push

Deployment History

Cloudflare Pages keeps a history of all deployments:

Information	Available
Deployment ID	Yes
Timestamp	Yes
Git commit hash	Yes (if Git-connected)
Branch name	Yes
Build logs	Yes
Status (success/fail)	Yes
Preview URL	Yes (each deploy has a unique URL)

CI/CD Pipeline

GitHub Actions Workflow

Automate testing and deployment with GitHub Actions. This example runs tests before deploying, ensuring broken code never reaches production.

Create .github/workflows/deploy.yml:

name: Deploy to Cloudflare Pages

on:
  push:
    branches: [main, staging]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Build
        run: npm run build

      - name: Run tests
        run: npm test

      - name: Run Lighthouse CI
        uses: treosh/lighthouse-ci-action@v12
        with:
          urls: |
            http://localhost:4173/
          configPath: '.lighthouserc.json'
          uploadArtifacts: true

  deploy:
    needs: test
    if: github.event_name == 'push'
    runs-on: ubuntu-latest
    permissions:
      contents: read
      deployments: write
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Build
        run: npm run build

      - name: Deploy to Cloudflare Pages
        uses: cloudflare/wrangler-action@v3
        with:
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
          command: pages deploy public --project-name=my-practice-site

Setting Up GitHub Secrets

Add these secrets to your GitHub repository:

Go to GitHub -> your repo -> Settings -> Secrets and variables -> Actions

Add the following secrets:

Secret Name	Value	How to Get
`CLOUDFLARE_API_TOKEN`	Your API token	Cloudflare Dashboard -> My Profile -> API Tokens -> Create Token -> “Edit Cloudflare Workers” template
`CLOUDFLARE_ACCOUNT_ID`	Your account ID	Cloudflare Dashboard -> any domain -> Overview -> right sidebar

Creating a Cloudflare API Token

Go to https://dash.cloudflare.com/profile/api-tokens
Click Create Token
Use the “Edit Cloudflare Workers” template
Modify permissions:

Resource Permission
Account -> Cloudflare Pages Edit
Account -> Account Settings Read
Zone -> Zone Read (if using custom domains)
Zone -> DNS Edit (if managing DNS via API)
Click Continue to summary -> Create Token
Copy the token immediately (shown only once)

Resource	Permission
Account -> Cloudflare Pages	Edit
Account -> Account Settings	Read
Zone -> Zone	Read (if using custom domains)
Zone -> DNS	Edit (if managing DNS via API)

Lighthouse CI Configuration

Create .lighthouserc.json for automated Lighthouse scoring:

{
  "ci": {
    "collect": {
      "numberOfRuns": 3,
      "startServerCommand": "npm run serve",
      "startServerReadyPattern": "ready",
      "url": [
        "http://localhost:4173/",
        "http://localhost:4173/about/",
        "http://localhost:4173/contact/"
      ]
    },
    "assert": {
      "assertions": {
        "categories:performance": ["error", { "minScore": 0.9 }],
        "categories:accessibility": ["warn", { "minScore": 0.9 }],
        "categories:best-practices": ["warn", { "minScore": 0.9 }],
        "categories:seo": ["warn", { "minScore": 0.9 }]
      }
    },
    "upload": {
      "target": "temporary-public-storage"
    }
  }
}

Pipeline Flow

flowchart TD
    A[Push to main] --> B[GitHub Actions Triggers]
    B --> C[Job: test]
    C --> C1[Install dependencies]
    C1 --> C2[Build site]
    C2 --> C3[Run validation tests]
    C3 --> C4["Run Lighthouse CI (must score 90+)"]

    C4 --> D{Tests pass?}
    D -->|Yes| E[Job: deploy]
    D -->|No| F[Deployment blocked<br/>Team notified]

    E --> E1[Build site]
    E1 --> E2[Deploy via Wrangler]
    E2 --> G[Live on production]

    style F fill:#fee,stroke:#f66
    style G fill:#efe,stroke:#6a6

Multi-Environment Setup

Production + Staging Architecture

A typical setup for medical practice sites with a staging environment for review:

Production

Branch: main

URL: www.mypractice.com

Vars: Production API keys, real email addresses

Deploy: Automatic on push to main (after CI passes)

Staging

Branch: staging

URL: staging.mypractice.com

Vars: Test API keys, dev email addresses

Deploy: Automatic on push to staging

Preview

Branch: feature/* or PR branches

URL: <hash>.my-site.pages.dev

Vars: Same as staging

Deploy: Automatic on push

Workflow for Changes

flowchart LR
    A[Feature Branch] -->|Push| B[Preview Deploy]
    B -->|Create PR| C[Code Review]
    C -->|Approve & Merge| D[Staging Branch]
    D -->|Auto-deploy| E[Staging Review]
    E -->|Approve & Merge| F[Main Branch]
    F -->|Auto-deploy + CI| G[Production]

# 1. Create feature branch from main
git checkout main && git pull
git checkout -b feature/update-services

# 2. Make changes, test locally
npm run build && npm run serve
# Preview at http://localhost:4173

# 3. Push feature branch (creates preview deployment)
git push -u origin feature/update-services
# Preview URL: feature-update-services.my-site.pages.dev

# 4. Create PR for review
gh pr create --title "Updated services page" --body "New pricing, updated descriptions"
# Cloudflare posts preview URL on the PR

# 5. After approval, merge to staging for final review
git checkout staging && git merge feature/update-services
git push
# Review at staging.mypractice.com

# 6. After staging approval, merge to main for production
git checkout main && git merge staging
git push
# Live at www.mypractice.com

Custom Domain per Environment

Map custom domains to specific branches:

Step 1: Add custom domains in Cloudflare Pages settings

Domain	Branch	Purpose
`www.mypractice.com`	`main`	Production
`staging.mypractice.com`	`staging`	Staging
`dev.mypractice.com`	`develop`	Development

Step 2: Add DNS records (if domain is on Cloudflare DNS)

Type    Name      Content                       Proxy
CNAME   www       my-site.pages.dev             Proxied
CNAME   staging   staging.my-site.pages.dev     Proxied
CNAME   dev       develop.my-site.pages.dev     Proxied

Environment-Specific Build Configuration

Use environment variables to control build behavior per environment:

// astro.config.mjs or build script
const isProd = process.env.CF_PAGES_BRANCH === 'main';
const isStaging = process.env.CF_PAGES_BRANCH === 'staging';

export default {
  site: isProd
    ? 'https://www.mypractice.com'
    : isStaging
      ? 'https://staging.mypractice.com'
      : 'https://dev.mypractice.com',

  // Disable analytics in non-production
  integrations: isProd ? [analytics()] : [],
};

Cloudflare Pages built-in environment variables:

Variable	Description	Example
`CF_PAGES`	Always `1` on Cloudflare Pages	`1`
`CF_PAGES_BRANCH`	Current branch name	`main`
`CF_PAGES_COMMIT_SHA`	Full commit hash	`abc123def456...`
`CF_PAGES_URL`	Deployment URL	`https://abc123.my-site.pages.dev`

Deployment Checklists

Pre-Deployment

All tests passing (npm test)
Lighthouse score 90+ mobile (npm run test:lighthouse)
All links valid (no 404s)
Forms tested and working
Images optimized (WebP, responsive)
_headers file in place (cache + security headers)
robots.txt and sitemap.xml present
Meta tags and Open Graph tags set
Favicon configured
404 page created (public/404.html)

First Deployment

Wrangler authenticated (npx wrangler login)
Project created on Cloudflare Pages
Build output directory correct in configuration
Initial deploy successful (npx wrangler pages deploy public)
Site loads at <project>.pages.dev
All pages render correctly
All assets load (images, CSS, JS, fonts)

Custom Domain Setup

Domain added to Cloudflare (nameservers or CNAME)
DNS propagation complete (dig NS yourdomain.com +short)
Custom domain added in Pages settings
SSL certificate provisioned (check HTTPS works)
SSL mode set to Full (Strict)
“Always Use HTTPS” enabled
HSTS header configured in _headers
WWW redirect configured (if desired)

Post-Deployment

Site accessible on custom domain
All pages return 200 status
Forms submit successfully and emails arrive
Security headers verified (securityheaders.com)
PageSpeed Insights score meets targets
Google Search Console updated with new sitemap
Analytics tracking verified
Old hosting decommissioned (after monitoring period)

CI/CD Setup (Optional)

GitHub repository connected to Cloudflare Pages
GitHub secrets configured (CLOUDFLARE_API_TOKEN, CLOUDFLARE_ACCOUNT_ID)
GitHub Actions workflow created and tested
Lighthouse CI configured with score thresholds
Auto-deploy on push working
Preview deployments working for branches/PRs

Quick Reference

Common Wrangler Commands

# Authentication
npx wrangler login                    # Login via browser
npx wrangler whoami                   # Check current user

# Deployment
npx wrangler pages deploy public      # Deploy public/ directory
npx wrangler pages deploy public \
  --project-name=my-site              # Specify project name
npx wrangler pages deploy public \
  --branch=staging                    # Deploy as preview (staging branch)

# Project management
npx wrangler pages project list       # List all Pages projects
npx wrangler pages project create \
  my-site                             # Create a new project
npx wrangler pages deployment list \
  --project-name=my-site              # List deployments

# Secrets
npx wrangler pages secret put \
  API_KEY --project-name=my-site      # Set a secret
npx wrangler pages secret list \
  --project-name=my-site              # List secrets
npx wrangler pages secret delete \
  API_KEY --project-name=my-site      # Delete a secret

# Local development (with Functions)
npx wrangler pages dev public         # Local dev server with Functions support

DNS Verification Commands

# Check nameservers
dig NS mypractice.com +short

# Check A record
dig A mypractice.com +short

# Check CNAME record
dig CNAME www.mypractice.com +short

# Check SSL certificate
openssl s_client -connect www.mypractice.com:443 -servername www.mypractice.com \
  </dev/null 2>/dev/null | openssl x509 -noout -subject -dates

# Check HTTP headers
curl -I https://www.mypractice.com/

Cloudflare Dashboard Paths

Task	Dashboard Path
View deployments	Workers & Pages -> your project -> Deployments
Add custom domain	Workers & Pages -> your project -> Custom domains
Set environment vars	Workers & Pages -> your project -> Settings -> Environment variables
Configure build	Workers & Pages -> your project -> Settings -> Builds & deployments
Rollback deployment	Workers & Pages -> your project -> Deployments -> … -> Rollback
View build logs	Workers & Pages -> your project -> Deployments -> click deployment
DNS management	Your domain -> DNS -> Records
SSL settings	Your domain -> SSL/TLS -> Overview