You might notice things look a little different around here. I recently moved my personal site from Drupal 11 to Astro on Cloudflare Pages.

The decision was not driven by a technical problem or limitation with Drupal. Drupal had run this site successfully for years. This was a personal decision about time, cost, and how much infrastructure I still wanted to own for a site I have not had much time to write for lately.

Drupal was not the problem

This site ran on Drupal for years, first on AWS and later on Platform.sh, now Upsun. I wrote about both the original Drupal 8 relaunch on AWS and the later move to Platform.sh.

The setup worked well. It was stable, flexible, and heavily automated. Renovate handled dependency updates, GitLab CI validated changes, and security and regular Drupal core updates could deploy all the way to production without me intervening. I wrote about automating Drupal, package, and Docker image updates with Renovate, and later reflected on three years of automated Drupal core updates.

That system did exactly what I designed it to do. There was no dramatic failure and no technical ceiling that forced me to leave Drupal.

The real constraints were time and cost

My time is very limited these days. I have a hundred other things competing for attention every week, and I have not written much on this site this year. At the same time, I was paying $52 per month to host it on Upsun. Not a terrible price for managed infrastructure, but I just wasn't making the most of it.

I also had a list of ideas that would have made the site more dynamic. I never got around to building them, and realistically, I probably was not going to. Keeping a full Drupal application and its supporting delivery infrastructure running for those possibilities no longer made sense for me.

The maintenance was automated, but the system still existed. I still had private GitLab repositories, CI pipelines, runner minutes, dependency automation, and deployment workflows in the background. None of those tools were bad. Renovate remains an amazing tool, and I will continue recommending it. I simply did not want to monitor all of that for my personal site anymore.

Why Astro and Cloudflare Pages

Astro appealed to me because it is built for content-driven sites and can keep the result lightweight. When I learned I could host an Astro site on Cloudflare Pages for effectively $0, the tradeoff became compelling.

The site could become a collection of Markdown content and a relatively small amount of code. Cloudflare could handle serving it quickly and keeping it available without leaving me with another server or application stack to maintain. I could also decommission the private GitLab repositories and automation that powered the old site.

The monthly hosting cost went away and so did a category of work that I no longer needed on my plate.

Migrating the site with Codex and DDEV

I created a plan and spent about half a day working through the migration with Codex. I used DDEV to make the existing Drupal database available locally, then had Codex help marshal the site into its new structure.

That work included:

  • Reading the Drupal database and extracting the existing content.
  • Converting Drupal HTML into readable Markdown.
  • Preserving code snippets, media and tags.
  • Creating the Astro content collection and supporting pages.
  • Carrying the metadata needed for analytics, search engines, and structured data into the new files.

This was a good use of an AI coding agent. The migration involved a large amount of structured, repetitive work, but it still required a clear plan and verification. DDEV provided a predictable local copy of the Drupal site, while Codex helped transform and validate the content against the new Astro structure.

By the end of the session, years of Drupal content had become Markdown files that could be built and served as a static site.

Fewer layers between an idea and the site

The move also gives me more flexibility to change the site's presentation whenever I want. I can work directly in Astro and CSS without creating a new Drupal theme, working through Twig templates, or deciding how a visual idea should fit into the CMS.

That is not an argument against Drupal's theme system. It is simply a better fit for what I want from this particular site now. The content and presentation live together in a small codebase, and the boundaries are easy for me to understand and change.

I also had Codex create an authoring skill specifically for this repository. When I want to start a post or page, it asks a short set of questions and then creates the Markdown file with the frontmatter needed for analytics, SEO, canonical URLs, and Schema.org JSON-LD. The publishing workflow is still structured, but I no longer need a CMS administration interface to use it.

This does not change anything about Drupal

Moving my personal site away from Drupal does not change what I am doing with Drupal professionally or in the community.

I have three massive projects I am trying to bring to the Drupal community this year, alongside several other efforts. I am also ready to leverage Drupal 12 on client projects. I did not make this move because Drupal could not support the site or because I have lost confidence in it.

In fact, I released updates for a module recently to coincide with the Acquia & Vercel partnership announcement earlier this week. You can read about that right here.

This was personal time and budget management. The right architecture depends on the needs surrounding it, and those needs changed for me.