I accidentally built a static site with Laravel.
Not technically. Technically, this website is a normal Laravel app with Blade views, Markdown content, deployments, compute, and all the familiar moving parts. There is no static site generator turning my posts into a folder of HTML files. But the site has one important constraint: content only changes when I deploy. That small detail changes how scary caching feels.
The Setting That Made This Click
I'm talking about this very website you're currently on! When I launched my new website, I wanted to host it on Laravel Cloud.
It's my first production app on Laravel Cloud, so naturally, I spent a while clicking through the entire interface looking at what it offers.
Laravel Cloud partnered with Cloudflare to "provide edge networking." This means DDoS protection, but also caching. My website doesn't change too often, so allowing Cloudflare to cache my pages for a bit seems reasonable.
But then I found the setting that made this whole thing click: Purge edge cache on deploy
My Site Is Dynamic, But My Publishing Model Is Not
Technically, my website is dynamic: Content is dynamically read from Markdown files, filtered & organized by custom PHP code, and then rendered using the Blade templating engine. No static site generators, just a classic Laravel app with Blade.
But in reality, every change I make to the website requires a new deployment: Changes to the Markdown files to create or update posts, changes to the Laravel app for styling or other adjustments.
The pages don't change because a user clicks something: A page changes because I edit a Markdown file, commit it, and deploy a new version.
The app is dynamic at runtime, but the publishing model is static.
To be clear: this is not a new caching trick. Cloudflare caching is not exactly a secret. Sending cache headers from a web app is not a revelation. If your first reaction is "yes, that is what a CDN is for," fair.
The part that clicked for me was the fit: My site only changes when I deploy, and Laravel Cloud can purge the edge cache when I deploy. That turns aggressive caching from something I would normally be careful with into something that mostly matches how the site works anyway.
One Request for Laravel, Then Edge Cache
If the cache is purged on new deployments anyway, then what's stopping me from caching pages for a long time?
Posts are Markdown files committed to the repository and deployed with the app. So in this case, a long cache lifetime is not scary. It matches the way the site already works: content changes on deploy, and that's when the edge cache is purged.
The result is pretty cool:
Laravel renders a page once. Cloudflare stores the response. The next requests are served from the edge instead of waking up my app.
That is good for visitors, because the page is fast. It is also good for my Laravel Cloud bill, because cache hits do not need compute. Once the cache is warm, my app can spend most of its time asleep.
Why I Like This More Than a Static Site Generator
Perhaps the best part:
This required zero changes to my development experience or how I build the site: I set the header in a Laravel middleware and the header itself is specific to Cloudflare. That means locally or whenever Cloudflare isn't in front of my app, it "falls back" to regular Laravel app behavior: Just hit the app and let Laravel return a fresh response on every request.
No local cache clearing. No separate build step. No Cloudflare-shaped development workflow.
I don't have to worry about a static site generator or architect my page around the concept of a static site. I just return the header for the pages that behave like static content, which is almost the whole site.
Where This Falls Apart
If you sign up for my newsletter (Where I hear you asking? At the bottom of the page!), you'll still hit my Laravel Cloud app.
This setup only works if you actually have static-ish pages. If your responses are personalized, pages require authentication, you have sessions, or basically anything dynamic that isn't done client-side, this setup won't work.
But for a mostly static site like my homepage and blog, this works perfectly.
I still get to build the site like a Laravel app. It just spends most of its production life behaving like a pile of cached HTML.