Deconstructing this website
This is how this website is built. It runs on Cloudflare, a network of data centres around the world, and every claim on this page links to the file that proves it.
Four layers, on Cloudflare
layer 1 · Cloudflare
The network
How a visit reaches this website.
When you type the address, Cloudflare's DNS answers. The zone is signed with DNSSEC, a signature that lets anyone check the answer was not altered on the way. The connection is encrypted with TLS 1.3 at the least, and in browsers that support it not even the site's name travels in the clear. On the other side there is no server of our own: a Worker answers, a program Cloudflare runs in the data centre closest to the visitor.

Cloudflare dashboard: TLS 1.3 as the minimum, and Encrypted Client Hello on.Detail and proof 2 rows
- 1.1
DNS is authoritative on
Cloudflare, and the zone is signed withDNSSEC.no file: checked in the zone's APIDNS full setup · DNSSEC - 1.2
TLS 1.3 is the minimum version the zone accepts.
Encrypted Client Hellois on. Clients that support it also get the post-quantum key agreementCloudflareoffers by default.no file: checked in the zone's APIMinimum TLS · Encrypted Client Hello · post-quantum
layer 2 · Cloudflare
The cache
Which pages are kept ready-made, and when they are cleared.
In front of the Worker sits Cloudflare's cache, which keeps copies of pages in each data centre. If the page you ask for is already stored, it is delivered without running the Worker. Only pages that ask for it are stored, and publishing a change from the content management system (the CMS) clears, by tag, that page and every page that lists it.
Detail and proof 5 rows
- 2.1
Workers Cachesits in front of the Worker and is tiered by default: a hit does not run the Worker. - 2.2
A rendered page is cached at the edge only if it opts in. Every other rendered response is sent
no-store. - 2.3
Publishing an entry purges, by cache tag, its own pages and the pages that list it. Menus and settings are not purged; they expire within the hour.
- 2.4
Build output under
/_astro/is content-hashed and served with a one-year, immutable max-age. - 2.5
Resized images are kept in the
Cache API.no file: in the@astrojs/cloudflaredependencyCache API
layer 3 · Cloudflare
Compute
Where the code that builds each page runs.
The whole site is produced by a single Worker with Astro, a framework that assembles each page at the moment it is requested. Files that never change, such as styles, scripts and images, are served directly, without running any code. There is no server behind it, and before answering the Worker adds seven security headers to every page.
Detail and proof 5 rows
- 3.1
One
Workerrenders the pages on demand withAstro(SSR). The built files are served asWorkers Static Assetswithout running it. There is no server behind the Worker. - 3.2
The team that makes
Astrohas worked atCloudflaresince January 2026.Astroremains MIT-licensed and openly governed.no file: per the announcementannouncement - 3.3
One middleware stamps 7 security headers on every page the Worker renders. The CSP admits no third-party script.
- 3.4
The Worker knows the visitor's city and which
Cloudflaredata centre answered (request.cf). The edge-security opening shows them. - 3.5
CMS plugins can run in their own
Dynamic Worker, with no network of their own and fixed CPU, subrequest and time limits. Everything they do passes through a bridge that checks the capabilities each one declares.
layer 4 · Cloudflare
Data
Where each thing is kept.
The texts and their history live in D1, Cloudflare's SQLite database. Editors' sessions are kept in Workers KV, a key-value store; Images crops each picture to its slot and turns it into WebP; and R2, the file storage, is ready for whatever is uploaded through the CMS. The preview and production share none of the four.

Worker bindings in the Cloudflare dashboard. The sixth, ASSETS, is added by the Astro adapter at build time.Detail and proof 5 rows
- 4.1
D1(SQLite) holds the content, its revisions and the settings. Each request opens aD1session. - 4.2
Workers KVholds the editors' sessions. - 4.3
The Worker hands each image to the
Imagesbinding, which resizes it to its slot and converts it to WebP. - 4.4
R2is wired as the CMS media store. Today every image on the site ships with the code. - 4.5
Preview and production each have their own
D1,Workers KVandR2.
Inside the Worker
inside the Worker
Presentation
How what you see is drawn.
The interface is built with Astro and a single stylesheet. Fonts, scripts and images come from the site itself, asking nothing of third parties. The openings of each section pair restored photographs with a drawing animated in the browser.


