Overview
Our own website is the case study we get asked about most, and the question behind it is rarely about speed. It is: how do you build a marketing site that non-technical editors can change without a developer, that AI coding agents can work in productively, and that leaves no public server for an attacker to reach?
The answer is a headless architecture with the right layer for each job. Drupal manages the content, privately, on DigitalOcean. Astro turns that content into a static site at build time. Cloudflare Workers serve the result from the edge closest to every visitor. Speed comes with that design, but it is the least interesting thing about it.

Headless Drupal as the content layer
Drupal is where the content lives and where the editorial rules are enforced: structured content types, revisions, translations, permissions, and workflow. Running it headless means Drupal never renders a public page. It exposes content through an API, and the front end decides how that content looks.
That separation is what makes the rest possible. The CMS can sit on private infrastructure with access limited to editors. The front end can be rebuilt in whatever framework fits the job without touching a single piece of content. And when we want to change how the site looks, we change the Astro components, not the CMS.
Astro as the front end
Astro reads the content from Drupal at build time and writes every page as static HTML, CSS, and JavaScript. There is no server rendering on request, no database query behind a page view, and JavaScript ships only where a component actually needs it. Publishing in Drupal triggers a rebuild, and the new site replaces the old one in minutes.
Astro also happens to be the environment our AI coding agents are most productive in. Codex and Claude Code work fluently in JavaScript frameworks and component files, so a design change, a new page type, or a fix moves from request to pull request quickly, with a human reviewing every change before it ships.
Testing headless Drupal Canvas with Acquia
Drupal Canvas is Drupal's drag-and-drop page builder. At DrupalCon Rotterdam 2026, the Driesnote announced official headless support for Canvas across five front-end frameworks, with code components written in React and JavaScript developers treated as first-class citizens.
We have been working with Bálint Kléri at Acquia to test that headless support against our Astro front end: composing pages in Canvas, reading the layouts through the API, and rendering them with our own components. It gives us two things at once that a headless site usually has to choose between.
- Non-technical editors get a drag-and-drop experience. Layouts are assembled visually in Canvas, with the components our designers built, and published without a developer in the loop.
- AI agents get a codebase they are good at. The components Canvas renders are JavaScript, so Codex and Claude Code can build, extend, and test them in the environment they work best in.
Connecting humans and AI in the CMS
The same Driesnote showed an AI assistant connected to a Drupal site through a recipe of Simple OAuth, the MCP Server, and the Tool module. Put that next to headless Canvas and the shape of the next content management system is clear: people set direction and make decisions in a visual editor, and agents do the repetitive production work in code, with every change reviewed before it goes live.
That is the principle behind everything we build. Human judgment directs the work. AI accelerates it. A CMS that connects the two, instead of forcing a choice between a page builder for people and an API for machines, is where we believe content management is going, and it is what we are helping to test.
Hosting: DigitalOcean underneath, Cloudflare at the edge
Drupal runs on DigitalOcean, our infrastructure partner for compute and managed services, on the same platform behind our managed hosting. It is reachable by editors and by the build, and by no one else.
The Astro output is deployed to Cloudflare Workers with static assets, so every page is served from Cloudflare's network at the edge nearest the visitor. The only code that runs on request is the small Worker that handles our contact and newsletter forms; everything else is a file.
Why static beats a monolith for a marketing site
A traditional Drupal site renders every page on a server, with a database, an admin interface, and PHP all reachable from the public internet. That is a lot of surface to defend and a lot of work to keep patched, and its speed depends on caches being warm.
- Security. A static file cannot be exploited the way a CMS can. There is no public admin panel, no database to inject into, and no server-side code running per request. The CMS stays private, and a compromise of the public site is a compromise of nothing.
- Performance. Pages are files served from the edge, so they are fast for every visitor whether or not a cache is warm, and Google's Core Web Vitals and AI crawlers both get finished HTML immediately.
- Resilience and cost. Traffic spikes hit Cloudflare, not a server. The site stays up if Drupal is down for maintenance, and there is no fleet of web servers to size, scale, or pay for.
- Maintenance. Security updates for Drupal happen on a private system on our schedule, not as an emergency because the site is exposed.
See it for yourself
Every page you have read on this site came through this pipeline: written in Drupal, built by Astro, delivered by Cloudflare. We are glad to walk through the setup, the Canvas testing, and what it would take to run your marketing site the same way.
Want to see headless Drupal Canvas, Astro, and Cloudflare working together?
Schedule a demo of our setup