Before choosing how a website publishes, ask one practical question: does an update need to be public in seconds, or can it take a few minutes? The answer changes the architecture.
A newsroom may need a correction visible immediately. A store may need stock and prices to be authoritative on every request. A services site, portfolio, or relatively stable business site may accept a short delay when a build-time separation between editing and serving fits its freshness and workflow needs. The right choice starts with freshness, not with a favourite tool.
The editor and the public site have different jobs. The editor gives the owner one place to edit content. The public site delivers the pages that visitors read.
On yesid.dev, the current application reads generated content modules for public pages instead of asking the CMS for content during each sampled visit. In fresh production traces on July 10, 2026, the home page, Services, Blog, one published article, and the yesid.dev project page all returned 200. Every observed request stayed on yesid.dev, with no request to Directus or a cms.* host. That is evidence from five traces, not a claim about every route or every future visit.
This smaller CMS dependency surface has practical value. Already-published pages are designed to remain available if the editor is unavailable because those pages do not need a fresh CMS response for each reader. That expectation follows from the architecture; it has not been proven by an independent outage drill. It also does not mean the whole website cannot fail. Other hosting, code, network, and asset dependencies still exist.
For the owner, there is still one editor. The separation applies to how published content is built and served.
Here is the one technical aside: the production path is Directus -> build export -> generated modules -> SvelteKit/Vercel. The CMS supplies published content to a build, the build prepares the public files, and only a completed deployment replaces the previous version.
That production refresh is now enabled. On July 11, 2026, a production build logged mode=live, read https://cms.yesid.dev with a fail-closed policy, exported five published posts and five bodies, and emitted all 22 generated content modules.
In the live-export path, refreshed content does not become public before a new deployment is ready. For the July 11 receipt, the production build started at 06:17:57.482 UTC and deployment completed at 06:19:26.603 UTC: 89.121 seconds from build start to completed deployment.
That is one observation, not an SLA or a promised normal range. It does prove this specific CMS change reached the public site: after completion, all five intended new article URLs returned 200 with self-canonicals and appeared in the sitemap; the three retired article URLs returned 404 and disappeared from the sitemap. This article was deliberately still a draft during that receipt, also returned 404, and was absent from the sitemap. An earlier candidate build rejected a link to this draft page and was not promoted, so the previous live deployment stayed in place until the corrected build completed.
This architecture is a poor fit when updates must be public in seconds. That includes newsroom-speed publishing, inventory or pricing that must be authoritative at request time, personalized applications, live dashboards, and any workflow that cannot tolerate a build before content becomes public.
It can fit services sites, portfolios, documentation, and other relatively stable pages where a few minutes is acceptable. Even then, fit depends on preview needs, editorial approvals, integrations, and how much operational work the owner or developer is prepared to carry. Static delivery is not a universal recommendation.
If that trade fits your site, see how the Websites & E-commerce service approaches web projects.
This is chapter 6 of a six-chapter epic. Chapters 1–3: who I am. Chapters 4–6: what I build. Previous: $50 to $0: an Oracle Always Free VM.
Need a system that stays editable?