Static Business Website with Edge Delivery, Contact Form, Analytics, and CI Deployment

Architecture

Visitors request static HTML, CSS, JavaScript, and media from Cloudflare Pages. Cloudflare is configured in future implementation work as the public DNS/edge layer and CDN for the custom domain. The static contact form submits HTTPS requests to a Cloudflare Worker endpoint rather than exposing email-provider credentials in browser code. The Worker must validate the submitted Turnstile token server-side, apply strict input validation and rate controls implemented in application logic where feasible, then send a sanitized notification through Resend.

Reliable contact delivery requires a durable transactional submission/outbox store, which is an implementation prerequisite not supplied by the current component catalogue. The Worker must accept a client-generated idempotency key, atomically persist the validated inquiry and an outbox record before attempting delivery, and retain states such as pending, sending, sent, unknown, and error with attempt metadata and any provider message identifier. A future scheduled recovery invocation of the Worker must reclaim expired sending leases and reconcile unknown outcomes through supported Resend lookup, idempotency, or delivery-status behavior where available. If reconciliation or provider-side deduplication is unavailable, delivery is at-least-once and duplicate notifications require documented operator resolution; exactly-once delivery is not claimed. The UI may state that an inquiry was recorded or that a send attempt was accepted by the provider, but must not claim inbox receipt unless verified delivery-status handling is implemented. Ambiguous and failed states must show a non-success/pending outcome and retain the visible fallback contact method.

The browser loads the Plausible Analytics tracking integration only after the project defines its consent and privacy requirements. GitHub holds the site source and future CI configuration; a successful CI build should publish generated static assets to the selected deployment target through credentials configured outside the repository. Dependencies and deployment compatibility must be validated during implementation rather than assumed from this design. Static-site rollback should be performed by redeploying a previously known-good source revision after the team establishes and tests a rollback procedure. Analytics failure must not block rendering or submission of the contact form.

Implementation sequence

• Define the site's information architecture, visual content, contact recipient mailbox, privacy notice, cookie/consent position, accessibility acceptance criteria, fallback contact method, and user-visible definitions for recorded, provider-accepted, pending, failed, and ambiguous contact outcomes.
• Create a static-site repository in GitHub. Keep the site build output reproducible from source, pin or review third-party front-end dependencies, and prohibit secrets from the repository and generated client assets.
• Implement the business pages as static HTML/CSS/JavaScript or a static export. Optimize images, provide descriptive alternative text, use semantic headings, and ensure the site remains usable without analytics scripts.
• Configure a future CI workflow in GitHub to install dependencies, run project-defined checks, build static assets, and deploy only from approved branches. Store deployment credentials in protected CI secrets.
• Set up Cloudflare Pages as the static deployment target and configure preview versus production deployment policy. Connect the production custom domain only after domain ownership, DNS records, TLS behavior, redirect policy, and cache invalidation/rollback procedures have been reviewed.
• Configure Cloudflare edge/CDN behavior deliberately: force HTTPS, define canonical-host redirects, cache only immutable or safe static assets, and avoid caching contact-form POST responses. Validate headers and redirects in preview or staging before launch.
• Before enabling the contact form, provide durable transactional storage for inquiry and outbox state; do not represent email alone as durable submission storage. Define retention, access, deletion, and operator ownership for submission records, outbox records, attempt metadata, and unresolved unknown states.
• Build the Worker contact endpoint with an explicit request schema, allowed origins, request-size and field-length limits, a rate-limiting strategy, safe errors, and a client-generated idempotency key. Atomically create or return the existing submission/outbox record for that key; bind the key to the validated request so reuse with different content is rejected.
• Add Turnstile and verify it in the Worker before trusting payload fields or changing submission state. Treat missing, invalid, expired, or unverifiable tokens as failed submissions. Implement an outbox state machine: persist pending before send; atomically claim work with a lease as sending; record provider acceptance as sent; record definite failures as error; and record timeouts, lost responses, and crash-window outcomes as unknown rather than sent or failed.
• Configure Resend credentials as protected Worker secrets. Normalize and validate fields, construct a fixed-format email, and use a provider request idempotency mechanism only when its documented behavior is validated. Persist the provider message identifier and outcome before finalizing state where possible. Provider request idempotency is separate from the application's contact-submission deduplication.
• Configure a future scheduled recovery invocation to process pending work, reclaim expired sending leases, and reconcile unknown outcomes using supported provider identifiers, lookup, idempotency, or delivery-status behavior. Where no supported reconciliation exists, retry only under the documented at-least-once policy, retain the operator-review queue, and document duplicate-notification resolution.
• Return a recorded/pending response only after durable persistence succeeds. Return a provider-accepted response only after that acceptance is durably recorded. Do not report inbox delivery without verified provider delivery-status handling; show the fallback contact method for failures and unresolved ambiguity.
• Add Plausible Analytics according to the selected privacy and consent policy. Confirm during implementation that rendering, navigation, and contact behavior continue if analytics is blocked or unavailable.
• Before launch, perform and document checks for mobile layout, keyboard navigation, form validation, bot-defense failure handling, idempotent retry behavior, crash/timeout and unknown-outcome recovery, email receipt and deliverability, custom-domain TLS, redirects, caching, and rollback from a prior repository revision.
• Document ownership for domain renewal, Cloudflare, GitHub, Resend, analytics, durable submission storage, and recovery operations; establish access revocation, incident handling, content updates, outbox-review procedures, and periodic restore/rollback drills.

