Running Water thru New Pipes
Why Rebuild vdatacloud.com? and What It Says About How We Think!
We just shipped a full rebuild of this site, and while “we redesigned our website” isn’t usually worth writing about, the how is close enough to what we talk about here, namely: architecture, separation of concerns, and building systems that don’t accumulate risk over time. Tt seemed worth explaining rather than just shipping quietly.
The old setup. Like most sites of this vintage (y2k-ish), vdatacloud.com was a single monolithic WordPress installation: content, templates, plugins, and public-facing delivery all living in one place, on one server. It worked, but it meant every visitor’s page load depended on a full PHP application executing in real time, and every plugin update carried some risk to the whole stack. Prior CISO’s have long berated me for WordPress due to base + plugin risks and an uncontrolled platform.
In with the new. WordPress is still where content gets written and nothing changes about how we “publish”. But it’s no longer what serves the public site. WordPress now runs headless, reachable only by an authenticated content pipeline and by us, through its admin. The actual site your browser talks to is a statically generated build, produced by Astro and served directly from Cloudflare’s edge network via Workers, no origin server in the request path at all for a normal page view. We have also fronted /wp-admin with Cloudflare Access – their zero-trust platform for enhanced lockdown of our cms!
New practices. Publishing a post still happens in the WordPress editor, exactly as before. But that content now gets pulled into the build pipeline, rendered once, and distributed as static assets across Cloudflare’s global network. A page load doesn’t wait on a database query or PHP execution, it’s just a file being served from whichever edge location is closest to you. Attack vectors are minimized, and SEO load times are “as fast as I can get”.
| From | To | |
| Architecture | Monolithic WordPress: content, templates, and public delivery all in one system | Headless WordPress (content only): + Astro static build + Cloudflare Workers edge delivery |
| Request path | Every page view executes PHP and queries a database | Every page view serves a pre-built static file, no server-side execution |
| Publishing | Write, publish, live immediately | Write, publish → content synced → site rebuilt → deployed (a pipeline, not a single step) |
| Public attack surface | CMS, database, and plugins all reachable by anonymous traffic | Public site has no database and no plugin surface; WordPress itself isn’t part of the public path |
| Scaling model | Vertical, bigger server, more headroom | Horizontal by default, edge network scales independent of any one origin |
| Failure mode | CMS outage = site outage | CMS outage = publishing pauses; the public site keeps serving its last successful build |
Why this matters, and why it’s not just a performance story. We talk a lot in this blog about treating architecture as a first-class (intentional) design decision rather than something that accretes by accident. We govern meaning before governing data, or build systems where the failure modes, constraints and vulnerabilities are understood rather than discovered in production. This rebuild is the same instinct applied to our own infrastructure: separating the system that authors content from the system that serves it means each can be optimized, secured, and reasoned about independently. WordPress’s attack surface no longer overlaps with the public site’s attack surface. A traffic spike doesn’t threaten the CMS. A CMS plugin issue doesn’t threaten uptime for a visitor reading a post or open a vector for attacking our brand or our readers.
Advantages
- Performance. Static assets served from the nearest edge location beat a database-backed page render on every request, everywhere, without any caching layer trying to paper over it after the fact.
- Security posture. The system anonymous visitors talk to has no database and executes no server-side code. WordPress, historically the most-targeted piece of this kind of stack, is no longer part of the public attack surface at all.
- Resilience. Decoupling authoring from delivery means an origin problem is a publishing problem, not an uptime problem. The site keeps serving its last good build regardless of what’s happening upstream.
- Cost and scaling efficiency. Static content is cheap to serve at any volume, there’s no per-request compute or database load that grows with traffic, which matters a lot more the moment something you write actually gets shared.
Things that tripped us up / need watching
- Publishing isn’t instant by default. There’s now a pipeline between hitting “Publish” and content going live, fetch, rebuild, deploy. Worth investing in a fast trigger (a webhook, not just a periodic poll), or editors will assume something’s broken when it’s just a normal, if solvable, latency. “Post transition” hooks for X, Linkedin and other social platforms need to be carefully managed within our GitHub workflow.
- Preview gets harder. When rendering is decoupled from the CMS, “what will this actually look like live” is a less immediate question than it is in a traditional WordPress theme. Plan for how authors preview content before it’s public.
- Legacy URL debt doesn’t disappear on its own. Anything relying on dynamic, origin-generated behavior including query-driven pages, plugin routes, and non-content paths, needs to be explicitly accounted for in the new architecture, or it quietly breaks instead of failing loudly.
- The operational surface shifts, it doesn’t shrink. You trade “one system to operate” for “two systems that have to stay in agreement”. The synchronization pipeline needs to be reliable, and the content model the CMS allows has to stay in sync with what the frontend actually knows how to render. For us GitHub workflows and mu-plugins were the answer!
What stayed the same. Every existing post URL still resolves to the same content: old links, bookmarks, and search results all still work. What changed is everything underneath that, which is exactly where architecture is supposed to live: invisible when it’s working.
If you’re evaluating a similar move for your own organization: decoupling a content system from its delivery layer, or rethinking how much of your public infrastructure needs to be stateful at all… this is a pattern worth taking seriously, and one we’re glad to talk through.