The questions that actually decide a yes.

The static layer is your read-heavy marketing/brochure pages — the content the vast majority of your visitors come for. That's what we capture and serve as immutable files on the edge.

Dynamic and transactional features stay dynamic. A contact form, a site search, a login, or a members area runs on a small Worker overlay or your existing dynamic origin — not the static layer. In the live demos, the contact forms already work exactly this way: the page is static, the form posts to a small same-origin endpoint.

So the honest split is: the brochure surface goes static (fast, unbreakable), and the few genuinely dynamic bits keep a tiny, well-scoped dynamic component. We scope which features need that when we look at your site. If a feature can't be static and can't be a small overlay, we'll tell you up front.

Exactly the way you do now. You keep editing in Drupal — same admin, same content types, same editorial workflow. Nothing about authoring changes.

When you publish, we re-capture the affected pages and atomically redeploy the static copy on the edge. Your Drupal can live wherever you like (it doesn't need to be on the public internet) — it's your editing tool, and the edge serves the rendered result.

There's no new CMS to learn and no proprietary editor to adopt. It's your existing Drupal, feeding a static front door.

No. This is the core of the pitch, so we'll be blunt: there's nothing proprietary to get trapped in. What you run is standard Drupal — ordinary Composer + Git + drush, the same stack the whole Drupal community uses.

You keep it, and you can leave any time. On the way out we hand you the static bundle plus your config via a one-command export — the rendered site is just files, and your Drupal is just your Drupal. Point it at any host and you're running.

We don't hold your CMS, your content, or your domain hostage. If the value isn't there, walking away is easy — that's the point.

On security, the claim is structural, not magic: with the static layer there's no origin server, no database, no PHP, and no admin login on the public internet. The web's most-attacked surface simply isn't there. You can't breach a login that doesn't exist or take down an origin that isn't serving traffic.

On speed, we measured the same site two ways. As a live Drupal origin, an uncached request does real PHP + DB work — a ~1,100 ms cold render on every cache miss, deploy, and content edit. The static edge copy holds ~105 ms with no render step to fall off of.

We're honest about the nuance: a warm Drupal page cache can be fast too — the real win is that the static copy has no cold-render cliff and no server to attack, not a magic TTFB number. See the full, dated, per-demo measurements on the proof section →

Drupal and WordPress, both today. The capture→edge pipeline runs on both, and we have live demos on each — five Drupal sites plus The Copper Fern, a WordPress small-business site (see them live).

The same approach applies to either CMS: we render your existing site and serve it static on the edge, so there's no /wp-admin or /user/login left on the public internet. On something more unusual? Get in touch and we'll tell you honestly whether you're a fit.

There are three parts: a one-time capture/onboarding, a monthly edge-hosting rate tiered by traffic and page count, and optional custom development only if you need it — with no per-resource markup and no lock-in.

We're in early access, so the numbers are indicative ranges, not a final rate card. See the breakdown and request a real quote on the pricing page →

No — they're fictional demonstration sites. The airport, university, garden, county, health system, and restaurant are invented organizations, not real businesses.

They're real Drupal and WordPress sites we built and captured, served 100% static on the edge, so you can click into a genuine live example of the transformation — five on Drupal plus The Copper Fern on WordPress. The orgs are made up; the static delivery is real. See all six →