← We The People Platform Download .docx

Technical Configuration Specifics for Cloudflare-Based Deployment

v1.0 · Created May 10, 2026 for v3.7.20 (companion technical reference to 05_Milestone_B1_Execution_Checklist.docx; consolidates hosting-specific configuration details into a focused quick-reference document) · Jason Robertson · Ohio · 2026

Purpose

This document is a technical quick-reference for the platform's hosting infrastructure setup. It supplements the Milestone B1 Execution Checklist (05_Milestone_B1_Execution_Checklist.docx) by consolidating the technical configuration specifics for domain registration, hosting (Cloudflare Pages), DNS setup, and email routing into one focused reference. The B1 checklist provides the broader publication workflow (archival, citations, bio, license, announcement); this document is the deeper hosting-only reference the lead author can consult while executing Steps One, Two, and Seven of the B1 checklist.

Scope: this document covers domain, hosting environment, DNS configuration, custom domain attachment, SSL/TLS configuration, email routing, optional Git-based deployment workflow, and verification at each step. Out of scope: archival deposits (covered in B1 Steps Three and Four), citation metadata (covered in B1 Step Five), bio/license/contact policy decisions (B1 Steps Six through Eight), and announcement strategy (B1 Step Nine).

Architecture Overview

The platform's web infrastructure consists of three Cloudflare services configured under a single Cloudflare account: Cloudflare Registrar (the domain), Cloudflare Pages (static site hosting for the GUI navigator and supporting pages), and Cloudflare Email Routing (forwarding email at the platform's domain to the lead author's existing inbox). All three are operated through the same Cloudflare dashboard, share a single billing relationship, and interoperate without requiring third-party glue services. Total expected monthly cost at low-to-moderate traffic: approximately $0 (free tier) for hosting and email routing; the only recurring cost is the domain renewal (approximately $10 per year at wholesale registrar pricing).

The choice of Cloudflare for all three services is deliberate: the integration eliminates several common failure modes that occur when domain, hosting, and email are managed across different providers (DNS misconfiguration during transfer, TLS certificate gaps during cutover, email-routing delays from MX-record propagation across vendors). Alternative providers exist (GitHub Pages, Netlify, Vercel, Cloudflare Workers, S3 + CloudFront) and would also work; this document specifies the Cloudflare path because it produces the lowest configuration overhead for a static-content platform with low expected traffic.

Step One Technical: Domain Registration

Prerequisite: a Cloudflare account. If one does not exist, create one at dash.cloudflare.com before proceeding. The same account will be used for registrar, hosting, and email routing.

Domain Registration Action Steps

First: in the Cloudflare dashboard sidebar, select Domain Registration, then Register Domains. Second: search the chosen domain name. Third: review the wholesale price (typically $9 to $15 per year for common TLDs such as .org, .com, .net, and .info; .org is recommended for a non-commercial policy platform but any TLD works). Fourth: complete the registration form with the lead author's contact information; confirm that WHOIS privacy is enabled (Cloudflare enables it by default; verify on the registration confirmation screen). Fifth: complete payment; the domain typically activates within five to thirty minutes.

Verification at End of Step One

Verification one: the domain appears in the Cloudflare dashboard Domain Registration page with status 'Active'. Verification two: a WHOIS lookup for the domain (whois.icann.org/lookup) returns Cloudflare's privacy-proxy values for the registrant rather than the lead author's personal contact information. Verification three: the domain's nameservers in the Cloudflare dashboard are set to Cloudflare's nameservers (typically two values ending in .ns.cloudflare.com); this happens automatically for domains registered with Cloudflare Registrar but is worth confirming.

Step Two Technical: Cloudflare Pages Project Setup

Goal: create a Cloudflare Pages project that serves the platform's static content (the GUI navigator HTML, the calculator HTML, citation pages, bio, license, and the downloadable package zip). The project pulls source content from either a Git repository (recommended for ongoing updates) or a direct upload (simpler for one-time deployment).

Decision: Git-Based or Direct-Upload Deployment

Recommendation: Git-based deployment. The Git approach connects the Cloudflare Pages project to a public or private GitHub repository; every push to the chosen production branch triggers an automatic rebuild and deploy. This eliminates the need to remember to upload files when the platform is updated. The direct-upload alternative requires zipping the deployment bundle locally and dragging it into the Cloudflare Pages dashboard each time; this is workable but adds friction to every iteration.

If choosing Git-based deployment: prerequisite is a GitHub account and a repository containing the platform's web-facing files (the GUI navigator HTML, calculator HTML, and any supporting assets). The repository can be public (which makes the platform's source code transparent and citable; consistent with the platform's open-publication intent) or private (which still works for Cloudflare Pages deployment but limits external auditing of source). Recommended: public repository under the lead author's GitHub account.

Cloudflare Pages Project Creation

