Skip to content
digizeDocs

How sites work

Every site is a Cloudflare Worker in Digize’s Workers for Platforms namespace. Digize builds it from the site’s git repository and uploads it under a script name made from the workspace and site ids, the same name every time, so a new version is live from the next request.

Kinds of Workers

Section titled “Kinds of Workers”

The Sites › Workers page lists four kinds. A Worker you create from scratch is a site; a template can make one of the others.

Kind Answers on a hostname Used for
site Yes Pages, a storefront, anything a browser opens.
api Yes An HTTP API of your own.
consumer No Taking messages off a queue.
scheduled No Running on cron triggers.

A site or API gets the address <name>.yourfreesite.com when it’s made. Any Worker can have cron triggers and bindings.

A visitor’s request

Section titled “A visitor’s request”

Every request to *.yourfreesite.com, or to one of the workspace’s own domains, reaches Digize’s Dispatch Worker first:

  1. Dispatch looks up the hostname. A hostname nobody has is a 404 Site not found page. A route can hand a path of the hostname to another of the workspace’s Workers; otherwise the hostname’s own site answers.
  2. The analytics paths, /_platform/t/… and /_platform/e, and /_platform/g/… when the workspace has a GA4 property, are answered by Dispatch itself and never reach the site (Analytics).
  3. Paths only scanners ask for, such as /wp-admin, /.env and /config.json, get a 403 without running the site (Limits).
  4. If the workspace has click protection on (Ads), listed addresses and, with the traffic shield, scripted clients are turned away.
  5. The site’s Worker runs, within the per-request limits. Its response gets an x-digize-site header with the site’s id. Before the first deploy, the answer is a 404 Not deployed yet page; a Worker that throws gets a 503.
  6. HTML pages get the analytics tracker in their <head>, and the request is logged for the workspace’s traffic reports.

What a Worker can reach

Section titled “What a Worker can reach”

Every fetch a site’s Worker makes goes through Digize’s Outbound Worker, which knows which site is calling from Dispatch, never from the site’s own code:

  • The platform paths. A fetch to /_platform/… on the site’s own hostname, or on https://digize.com, is answered by Digize: the site’s identity, forms, the storefront and reviews (Platform paths). The site never holds a key for them.
  • The App Worker. Any other request to https://digize.com carries a signed copy of the site’s identity in x-digize-site-context, replacing any the site set, and loses its cookie and authorization headers.
  • The internet. Everything else goes out as it is, to public addresses only: localhost, private and link-local ranges and other internal names answer 403 Requests to this address are blocked. Outbound doesn’t follow redirects itself, so each hop is a new request that passes the same checks.

A Worker reaches its own storage through the bindings its config declares or the Worker’s Bindings tab adds, and its variables and secrets through env.

Where to go next

Section titled “Where to go next”