Detail and proof 6 rows
- 5.1
One stylesheet declares every colour, radius and shadow, the column width and the spacing scale. CI rejects those values written anywhere else, except in marked blocks that imitate another product's interface.
- 5.2
Loading a page makes no third-party request. Fonts, scripts and images are all the site's own.
- 5.3
The fonts live in the repository, so building the site does not depend on
Google Fonts.Cloudflare Fontsdoes not apply: it only rewrites links toGoogle Fonts, and there are none here. - 5.4
Each vertical opens with a Wikimedia Commons photograph, restored and partly redrawn, and a layer drawn live in the browser. The layer is placed against the measured text, and its clock stops at eight seconds: nothing loops.
- 5.5
The photographs were restored locally with SeedVR2. FLUX.2 [dev] (Black Forest Labs) on
Workers AIremoved objects, extended frames and redrew from the photographs. Every prompt is in the repository.docs/design/hero-rotativo/photo_restore.py[FLUX.2 [dev]](https://developers.cloudflare.com/workers-ai/models/flux-2-dev/) - 5.6
The photographs are CC BY-SA, and the site credits them with the changes stated.
inside the Worker
The CMS: EmDash
Where the content is edited.
The site's CMS is EmDash, Cloudflare's open-source content management system, and it runs inside the same Worker that serves the pages. Its admin edits pages, services, menus and every interface label, in Spanish and English. On publishing, a plugin kept in the repository clears what changed from the cache.

EmDash editor, in the site's admin.Detail and proof 7 rows
- 6.1
EmDash, the open-source (MIT) CMS thatCloudflareannounced in April 2026, runs inside the same Worker. - 6.2
Cloudflareruns its own blog onEmDash.no file: per its blogthe Cloudflare blog - 6.3
Five content types: pages, services, members, references and partners, with blog posts ready and empty. Pages and services have drafts; those two and members keep revisions. Bodies are Portable Text.
- 6.4
Two languages: pages, services and members are published in pairs linked by
translationOf. - 6.5
Menus, widget areas, site settings and taxonomies come from the CMS. Every interface label lives in a widget, not in a template.
- 6.6
Search comes from
EmDash, onSQLiteFTS5 with bm25 ranking.no file: inEmDash, migration 064 - 6.7
A plugin kept in the repository purges the cache on publish. It declares
content:read, because without itEmDashskips its hooks.
Across the layers, from the workshop
across the layers · from the workshop
Delivery
How a change reaches production.
The code lives in a GitHub repository. Every change comes in as a reviewable proposal, a pull request, and goes through 26 steps of automatic checks (the continuous integration, or CI) against a local copy of the site. If they all pass, the preview deploys itself with wrangler, Cloudflare's deployment tool. Production is deployed by hand, and a guard refuses to overwrite a database that already holds content.

GitHub Actions.Detail and proof 5 rows
- 7.1
The working repository is public, with all its commits.
- 7.2
Every change that can reach a page passes 26 steps that can fail. A test derives that number from the workflow.
- 7.3
The gates run the site locally on
workerd, the open-source runtime behindWorkers, throughwranglerdev. Ifwrangleritself crashes, the stack restarts once and the summary says so. - 7.4
When the gates pass on main, the preview deploys itself with
wrangler-action. It waits for theD1migrations, reseeds after rehearsing the SQL on a throwaway database, and runs a smoke battery. - 7.5
Production deploys only when the founder starts it by hand, and a guard refuses to overwrite a database that holds content.
across the layers · from the workshop
Content
Where every text is written.
Every word on the site lives in one file in the repository, seed/seed.json, in Spanish and English. On every change, the CI builds the site and fills an empty database from that file, so the whole site can be rebuilt from scratch at any time.

seed/ folder of the public repository.Detail and proof 4 rows
- 8.1
Every sentence the site renders lives in one versioned file,
seed/seed.json. The service pages are written in Markdown, and the CMS converts them into that file. A test keeps the two word for word, and a CI gate rejects copy typed into a template. - 8.2
On every change that can reach a page, CI builds the site and fills an empty database from that file, twelve times in parallel.
- 8.3
Service slugs are translated, so the other language's URL is never guessed. hreflang and the language switcher read the same resolved value.
- 8.4
The sitemap is generated from the CMS collections.
across the layers · on every change
Quality
What is checked before anything is published.
The accessibility, design, text and language checks first plant the defect they look for and pass only once they find it. Lighthouse, Google's tool that scores performance and accessibility, measures nine pages; the text of 30 routes is frozen; and every opening is tried in Safari's and Chrome's engines. AI agents write most of the code, and the founder merges every change.

main, all green, on 2026-10-16.Detail and proof 7 rows
- 9.1
The accessibility, engine, design, layout, copy, language and naming checks plant the defect they hunt, and must catch it before they report green.
- 9.2
Lighthouse in CI, against a local copy, takes the median of 3 runs on 9 pages: performance ≥95; accessibility, best practices and SEO, 100. All nine met it on 2026-10-16.
- 9.3
Accessibility: axe (WCAG 2.2 A+AA) and a keyboard pass on every route of the site, plus reflow at 320 px. Where text sits on a photograph, contrast is measured on the rendered pixels.
- 9.4
Each opening is checked mid-animation and at rest, in Safari's engine (iPhone and desktop profiles) and Chrome's (Pixel 7), with reduced motion too.
- 9.5
The rendered text of 30 routes is frozen. Changing a word fails until the new text is deliberately re-captured, so the change shows in the pull request's diff.
- 9.6
AI agents write most of the code under written rules, and the founder merges every pull request.
no file: shown by the merge historythe repository - 9.7
Every push is scanned for secrets, and a guard rejects any client name not published under References.
The workshop, open
If someone tells you how they work and cannot show you the workshop, be wary. This is ours: code, content, checks and deployments.
Let's talk, engineer to engineer.
Bring the problem as it is. You'll hear back from the person who'll write the code.
Tell us about your project