First: in the Cloudflare dashboard, select Workers and Pages from the sidebar, then Create application, then Pages, then Connect to Git (or Upload Assets for direct-upload). Second: if using Git, authenticate with GitHub and select the platform repository. Third: configure the build settings (see next section for specifics). Fourth: click Save and Deploy. The first deployment typically completes in one to three minutes; subsequent deploys are faster (often under a minute) because Cloudflare caches dependencies.

Build Settings

For a static site with no build step (the GUI navigator and calculator are plain HTML files, so no compilation is needed): Production branch: 'main' (or whatever branch the lead author treats as production). Framework preset: None. Build command: leave blank. Build output directory: leave blank (or '/' which is equivalent; means serve files from the repository root). Root directory (advanced): leave blank. Environment variables: none required for this setup.

If the platform later adopts a static-site generator (such as Hugo, Eleventy, or Astro) the build settings would change: build command would be the generator's build command (for example 'hugo' or 'npm run build'), and build output directory would be the generator's output folder (typically 'public/' or 'dist/'). This is not required for the initial deployment.

Custom Domain Attachment

After the first successful deployment, the project is reachable at a Cloudflare-provided subdomain (typically project-name.pages.dev). Attach the platform's custom domain in three actions. First: in the project page, select Custom domains, then Set up a custom domain. Second: enter the apex domain (for example wethepeopleplatform.org without any subdomain prefix). Third: Cloudflare automatically provisions the required DNS records (CNAME for the apex via Cloudflare's flattening feature; Cloudflare handles this differently from other DNS providers and the lead author does not need to manually configure CNAME-flattening). Fourth: optionally repeat the process to attach a 'www' subdomain (recommended; redirects www.wethepeopleplatform.org to wethepeopleplatform.org by default).

SSL/TLS Configuration

After custom-domain attachment, Cloudflare automatically issues a Universal SSL certificate for the domain. This takes approximately five to fifteen minutes to provision. During this window, the domain may be reachable via HTTP but not HTTPS; this is normal and resolves automatically. Verify in the project Custom domains page that the certificate status is 'Active' before announcing the platform externally.

SSL/TLS encryption mode (set in Cloudflare dashboard, SSL/TLS section, Overview): 'Full (strict)' is the correct setting for Cloudflare Pages. The 'Flexible' and 'Off' modes are inappropriate for the platform's use case (they would expose the connection between Cloudflare and the lead author's origin to unencrypted transit, even though for Pages-hosted sites the origin is also Cloudflare so this is less critical; 'Full (strict)' is the correct convention regardless). 'Full' (without strict) is also acceptable but provides slightly weaker verification than 'Full (strict)'.

Verification at End of Step Two

