Why we moved computerminds.co.uk to Astro and Sanity

This week's PHP2Shell flaws hit every PHP server on the web, but not the one running our website, because there isn't one any more.

What we built

The new computerminds.co.uk is an Astro front end, built to static files, with Sanity as the CMS. It replaced the Drupal site we'd run for years.

• Sanity holds the content. Its editing screen, the Studio, is hosted by Sanity, so there's no admin area on our own domain.
• Astro pulls that content at build time and turns it into plain HTML pages.
• Cloudflare serves those files from its global network. When an editor publishes, a webhook kicks off a fresh build, and the new pages go live when it finishes.

Everything that reads the CMS or runs code sits in the top row, away from the public. Visitors only ever touch the bottom row.

Why there is less to attack

The public site is a folder of HTML, CSS and images. There's no PHP, no database and no admin login on the server visitors reach, so a flaw like PHP2Shell has nothing to land on.

With a traditional CMS, every page view runs code. That code, its runtime and its database are all exposed to the internet around the clock, and each needs patching the day a fix appears. With a static build, the code runs once, at build time, on a machine nobody can send requests to.

The moving parts that remain are small and well contained:

• The CMS is hosted by Sanity. Editors log in to Sanity, not to our server, and Sanity patches its own platform.
• The forms run as one short Worker script that checks a Cloudflare Turnstile token before passing anything on.
• The build tools are npm packages. We pin them, batch updates through Dependabot with a cooldown, and check dependencies in CI, because a static site still has a supply chain to look after.

None of this makes a site unhackable. It makes the target much smaller, and it means a bad week for PHP is not a bad week for us.

It's not for every site

We're a Drupal agency, and we'd still pick Drupal for most of the sites we build. A static front end suits content that changes a few times a day at most. It gets harder as a site does more for each visitor.

Drupal, or another server-side CMS, is still the better fit when a site has:

• Logged-in users who see their own content, such as members' areas, intranets or learning platforms.
• Commerce with baskets, stock and checkout.
• Complex permissions and workflows, like many editorial teams with sign-off rules.
• Lots of content that changes constantly, where rebuilding the site on every edit becomes slow.
• Deep integrations with CRMs, search or single sign-on that need server-side logic on each request.

You can build some of this headless, with APIs and serverless functions. But by then you're running a back end again, just spread across more services. For those sites, a well-maintained Drupal install with a patching plan is the safer, simpler choice.

Where it works well: brochure sites

Smaller brochure sites are the sweet spot. They're often the sites most exposed to bugs like PHP2Shell, because they run on shared hosting, get patched rarely and have no one watching them.

A site is a good candidate if it:

• Has a handful of editors publishing pages, news and case studies.
• Collects enquiries through a few forms, but has no user accounts.
• Changes daily or weekly, not by the minute.
• Costs more in hosting and security updates than its traffic justifies.

For these sites the payoff is real. There's no server to patch, hosting costs fall to little or nothing, and pages load fast from a global CDN. Editors keep a modern editing screen with live preview.

Is your site a good fit?

If you spent this week worrying about PHP2Shell on a site that is mostly pages and a contact form, talk to us. We'll look at what your site actually does and tell you honestly whether to move it, or to keep it on Drupal and put a proper patching plan in place.