Static sites with a CMS are not a contradiction
Static output and a real CMS can coexist nicely. The trick is treating the CMS as the publishing system, not the public runtime.
A static site does not have to mean writing every page by hand or teaching editors Git. It means the public thing people visit is already built, cacheable, and boring in the best possible way.
The CMS still matters. Payload is where entries are drafted, reviewed, and published. The public website only sees a validated snapshot after publish. That small separation removes a lot of runtime drama.
The publishing shape
- Payload owns content, editorial metadata, and publish state
- A signed publish hook asks the Website Manager to rebuild the site
- SvelteKit turns the current snapshot into static HTML, feeds, and search JSON
- The release is pushed to storage and served through BunnyCDN
export function contentEntryPath(entry) { return `/${entry.collection}/${entry.slug}`;}// /blog/static-sites-with-a-cmsThe important part
Why I like this default
It keeps the fun parts of a CMS, like clean authoring and publish workflows, while making the public site cheap to host and easy to cache. There are still places where live rendering is useful, but a technical blog is usually not one of them.
The best production system is often the one that has fewer opportunities to be interesting at 2am.