Verification one: the custom domain resolves to the Cloudflare Pages project (visit https://wethepeopleplatform.org or equivalent and confirm the GUI navigator displays). Verification two: the page loads over HTTPS with a valid certificate (browser shows the lock icon, no warnings). Verification three: the calculator page loads as well (visit /calculator.html or equivalent path). Verification four: the platform's downloadable zip is accessible via a direct URL (/We_The_People_Platform_v3_7_X.zip or equivalent). Verification five: the project's Deployments tab shows the most recent deploy with Status 'Success'.

Step Seven Technical: Cloudflare Email Routing

Goal: enable email addresses at the platform's domain (for example contact@wethepeopleplatform.org) to forward to the lead author's existing inbox without requiring a separate mail-server setup. Cloudflare Email Routing provides this as a free service.

Email Routing Setup Action Steps

First: in the Cloudflare dashboard, select the platform's domain, then Email, then Email Routing. Second: click Get Started or Enable Email Routing. Third: Cloudflare prompts to add the required DNS records (typically three MX records and a TXT record); accept the prompt to add them automatically. Fourth: configure a destination address by clicking Destination addresses, then Add destination address; enter the lead author's personal email address. Fifth: Cloudflare sends a verification email to the destination address; click the verification link to confirm ownership. Sixth: configure a custom address by clicking Routes, then Create address; enter the local-part (for example 'contact'), select the verified destination, and save.

Recommended at minimum: one custom address for general contact (contact@platformdomain.org or info@platformdomain.org). Optionally: a second address for the lead author's name (jason@platformdomain.org for example), routed to the same destination; this provides a more personal contact mechanism for direct outreach to the lead author. Optionally: a catch-all address (configured by selecting Catch-all in Routes settings) that routes anything-else@platformdomain.org to the destination; this is useful for catching typos or addresses that congressional staff might guess, but increases spam exposure.

Verification at End of Step Seven

Verification one: send a test email from a personal account to the configured custom address (contact@platformdomain.org). Verification two: confirm the email arrives at the destination inbox within approximately one minute (Cloudflare Email Routing is typically near-instant). Verification three: in the Cloudflare dashboard, Email Routing page, the Activity tab shows the test email with Status 'Delivered'. Verification four: send a reply from the destination inbox; confirm it delivers to the test sender (the From line will show the destination's actual email, not the platform domain, because Cloudflare Email Routing is forwarding-only and does not provide outbound SMTP; this is acceptable for the platform's use case).

Optional: Git-Based Continuous Deployment Workflow

Skip this section if direct-upload deployment was chosen in Step Two. For Git-based deployments, the following workflow produces low-friction iterative updates.

First: clone the platform repository to the lead author's development machine. Second: make changes to the platform's web-facing files locally. Third: test changes locally by opening the modified files in a browser (file:// URLs work for simple static testing; for more accurate testing, run a local web server with 'python3 -m http.server' from the repository root). Fourth: commit changes with a descriptive message. Fifth: push to the production branch; Cloudflare Pages automatically rebuilds and deploys. Sixth: monitor the deploy at the project's Deployments page; if the deploy fails, the page shows the error log.

For platform-package updates (when a new iteration is shipped): the deployment bundle's contents are pushed to the repository, replacing the previous version's files. The downloadable zip is uploaded as a new file (with the iteration version in the filename) and the GUI navigator's download link is updated to point to the new zip. The repository keeps prior versions for historical reference; the GUI navigator surfaces the current version while archived versions remain accessible by their version-suffixed filenames.

Cost Expectation Summary

Domain registration and renewal: approximately $9 to $15 per year, paid annually, at Cloudflare Registrar's wholesale pricing. Cloudflare Pages hosting: $0 per month at the platform's expected traffic level. The free tier supports five hundred builds per month and unlimited bandwidth; the platform's iteration cadence and traffic are both far below those limits. Cloudflare Email Routing: $0 per month. There is no free-tier limit that the platform's email volume is likely to approach. Total expected first-year cost: approximately $10 (domain registration). Total expected ongoing yearly cost: approximately $10 (domain renewal). No other recurring costs.

Costs would increase only if the platform adopts paid features that exceed free tier limits: Cloudflare Workers (server-side execution beyond static content; not required for the platform as currently designed), Cloudflare R2 storage (large-file hosting; the zip files are small enough to fit within Pages' free-tier limits), or premium DNS features (not required). None of these are anticipated under the current platform architecture.

Failure Mode and Recovery Notes

Failure mode one: deployment fails after a push. Recovery: review the deployment log in the Cloudflare Pages project's Deployments page; the failure is typically a syntax error in an HTML file or a missing file referenced by a relative link. Fix locally, commit, push again. Cloudflare Pages keeps the previous successful deployment live until the new one succeeds, so the platform remains available during fixes.

Failure mode two: custom domain stops resolving. Recovery: check the Cloudflare Pages project's Custom domains page; the domain status should be 'Active'. If status is 'Pending' or shows an error, the most common cause is that DNS propagation is still in progress (allow up to twenty-four hours for global propagation, although Cloudflare-managed DNS is usually much faster). If status shows 'Verification failed' or similar, the domain may have been removed from the project; re-add it via the Custom domains page.

Failure mode three: SSL certificate expired or not provisioning. Recovery: Cloudflare auto-renews Universal SSL certificates; expiration is extremely rare in normal operation. If certificate status shows 'Not provisioning' or 'Failed': check the SSL/TLS section of the dashboard, ensure Universal SSL is enabled, and wait approximately fifteen minutes; if the issue persists, contact Cloudflare support (free-tier customers have access to the community forum and basic ticket support).

Failure mode four: email forwarding stops working. Recovery: check Email Routing Activity tab for delivery errors. Most common cause: the destination inbox marked Cloudflare-forwarded messages as spam and the spam filter expanded to the entire forward stream. Whitelist the platform domain in the destination inbox's spam filter. Second most common cause: MX or TXT records were accidentally modified or removed; the Email Routing page shows the required records and allows re-adding them with one click.

Integration with Milestone B1 Checklist

This document supplements the Milestone B1 Execution Checklist. When executing the B1 checklist, consult this document at the following points. B1 Step One (Domain Registration): consult the Step One Technical and Verification at End of Step One sections of this document for the specific dashboard navigation and verification steps. B1 Step Two (Hosting Setup): consult Step Two Technical (Cloudflare Pages Project Setup, Build Settings, Custom Domain Attachment, SSL/TLS Configuration) for the specific Cloudflare Pages configuration. B1 Step Seven (Contact Mechanism): consult Step Seven Technical (Cloudflare Email Routing) for the email routing setup. The B1 checklist's other steps (archival, citations, bio, license, announcement) are not covered here and should be executed per the B1 checklist directly.

Related Documents

05_Milestone_B1_Execution_Checklist.docx: the broader publication workflow this document supplements. 05_What_Done_Looks_Like.docx: the decision framework that defines Milestone B1 satisfaction criteria. The platform's deployment bundle (delivered as part of the v3.3.1 and later iterations): contains the files to be deployed at the hosting environment configured by this guide. 00_GUI_Files/index.html and supporting JavaScript: the GUI navigator that becomes the platform's primary web entry point once hosted.