Cloudflare and GAS — Using and Relying Are Different Things

TokiStorage uses Cloudflare Workers and Google Apps Script.
But the data meant to last forever depends on neither.

The point of this essay: TokiStorage uses Cloudflare Workers and Google Apps Script (GAS) in its operations — order processing, contact forms, page view analytics. We use them because they are convenient. But the data meant to endure a thousand years — the voice embedded in QR codes, physical products, National Diet Library deposits — depends on neither Cloudflare nor GAS. Using a service and relying on it are different things. Architecture is where you draw that line.

1. Why Cloudflare Workers and GAS

A project run by one person needs infrastructure that one person can operate. Not scale — integration.

Google Apps Script — An Entire Operations Backend in One File

The reason for choosing GAS is straightforward. Email delivery, spreadsheet storage, scheduled execution — functions that normally require three separate services are integrated into a single environment. No contracts, no configuration, zero cost.

TokiStorage's GAS script (code.gs) is 1,564 lines. Order intake, Wise payment confirmation, storage pipeline automation, daily access reports, payment reminders, monthly partner reports, newsletter auto-generation — the entire operational backbone of a one-person project fits in a single file.

Cloudflare Workers — Solved in 52 Lines

The reason for using a Cloudflare Worker is technically specific. GAS's exec URL returns a 302 redirect, which fails Wise's webhook URL validation. A 52-line proxy solves this. It handles CORS and absorbs URL changes when GAS is redeployed. Zero cost.

In short, the operational backend is Cloudflare Workers + GAS + Google Sheets. It is an external dependency. But this dependency is the result of a rational choice, not a compromise.

What a one-person project needs is not scale, but integration.
GAS provides email, spreadsheets, and scheduling in a single environment.

2. The Operational Layer and the Permanent Layer

TokiStorage's architecture has two distinct layers.

Operational Layer Permanent Layer
Purpose Order intake, inquiries, analytics Preservation of voice and existence
Dependencies Cloudflare Workers, GAS, Google Sheets QR code (physical), GitHub, NDL
Assumed lifespan Years to a decade 100 to 1,000 years
Replaceability Substitutable with other services Irreplaceable — data is self-contained
Impact if stopped New orders cannot be received None — all existing QR codes remain playable forever

This separation is the heart of the design. The operational layer may depend on external services. The permanent layer must depend on nothing.

The voice data embedded in a QR code is self-contained as URL parameters within the QR code itself. No server query is needed. Cloudflare, GAS, Google Sheets — none are involved. Scan the QR code, open it in a browser, and the voice plays.

3. What If Cloudflare Disappears

If the Cloudflare Worker goes down, the following are affected:

The following are unaffected:

Recovery is straightforward. Rewrite the forms to POST directly to the GAS exec URL, or substitute another proxy service. The Cloudflare Worker code is just 52 lines.

4. What If GAS Disappears

If GAS reaches End of Life, the following are affected:

The following are unaffected:

Alternatives exist. The GAS code is a simple 131-line script: receive form data, write to spreadsheet, send email. Equivalent functionality can be replaced with Supabase, Netlify Functions, or a simple email API.

5. Principles of Dependency Design

TokiStorage's external dependencies follow explicit principles.

Principle 1: The permanent layer depends on nothing external

QR code data is self-contained as URL parameters. Voice decoding runs in client-side WASM. Physical products are inscribed on metal. NDL deposits are made in both print and digital form. None of these are affected by the life or death of Cloudflare, GAS, GitHub, or BASE.

Principle 2: The operational layer uses what is convenient and remains substitutable

We use GAS because it is free, fast to set up, and integrates naturally with spreadsheets. We use Cloudflare Workers because it solves GAS's 302 redirect problem. Both are rational choices, but both are designed to be replaceable tomorrow.

Principle 3: Source code of dependencies is retained in-house

The GAS source code (contact-form-gas.js) is stored in the repository. The Cloudflare Worker source code (wise-webhook-proxy.js) is also in the repository. Even if the services disappear, the logic remains in our hands.

Principle 4: No secret data flows through the pipeline

Fundamentally, there is nothing in the data passing through Cloudflare Workers and GAS that would be harmful if leaked. This is the most foundational design principle of all.

If you use an external service, include the day it disappears in your design.
And never send secret data through its pipeline.

6. There Is No Data That Would Hurt If Leaked

Here is what flows from the order form through the Cloudflare Worker → GAS → Google Sheets pipeline:

Data Through pipeline Final destination
QR URL (voice data) Sent as order info Inscribed on physical product, published on GitHub (if opted), deposited to NDL (if opted)
Name & address Sent as shipping info Shipping label. Included in archive if includePersonal is selected
Storage options Sent as selections Instructions for which public preservation layers to activate
Credit card info Never passes through Entered and processed directly on Wise's platform (PCI DSS compliant)

The voice data in the QR URL is destined to be inscribed on a physical product, optionally published on GitHub, and optionally deposited to the NDL. It is data designed for public preservation. The name and address are shipping logistics — and if the purchaser chooses, they become part of the archive too.

Credit card information never touches this pipeline. Payment is completed entirely on Wise's platform. After order confirmation, a Wise payment link is emailed to the purchaser, who enters their card details on Wise. No card number is ever recorded in the Cloudflare Worker, in GAS, or in Google Sheets.

The pipeline carries no secrets — and this is not coincidence but design. The fact that preserved data is public by intent, and that payment processing is delegated to an external platform — these two design decisions create the structure that makes external services safe to use.

The origin of this design philosophy is not a technical manual — it is a cemetery. Family crests, surnames, epitaphs — whether in a temple or a public cemetery, a gravestone does not choose its viewer. It does not refuse. What is meant to endure is inscribed with the assumption that anyone may read it. TokiStorage's QR codes follow the same structure.

The best security measure is to have no secrets to protect in the first place.
Gravestones have known this for centuries.

7. Conclusion — Using and Relying Are Different Things

Using and relying are different things.

Never place what must not break on external ground.
Place what can tolerate breakage wherever is convenient.

TokiStorage uses Cloudflare Workers and GAS. This is fact.

But every QR code ever produced, every physical product ever manufactured, every newsletter deposited to the NDL — none depend on Cloudflare or GAS. If both services vanish tomorrow, nothing that is meant to endure will be lost.

This is not coincidence. It was designed this way from the start.

External services are tools. Good tools should be used. But you must never entrust your lifeline to a tool. The lifeline must remain in your own hands.

Related Essays