Static & edge delivery
The CMS stays private. The public site is files at the edge: nothing to patch on a weekend, no database exposed, and a hosting bill close to nothing.
Editors work in Drupal as always; on publish the site becomes plain files on a content delivery network, so the public never touches a server, a database or a login form. Almost nothing to attack, pages from the nearest edge, and this very site is built this way.
Ask whether your site is a fit- The CMS stays private; the site is files at the edge
- Nothing to patch on a weekend
- This site is built exactly this way
What static delivery is for
Most institutional sites are read far more than they are written: a few editors publish, many thousands read. Serving every reader from a live Drupal server means running, patching and defending that server around the clock for work that could have been done once at publish time. Static delivery does it once. The site is rendered to files, the files go to an edge network, and the reader never reaches the CMS. Forms, search and counts run as small functions at the edge. The CMS stays behind a login, or off.
What we do with it
We keep Drupal as the editorial system, with its content model, workflow and permissions intact, and add a bake step that renders the whole site to files on publish. We put those files on a content delivery network with a small edge worker for the parts that need to compute: contact forms, search, redirects, read counts. We build the pipeline that bakes, checks accessibility, responsiveness and SEO on every change, and deploys only when the checks pass. And we set up the CMS so it runs privately, on a small server or a laptop, and can be rebuilt from the repository.
How we work
Not every site is a fit, and the first step is saying so honestly: sites with personalized pages, logged-in readers or constant real-time data usually are not. For sites that are, we run the bake beside the live site until the output matches, move the dynamic pieces to edge functions one at a time, and cut over with the live server still warm. The pipeline's checks become the site's quality gate from then on.
Why now
The cost of running and defending a public Drupal server has not fallen; edge networks and workers have become cheap and ordinary. Drupal 10 ends on December 9, 2026, and a platform that is about to be rebuilt can arrive as a private CMS with a static public face. This is a Horizon service: we run it for ourselves and for pilots, and we say so on this page.
What this site proves
0
Public servers
The site you are reading is files on an edge network. The CMS is private.
How this site is built3
Gates on every change
Accessibility, responsiveness and SEO are checked on every build. A failure does not deploy.
Our accessibility statement1
Repository
Content, configuration, theme and pipeline. The whole site rebuilds from it.
Dec 9, 2026
Drupal 10 end of life
A rebuild scheduled now can arrive as a private CMS with a static public face.
Drupal core release scheduleI want to …
find out whether my site is a fit
Sites that are mostly read and rarely personalized are. Sites with logged-in readers or real-time data usually are not. A short audit says which, honestly.
- Pages, forms and integrations inventoried
- The dynamic pieces named, with how each would move to the edge
- A yes, a no, or a partial, in writing
take the public site off the server
Keep Drupal for editing, render the site to files on publish, serve from the edge. The server the public used to reach is switched off.
- A bake step on publish, checked against the live site until it matches
- Forms, search and redirects moved to edge functions
- Cutover with the live server still warm, then off
cut the hosting bill and the patch burden
A private CMS needs a small server or none; an edge network costs close to nothing at institutional scale. Weekend patching of the public server ends.
- The public server and its database retired
- The CMS on a small private host, or rebuilt on demand
- Patching reduced to the private CMS, on a schedule
put quality gates on every change
The bake pipeline is the place to check accessibility, responsiveness and SEO on every change, and to refuse to deploy a broken build.
- Automated accessibility checks against WCAG 2.2 AA
- Responsive and SEO checks, with budgets
- A deploy that happens only when everything passes
From a live server to files at the edge
Step by step, with the live site running until the static one matches it.
The bake runs beside the live site until nobody can tell them apart. Then the server goes away.
Services that pair with this one
Static delivery is a Drupal build, a cloud account and a set of gates. These are the services most often bought alongside.
-
Drupal development
New builds, major-version upgrades, module and theme work, and migrations from Drupal 7 onward. Every site we build is one we can keep patched, accessible and on a supported version for years, because that is the job after launch.
-
Cloud engineering
We design and run the cloud your platform lives on, in your own account, as code, with monitoring, patching and a monthly cost review in writing. We do not resell hosting, and everything we build is documented so the next engineer can run it.
-
Accessibility & AI visibility
Accessibility fixed at the source, in the theme and the editorial rules, with a conformance report you can hand to procurement. The same work makes your pages the ones AI engines cite.
Tell us about the site.
Roughly how many pages, what the forms do, whether anyone logs in. We come back with whether it is a fit and what the move would take.
Ask whether your site is a fit