Security and operations

• Do not expose Resend API credentials, Turnstile secret values, deployment tokens, analytics administrative credentials, or durable-store credentials in browser code, committed files, build logs, or public issue trackers. Store them only in relevant protected secret facilities.
• The Worker must verify Turnstile over the server-side request flow before trusting submitted fields or creating/changing inquiry state. A browser-side challenge alone is not sufficient.
• Validate and constrain every contact field and idempotency key server-side. Reject unexpected fields and content types, enforce bounded request sizes and field lengths, prevent a key from being reused for different validated content, and avoid interpolating visitor input into email headers or HTML email bodies.
• Use a fixed recipient allowlist in Worker configuration. Do not permit client-supplied recipient addresses, templates, redirect URLs, or email headers.
• Protect durable inquiry/outbox records with least-privilege access and defined retention/deletion rules. Recovery processing must use atomic claims or leases so concurrent executions and duplicate requests cannot both finalize the same record; expired leases must be reconciled as potentially unknown, not assumed failed.
• Treat a provider timeout, lost response, or Worker crash after transmission as an unknown outcome. Do not mark it sent, completed, or safe to retry until supported reconciliation occurs; if reconciliation is unavailable, preserve the at-least-once record and operator-resolution path.
• Use HTTPS for the public domain and contact endpoint. Future implementation must configure and test DNS, certificate issuance/renewal behavior, canonical redirects, and selected security headers.
• Collect the minimum contact and analytics data needed. Publish retention, access, deletion, and consent decisions appropriate to the business's legal and privacy obligations; those policies are not supplied by this stack.
• Restrict GitHub repository write access and deployment privileges. Require review for production changes where the team's process supports it, and rotate credentials when staff or vendors lose access.
• Contact details sent by email and retained in submission state may contain personal data. Limit inbox and record access, enable available mailbox authentication controls, and define retention/deletion procedures.

Limitations

• The catalogue does not identify a durable transactional datastore or queue for contact-submission/outbox state. Reliable recorded submissions, crash recovery, and reconciliation cannot be implemented from email alone; selecting and operating compatible durable storage is an unimplemented prerequisite, not an included component.
• The catalogue does not identify a dedicated static-site generator, domain registrar, business mailbox provider, consent-management tool, password manager, backup product for GitHub/Cloudflare configuration, or uptime monitoring service. These are external operational dependencies or future decisions, not included required components.
• Cloudflare Pages, Cloudflare, Workers, Turnstile, Resend, GitHub, and Plausible account setup, custom-domain linkage, credentials, service-region choices, provider terms, quotas, compatibility details, and Resend idempotency, lookup, and delivery-status behavior must be checked during implementation. This design does not assert that any integration has been configured or tested.
• Absent validated provider reconciliation or deduplication, outbound notifications have at-least-once semantics and can duplicate after unknown outcomes. Provider acceptance is not proof of inbox receipt; unresolved records require retention and operator review.
• A public contact form can still receive unwanted traffic despite challenge and validation controls. Rate limits, abuse thresholds, recipient inbox rules, response procedures, recovery cadence, and operator escalation need to be selected and tested for expected traffic.
• CI is described as future workflow configuration in GitHub. The exact build tooling, test suite, branch protections, secrets model, approval gates, artifact retention, and rollback procedure remain unimplemented operational prerequisites.
• CDN caching can delay content changes if cache policies are overly broad. Cache-control rules, purge authority, deployment ordering, and rollback behavior require documented validation before launch.
• Analytics and contact handling may create privacy, consent, accessibility, and data-residency obligations that vary by audience and jurisdiction. Legal review is outside the supplied catalogue and has not been performed.

Alternatives to consider

• Use product 47 Netlify or product 46 Vercel as an alternative managed deployment platform after evaluating static deployment, custom-domain, CI, and contact-handling requirements; do not run multiple hosting platforms unless there is a defined migration or resilience need.
• Use product 96 Bunny CDN as an alternative CDN provider if a separate CDN is desired, with hosting/origin integration and cache invalidation tested as implementation work.
• Use product 59 Matomo or product 97 Umami instead of Plausible Analytics when the desired analytics hosting model or data-control requirements favor those products.
• Use product 13 SendGrid or product 12 Postmark instead of Resend if evaluated email-delivery requirements favor them.
• Use product 76 hCaptcha instead of Turnstile if its challenge model is selected after accessibility, privacy, and abuse-resistance evaluation.