Cloud infrastructure
Corporate website cloud infrastructure
Inquiries are saved in D1 before acceptance is confirmed. Queues passes the record ID to notification processing.
Keep delivery and operations on one platform
This corporate website primarily consists of static pages served through Workers Static Assets. Distribution uses Cloudflare’s network, while article publication and updates are managed in Git.
Most updates are company information and articles, so there is no always-running application server or content database for page delivery. Keeping page delivery, HTTPS and inquiry processing on one platform reduces the number of systems to check during updates and incident investigation.
Cloudflare also handles HTTPS connections and standard DDoS protection. The website and inquiry API share one domain; only requests that require inquiry processing are routed to the Worker.
Inquiry processing with D1 and Queues
The Worker validates input and Turnstile, then saves the accepted inquiry and notification state in D1 before returning success. A temporary email delivery failure should not lose an inquiry that has already been accepted.
Notification runs separately through Queues so the form response does not depend on email delivery time or temporary delivery failures. The queue carries only the stored record’s ID. A handler in the same Worker reads the content from D1 and emails a fixed recipient. Failed attempts are retried, and scheduled processing recovers inquiries that remain unnotified.
Acceptance and notification sending are tracked as separate states. Application logs record processing outcomes without inquiry content, email addresses or validation tokens.
Release checks with CI and previews
GitHub Actions runs tests and builds the website, then deploys a preview protected by Cloudflare Access. Preview storage and notification settings are separate from production.
Content and code can be reviewed in the same pull request, including Japanese and English links and mobile layouts before release. Automated checks catch structural inconsistencies; the preview provides the actual pages for visual review.
A build allowlist limits the files that can be published, excluding internal documents and credentials. After deployment, HTTP responses and the deployed commit are checked to verify that the reviewed changes are being served.
