“Build on the edge” can sound like every request needs server code. Our first useful lesson was the opposite: most of the IILL brand site does not.

Pages, articles, language variants, metadata, feeds, and sitemaps can all be generated ahead of time. Serving those files directly removes a runtime step, keeps failure modes small, and makes the HTML immediately available to people, screen readers, and search crawlers.

Static first, edge when needed

The IILL site builds with Astro and publishes the resulting dist directory as Cloudflare Workers Static Assets. There is no application server in the path for ordinary page views.

Future products will still need edge behavior. Temporary publishing, rate limits, authentication, and deletion cannot be implemented as static files. Those capabilities belong in their own product services and subdomains, with their own security boundaries.

A smaller deployment surface

Keeping the brand hub static has practical benefits:

  • content deploys are deterministic;
  • localized HTML can be checked during the build;
  • canonical and hreflang links can be validated before release;
  • and no idle server or database is required for the site itself.

The architectural rule is simple: use static output for information and add runtime behavior only where a user action requires it. “Edge” is a place to run necessary logic, not a reason to create more logic.