Drupal Canvas goes headless. We’re already building with it.

Josh and I met Bálint Kléri at Florida DrupalCamp in February 2026. After his talk about JavaScript code components in Drupal Canvas, the three of us spent the better part of the afternoon discussing where Canvas could go.

We wanted headless to be a first-class part of Canvas. Developers could build the frontend in a framework they knew, with AI coding tools working alongside them. Editors could still arrange pages, change images, and manage content in Drupal. We could deploy the frontend on Cloudflare and protect the Drupal backend separately.

That conversation turned into an opportunity to test the approach. During development supported by Acquia, we worked with Bálint to try it against real project needs. I’m grateful to Bálint, Lauri Timmanee, and the Acquia team for the engineering and generosity that helped move it forward. Seeing that work in the Driesnote was a moment to celebrate the people behind it.

Canvas gives editors a visual way to compose pages from components: a hero, an introduction, a speaker card. In a headless setup, Drupal stores the content and the page’s structure, while a separate frontend renders what visitors see.

For this project, that frontend is Astro. At build time, it reads the content and component tree from Drupal and produces the public site. Cloudflare serves the resulting HTML, styles, scripts, and images. The component definitions connect the editing experience in Canvas to the frontend we develop.

Start with the content team’s everyday work. For a conference site, that means updating the year, choosing new imagery, and assembling the people and content for the next event. Canvas gives editors a visual way to do that with the site’s existing components.

This first recording shows page building on the live Shift UX site, starting with a draft in Canvas. Watch the editor assemble the page, change its text and images, and add curator cards by selecting people already stored in Drupal. It finishes with the resulting page on the live Astro frontend.

The curator cards show why structured content matters. Selecting a person fills in their name, photo, and title; the component handles the presentation. The editor can assemble a page from content already in Drupal while the development team maintains the code behind it.

For this static site, publishing means building and deploying the updated content from Drupal. We plan that workflow alongside the editing experience.

That visual editing experience gives the customer a way to keep working on the site. The headless frontend gives our developers and coding agents a way to extend the components available to them.

Because the frontend is a separate Astro project, an agent can work directly with its components, styles, and rendering logic. It can inspect the code, make a change, run a local build, and check the result. Our developers review those changes using the same tools they use for the rest of the project.

We connect those components to Canvas through definitions that describe the content editors can configure. The agent can read those definitions as it works, and editors get controls for the same content in Canvas. When we add a new capability to the frontend, we can give the content team a way to use it in their pages.

Our MCP connection extends that workflow into Drupal. It gives the agent specific authoring tools, so it can also create a test page and populate it with components and content. We can go from an idea to a working page that a person can open, review, and keep editing in Canvas. That’s where this combination gets exciting for me.

The first demo showed an editor working with existing components. Now say we want to add something new: a homepage hero that cycles through several background images. This second recording shows how an agent can help build that capability and put it onto a page we can edit in Canvas.

In this recording, we ask the agent to create a hero that changes images at five-second intervals, with a fade between them. We also ask it to use our Rosenfeld MCP connection to create a homepage variation for testing. The agent is working locally here, with the frontend code and our Drupal authoring tools available to it.

Watch for the handoff from the terminal to Canvas, then to Astro. The new hero appears on “Homepage Alt” in the visual editor, followed by a local frontend preview of that page.

The new hero is now part of the same visual workflow you saw in the first demo. The agent helped create the behavior and prepare a page for testing; an editor can open that page in Canvas and keep working with it. Our team directs the design, reviews the code, and tests the result before it reaches the live site.

For a closer look at the implementation, Josh’s account of rebuilding his own site with Canvas, Astro, and MCP walks through component definitions, restricted content-authoring tools, and fetching content during a build. His August post documents the work while Headless Canvas was still experimental.

Separating the frontend also changes how we can protect the site. Ordinary visits reach static assets on Cloudflare, so Drupal’s PHP application and modules can sit behind access controls for editors and build processes. Purpose-built Worker handlers can handle dynamic tasks such as form submissions.

That reduces Drupal’s public exposure. We still need to maintain it, manage access, and review the frontend and Worker code. Cloudflare’s Worker isolation provides another layer for the code that runs there.

For Rosenfeld, those pieces now work together on the live Shift UX conference site. We host Drupal on Blue Drop Cloud, our managed hosting platform, and the frontend on Cloudflare Workers.

To our knowledge, this was the first commercial website built with Drupal CMS, Headless Canvas, and Astro. I’m excited that Rosenfeld trusted us to take the approach from development into a site their team needs to maintain.

The part I’m happiest about for Rosenfeld is the savings. We kept design and development costs below what we typically see on traditional monolithic Drupal projects.

The demos help explain how. Coding agents can take on repetitive implementation work, and Canvas gives us an established foundation for visual editing. That leaves our team more room to compare designs, test behavior, and work through the details that make the site useful.

The cost of a project still depends on its content, integrations, design, and publishing needs. For suitable websites, though, we’re turning work around in weeks instead of months. Shift UX gave us a chance to put that approach to work for a customer, with an editing experience they can keep using after launch.

That afternoon in Florida, we were talking about a possibility. Now we have a live site, an editing workflow, and a clearer sense of what this approach can do for a customer.

If you’re considering Drupal Canvas, bring a website you’re planning or a workflow your editors find difficult. I’d love to walk through how we’d build the components, how your team would edit them, and what getting those changes live would involve.