Ssg Laravel Package

Product Decisions This Supports

• The delivery-tier decision, decoupled from the CMS decision. The core insight for a PM is that this package changes how the site is served, not how the site is authored. Editors keep using Statamic; the public artifact becomes a folder of HTML. That splits one previously bundled decision ("which CMS, hosted how?") into two independent ones: content tooling and delivery architecture. That separation is where the real optionality comes from — it lets you optimize the delivery tier on cost, latency, and security without reopening the editorial tooling debate.
• Hosting and cost model. With no PHP process or database in the request path, the run-rate becomes storage + CDN egress, and the operational surface narrows to two things: the CDN and the build pipeline. Both are forecastable line items. This is a decision a PM can take to finance with a number attached, rather than a vague "modernize the stack" story.
• Build vs. buy, framed honestly. If Statamic is already in place, SSG is a low-incremental-cost path to static delivery versus re-platforming to Astro, Next.js, or Hugo — the migration cost is the pipeline, not a content rewrite. If Statamic is not in place, adopting it purely to get static output is a coupling bet: you'd be selecting a CMS you didn't want in order to obtain an SSG you can get natively. That asymmetry should drive the decision more than the package's feature list.
• Publishing cadence becomes a product requirement. This reframes "publish" as content change → build → deploy. That forces explicit product decisions a PM would otherwise defer: what publish latency is acceptable, whether previews are required before publish, what rollback looks like, and whether regeneration is per-publish, scheduled, or on-demand. Committing to static delivery is committing to answer these.
• Security and compliance posture. Removing PHP from the public request path is a concrete, defensible reduction in attack surface — useful framing when the roadmap touches regulated content, DDoS resilience, or hardening work that would otherwise need its own workstream and budget.
• Roadmap triage by site archetype. Static generation has a clear fit set: docs portals, marketing/brochure sites, blogs, launch and event microsites — low-write, high-read, bursty-traffic properties. Identifying which properties in the portfolio match that profile is itself a useful prioritization exercise.
• Maintenance-lane alignment. 4.1.0 adds Laravel 13 support alongside a test-only PHPUnit metadata migration. Active upkeep lets a PM keep the static-site lifecycle on the same upgrade lane as the application and its host support windows, instead of accruing a parallel upgrade obligation.
• Explicit non-support: personalization, authenticated views, live search over private data, and sub-minute freshness. Naming these as out of scope up front is a scope decision, and a valuable one — it prevents a "we'll make it static and add personalization later" commitment that the architecture will not honor cheaply.

When to Consider This Package

Adopt when most of these hold:

• Statamic is already the authoring tool and you want to keep it while removing runtime rendering from the public site.
• Traffic is read-heavy with modest, infrequent content change, so a full rebuild per publish is cheap and fits within CI budget and minutes.
• The roadmap prioritizes CDN-edge delivery, low server spend, or a smaller attack surface over per-request dynamism.
• Content is largely public and cacheable; personalization, sessions, and real-time data are out of scope or handled as small client-side/API islands.
• Someone will own the build-and-deploy pipeline — CI triggers, artifact storage, cache invalidation, preview builds, rollback, and failure alerting. The package emits output; orchestration is entirely yours.
• The build environment can run PHP and Composer 2, and you're comfortable keeping a hand-maintained route manifest (config/ssg.php) in review alongside routing changes.

Look elsewhere or reconsider when:

• The product needs personalization, authenticated views, private-data search, or sub-minute freshness at scale. Build-per-edit cost then dominates and the static model actively fights the requirement.
• There is no existing Statamic investment. A native SSG (Astro, Next.js, Hugo) is likely the cheaper long-term default with a far larger hiring and troubleshooting pool.
• Editors expect instant publish confirmation. Every publish triggering a build needs a latency and UX answer before commit — not after launch.
• Required capabilities sit outside Statamic core (complex form handling, advanced multilingual routing) and would need separate infrastructure regardless, eroding the simplicity case.
• Your CI cannot run PHP, or you lack the appetite to own a pipeline. Without an owner, this becomes a system that silently rots.
• Ecosystem support matters to your risk posture. 252 stars and no listed dependents means limited peer validation and a thin body of public troubleshooting; internal expertise must be built, not borrowed.

Two risks a PM should carry into any go decision: silent under-generation (a page missing from the route manifest produces no build error — you simply don't ship it) and staleness (a broken CI pipeline quietly serves an old build indefinitely). Both are mitigated by a post-build route-count assertion, a link checker, and build-failure alerting — cheap controls, but they need to be named in the plan, not assumed.

How to Pitch It (Stakeholders)

Executive summary. Statamic SSG pre-renders our Statamic site into fully static files at build time, so the public site can be served from a CDN with no PHP runtime in the request path. The expected outcomes are lower infrastructure cost, faster and more predictable page loads, and a materially smaller security surface — all without changing how editors work. What changes is the delivery tier, not the authoring tool. Version 4.1.0 is a maintenance and compatibility release (Laravel 13 support plus a test-only PHPUnit metadata migration) with no public API, config-schema, or output changes versus 4.0, so it is low-risk to adopt. The package itself is a small, well-scoped piece of work; the investment is the build-and-deploy pipeline around it, and that should be estimated and staffed separately.

For engineering. Treat 4.1.0 as a routine dependency bump — the PHPUnit change has zero production effect and behaviour is unchanged from 4.0. The meaningful work is operational: build triggers, artifact storage, cache invalidation, preview environments, failure alerting, and a documented rollback. Verify rather than infer the resolved Composer matrix (Statamic core major, Laravel, and the PHP floor the widened constraints imply) — that PHP floor touches CI images, build containers, and any preview host still pinned to an older runtime. Keep two tracks separate: the addon supporting Laravel 13 is not a mandate for the application to upgrade to Laravel 13, and merging them turns a maintenance release into an accidental forced migration. Also note the package's footprint is small (modest star count, no listed dependents), so plan to build internal expertise rather than rely on community answers.

Recommendation. Adopt wherever Statamic is already in place, and gate the go/no-go date on a short pipeline spike — roughly two to three days to generate the site once, serve it, and classify each page archetype as static-safe, statically-degradable, or blocking. That spike is the earliest point at which a launch estimate is trustworthy; do not publish a date before it. Then run explicit gates: resolved-matrix sign-off, an output diff against the prior build (expect byte-identical modulo timestamps), pipeline build-out, preview validation against the real CDN, and production promotion with the previous artifact retained. Assign a single owner for config/ssg.php and document an "is this page static-safe?" checklist during rollout. Revisit the decision if content freshness, personalization, or traffic patterns move toward genuinely dynamic needs.