Skip to content

A delivery model for small organisations: static websites on Cloudflare's edge network. No server, no database, no CMS to patch, so running costs are close to zero and the attack surface is tiny. Related: AWS CloudFront Deep Dive (the same ideas on AWS), 3. HTTP Security Headers and CSP.

Services at a glance

Need Service
Hosting and global delivery Cloudflare Pages / Workers static assets (CDN included)
DNS Cloudflare DNS
HTTPS Automatic certificates
DDoS protection Built into the edge
Source and deploys Git repository; push to deploy
Contact forms (if needed) Edge function or a form service

Why Static

Traditional site Static site
Web server, PHP / CMS, database Pre-built HTML, CSS and JavaScript files
Needs patching and backups Nothing to patch
Slower, costs a server Sub-second global loads from the CDN
More attack surface Almost none (no server-side code to exploit)

The owner receives the files in full, so there is no lock-in. Content updates are either handled for them or through a self-service CMS integration.

The Stack

  • HTML, CSS, vanilla JavaScript for pages
  • GSAP for animation and Lenis for smooth scrolling, used sparingly (see accessibility below)
  • Git repository per site; every push builds and deploys
  • Cloudflare DNS with the site's domain; HTTPS automatic
$ git push origin main          # triggers the deploy
$ npx wrangler deploy           # or deploy static assets from the CLI

Headers, Redirects and Caching

Static hosts take simple config files in the output folder:

# _headers
/*
  X-Content-Type-Options: nosniff
  Referrer-Policy: strict-origin-when-cross-origin
  Permissions-Policy: camera=(), microphone=(), geolocation=()
  Content-Security-Policy: default-src 'self'; frame-ancestors 'none'
/assets/*
  Cache-Control: public, max-age=31536000, immutable

# _redirects
/old-page    /new-page    301
  • Fingerprint asset filenames and cache them for a year; keep HTML on short caching
  • A tight CSP is easy because the site has little third-party code
  • Purge the cache from the dashboard or API after content changes if needed

A Repeatable Delivery Process

flowchart LR
    C[Conversation: needs, content] --> D[Design]
    D --> B[Build and deploy]
    B --> H[Handover: full file ownership]
  1. Conversation: understand the organisation, collect content and branding
  2. Design: pages, layout, colours, tone
  3. Build and deploy: static site, DNS, HTTPS, headers
  4. Handover: files, repository access, how to update

Quality Checks Before Launch

  • Content matches the source material (no invented stats, correct contact details, no dead links)
  • Semantic HTML, alt text, keyboard navigation, colour contrast
  • Respect reduced-motion preferences for animation (prefers-reduced-motion)
  • Optimised images (modern formats, sizes) and fonts
  • Security headers present; run a passive scan (Siteward Web Security Scanner)
  • Mobile layouts and performance checked

Where It Fits

This is the same infrastructure discipline used on larger platforms (HTTPS everywhere, headers, least privilege, repeatable deploys), applied at community scale with almost no running cost. For dynamic applications with databases, queues and background jobs, see Django on ECS Fargate - Architecture and Lessons.