Static Site Generator Laravel Package

Product Decisions This Supports

• Delivery model: pre-rendered static output vs. a live PHP runtime. statamic/ssg takes an existing Statamic site and writes it out as plain HTML/CSS/JS to disk, deployable to a CDN, object storage, or any static host. The product question it answers is whether read-heavy, editorially published content should be assembled per request or built ahead of time. That's a decision about page speed, uptime exposure, and cost — not an infrastructure detail to be delegated.

• The publish-to-live loop as a product commitment. Adopting SSG means accepting a publish → rebuild → cache-invalidate cycle. The PM decision is the staleness budget: is "live within a few minutes of publish" fine, or does the business need instant? Agree this before engineering invests, because it determines whether SSG is viable at all.

• Scope and cost of interactive features — the classic SSG estimate blow-up. Static output removes request-time behavior. Forms, search, comments, A/B tests, authenticated areas, and personalization each become explicit line items with a third-party vendor, edge function, or client-side library attached. Surfacing those as scope decisions up front is the highest-value thing a PM does on an SSG project.

• Framework upgrade roadmap — the real signal in 4.1.0. This release adds Laravel 13 support. For a product on Statamic + SSG, the package version is a gate on the Laravel 13 upgrade: the host application cannot move while pinned to an SSG release that doesn't support it. Treat 4.1.0 as an unblocker in the upgrade workstream, not a feature to evaluate or market.

• Build vs. buy. This is a first-party, MIT-licensed Statamic addon — maintenance is bought, not built. The "build" alternative (Astro, Next.js + headless CMS, Hugo) is a re-platforming with content-model migration, template rewrite, and editor retraining. Unless the CMS itself is the problem, incremental addon on a stack we already run beats migration project.

• Hosting and vendor selection. Committing to static output narrows and clarifies hosting (Netlify, Cloudflare Pages, Vercel, S3 + CDN, GitHub Pages), usually collapses spend toward near zero, and removes a production server from the patch-and-defend rotation.

• Portfolio triage for new sites. A fast screen when a new site, microsite, or sub-brand lands on the roadmap. Good fit: marketing site, blog, docs portal, brochure site, landing pages. Poor fit: personalized or authenticated experiences, user-generated content, live pricing/inventory, real-time data.

• Release risk assessment for 4.1.0. A semver-safe minor from 4.0.0: no breaking changes, no new user-facing features, no deprecations. The PHPUnit metadata → attributes change is internal test tooling only. Signals active upstream maintenance, requires no migration work, carries no product risk.

When to Consider This Package

Adopt — or upgrade to 4.1.0+ — when:

• You already run Statamic (or have deliberately chosen it) and want to deploy to a static host or CDN.
• Content changes on a known cadence — editorial publishing, release notes, docs updates — and minutes-level staleness is acceptable to the business.
• You are planning a Laravel 13 upgrade. 4.1.0 is the release that keeps this dependency viable; staying on 4.0.x pins the host app to older Laravel.
• Reducing operational surface matters: no PHP runtime in production, no server to patch, smaller attack surface, predictable hosting cost.
• The team is small and shipping speed depends on not owning runtime infrastructure.
• You are on 4.0.0 already — 4.1.0 is a drop-in minor with no config or data migration.

Look elsewhere when:

• You need request-time behavior: authentication, personalization, geo/locale routing, sessions, live inventory or pricing.
• Content changes faster than your rebuild cycle — newsroom, marketplace, or feed-driven products where a full rebuild per publish becomes the bottleneck.
• Forms, search, comments, or experimentation are core to the product. SSG can still work, but only with explicitly budgeted third-party services (hosted form endpoints, Pagefind/Algolia, edge functions). If that budget isn't there, the answer is no.
• The site is very large (tens of thousands of pages) and build duration dominates. Generation is a full build, not incremental; build time scales roughly linearly with page count.
• You are not on Statamic. The effort is better spent on a purpose-built static framework than bending a CMS addon into a non-CMS stack.
• You are on an end-of-life PHP/Laravel combination the package no longer supports.

How to Pitch It (Stakeholders)

For executives:

Statamic SSG is a free, first-party addon that publishes our Statamic site as static files to a CDN. The business case is cost and speed: near-zero hosting spend, faster page loads, and one fewer production server to patch and secure. It's maintained upstream by the Statamic team, so we're buying maintenance rather than building it. Release 4.1.0 is a maintenance release — its substance is Laravel 13 compatibility, which keeps this dependency aligned with our framework upgrade roadmap. There are no breaking changes and no new features to evaluate, so the decision in front of us is the delivery model, not the version.

For engineering:

Drop-in Statamic addon: Composer install, publish config/ssg.php, run php please ssg:generate, and the existing Laravel app writes a static build. 4.1.0 is a minor from 4.0.0 — Laravel 13 support plus a PHPUnit metadata-to-attributes migration that's test-only with no consumer impact. No public API changes, no deprecations, safe in-place upgrade. The trade-offs we're accepting: full rebuilds per publish (so we need CI/webhook wiring and CDN cache invalidation), correct per-environment APP_URL/base path or the output is full of broken links, a curated include/exclude list so dynamic and private routes aren't published, and manual handling of pass-through files like robots.txt and _redirects. Anything requiring a live PHP request — forms, search, auth, redirects middleware — moves to third-party services or edge functions. Sequence it inside the Laravel 13 upgrade workstream and validate in a non-production environment before rollout.

Ask: approve the static delivery model and fund the pipeline work (CI build step, CDN cache invalidation, third-party replacements for forms/search), and schedule the 4.1.0 bump alongside the Laravel 13 upgrade.