Static Site Generator Laravel Package

Technical Evaluation

Verdict. Adopt, but separate the decision into two tracks that are frequently conflated: (1) a low-risk dependency bump to 4.1.0 that unblocks Laravel 13, and (2) a delivery-model change to static output that needs its own business case, budget, and acceptance criteria. Only the first is decided by the release note. The second is a product decision about staleness, hosting, and interactive-feature scope.

Architecture fit. statamic/ssg is a first-party, MIT-licensed Statamic addon, not a general-purpose static site generator. It attaches to an existing Laravel/Statamic application, adds an ssg:generate command to the familiar Artisan/please surface, and reuses the application's existing Antlers templates, content model, routes, collections, taxonomies, and multisite configuration to write static HTML to disk. For a TPM the architectural read is favorable: adoption is additive — one Composer dependency plus config/ssg.php — with no re-platforming, no content-model migration, and no editor retraining. That is the core of the build-vs-buy argument: the alternative (Astro, Hugo, Next.js + headless CMS) is a migration project with template rewrites and content migration, not a comparable line item.

The mechanism is the part that changes planning. Generation works by crawling the running site over HTTP and writing each response to disk. That makes the build environment a first-class dependency: it must actually serve the application correctly, with a resolvable host, correct APP_URL, correct base path, and absolute URLs that resolve. Treat it as a build-pipeline dependency, not a pure code dependency, when sizing. If the organization is not on Statamic, this package is the wrong comparison entirely.

Integration feasibility. High, with a sizing caveat. Install is auto-discovered service provider, publish config, set an absolute base URL, run the command. No database migrations, no schema changes, no new production runtime service. The real effort sits around the package: CI wiring, asset compilation, destination upload, pass-through files (robots.txt, _redirects, favicon.ico), CDN cache invalidation, and post-build link validation. Scope it internally as "small package install, medium pipeline change" — the package is the easy half and should not be sized as the whole effort.

The 0-dependents figure is a red herring and should be pre-empted in any review: this is an application-level dependency, not a library other packages import, so dependent counts structurally understate adoption. The meaningful signals are first-party stewardship, an active release in 4.1.0, and 252 stars as a rough floor on real-world use.

Technical risk. Low for 4.1.0 specifically. It is a semver-minor from 4.0.0 with exactly two changes: PHPUnit metadata migrated to attributes (internal test tooling; zero consumer impact) and Laravel 13 support. No breaking changes, no deprecations, no public API changes, no new user-facing behavior. That is the whole release — do not let it be evaluated or marketed as a feature.

The material risk is strategic, not tactical: this version is a hard gate on the Laravel 13 upgrade. A product pinned to SSG 4.0.x cannot move the host application to Laravel 13. Position 4.1.0 as an unblocker in the framework-upgrade workstream.

Carry the standard static-generation risks explicitly on the register:

• Base URL / APP_URL errors producing a site full of broken links — the single most common failure.
• Silent loss of request-time behavior — forms, search, redirects middleware, auth, sessions, personalization.
• Stale destination directories serving removed pages unless the build cleans output.
• Build duration scaling roughly linearly with page count — full rebuilds, not incremental.
• Crawl-based route discovery missing unlinked routes — needs include rules, sitemap seeding, or explicit route lists.
• Response-level dependencies (headers, cookies, server-side redirects) that static hosting cannot reproduce.

Key questions.

• Which Statamic core version does SSG 4.1.0 require, and does that constraint align with our current Statamic pin?
• Is Laravel 13 a supported target for us now, or are we adopting forward-looking compatibility ahead of need?
• What is our publish cadence, and is "live within a few minutes of publish" acceptable to the business? This is the staleness budget and it determines viability.
• Which current behaviors depend on request-time PHP — forms, search, auth, personalization, geo/locale routing, redirects middleware — and what replaces each, at what cost?
• What is the total page count, and therefore the CI build time and cost per full rebuild?
• Who owns the deploy pipeline, and does generation fit an existing CI job or require new infrastructure?
• Do any consumers rely on response headers, cookies, or server-side redirects?
• Is multisite/locale output in scope, and if so, what are the per-site destination and URL acceptance criteria?

Integration Approach

Stack fit. Excellent where the organization already runs Laravel + Statamic and serves read-heavy, publish-cadence content: marketing sites, docs portals, blogs, landing pages, brochure sites, sub-brand microsites. Poor where the product needs request-time behavior: authenticated areas, personalization, sessions, live pricing or inventory, user-generated content, newsroom-scale or feed-driven publishing. The TPM's contribution here is honest classification of surface area before commitment — an SSG migration that later has to bolt auth and search back on via edge functions and third-party vendors costs more than staying dynamic, and that reversal is expensive once the CDN pipeline and DNS are live.

Migration path. Two paths, sequenced differently.

Existing 4.0.x users (upgrade path). Drop-in. Composer update, run the existing suite, regenerate a static build, verify output, deploy. No config changes, no data migrations, no consumer-facing test impact from the PHPUnit attribute change. Fold this into the Laravel 13 upgrade workstream as a prerequisite step — not a standalone initiative, not its own release window.

New adopters (install path). Sequence deliberately:

1. Reconcile Statamic and Laravel versions against the package's constraints.
2. Install and publish config in a non-production environment first.
3. Set an explicit, environment-specific absolute base URL — the most common cause of broken output.
4. Define include/exclude rules: exclude control panel, preview routes, form endpoints, search, account/cart, and unindexable listings; explicitly include hand-written routes such as /404, /rss.xml, /sitemap.xml.
5. Configure pass-through file copying.
6. Wire ssg:generate into CI with a defined trigger — publish webhook or schedule — plus asset compilation and destination upload.
7. Add post-build validation as a deploy gate: link checking and page-count assertion against expectation.

Compatibility. Backward compatible across Laravel 10/11/12, forward-compatible with Laravel 13 as of 4.1.0. Multisite and localized URL generation are supported but should be treated as a separate workstream with its own acceptance criteria: per-site destinations or per-locale subdirectories, and explicit verification of correct cross-locale links and canonical/hreflang output. Verify the PHP version floor aligns with our runtime before committing the upgrade window.

Sequencing. Order matters and is where most of the schedule risk lives:

1. Dependency bump first (4.1.0 into the existing app) — low risk, unblocks Laravel 13, independently shippable and reversible.
2. Pipeline build in a non-production environment — config, base URL, include/exclude, CI job, pass-through files.
3. Interactive-feature remediation — forms, search, comments, experimentation each resolved to a vendor or edge function, each with its own cost line.
4. CDN/hosting cutover — DNS, cache invalidation hooks, rollback plan to the dynamic origin.
5. Multisite/locale expansion, if in scope, after single-site output is validated.

Do not compress steps 2–4 into a single release. Static delivery is a cutover, and the rollback path (keep the dynamic origin warm for a defined window) should be a written decision, not an assumption.

Operational Impact

Maintenance. Bought, not built. First-party addon maintained upstream by the Statamic team; maintenance cost to us is version alignment, not authoring. 4.1.0 signals active upstream maintenance with a clean semver-minor and no deprecations, which is the low-risk shape you want from a dependency. The ongoing obligation is keeping SSG, Statamic core, and Laravel in a compatible triple — and the failure mode of drift is asymmetric: an SSG version lag pins the whole host application's framework upgrade, which turns a small addon into a portfolio-wide blocker on the next major Laravel release.

Support. No production PHP runtime means a dramatically reduced support surface: no server to patch, no PHP-FPM tuning, no database to back up for the public site, smaller attack surface. That is the strongest operational argument and belongs in the exec pitch. But support does not disappear, it relocates: the incident surface moves to the build pipeline and CDN. On-call needs an answer for a failed build at publish time, a bad cache invalidation, and a CDN misconfiguration — none of which the current runtime-oriented runbooks cover. Assign pipeline ownership explicitly before cutover; "the build is broken" with no named owner is the predictable first incident.

Scaling. Two distinct axes, often confused.

• Traffic scaling is excellent. Static files behind a CDN scale near-linearly at near-zero marginal cost. This is the primary business case: page speed, uptime, and hosting spend collapsing toward zero.
• Content scaling is linear and bounded by build time. Generation is a full rebuild, not incremental, and duration grows roughly with page count. At tens of thousands of pages, build time becomes the constraint on publish cadence, and per-publish full rebuilds become the bottleneck. Before committing, measure actual build duration at realistic page count — that number, not the marketing claim, determines whether the staleness budget holds as the site grows.

Failure modes. Enumerate these in the risk register with an owner and a detection method for each:

• Broken base URL / APP_URL → site deploys with broken links and assets. Detect with post-build link checking gated into the deploy.
• Stale destination directory → removed or renamed pages keep serving. Mitigate with clean-output builds, not incremental overwrites.
• Silent feature loss → forms, search, redirects quietly 404 or no-op in production because middleware and request-time handlers don't exist in static files. Detect with an explicit pre-cutover feature-parity checklist per route class.
• Crawl misses unlinked routes → pages absent from the build with no error. Detect with page-count assertions and sitemap-driven include rules.
• Staleness outside the agreed budget → editors publish, nothing appears, trust in the CMS erodes. Detect with publish-to-live latency monitoring, not by waiting for a complaint.
• Cache invalidation failure → new build deployed, CDN serves old content. Needs an automated invalidation step and a manual purge runbook.
• Build infrastructure coupling → a crawl-based build requires a correctly serving app in CI; environment drift between CI and production produces builds that pass and sites that are wrong.

Ramp-up. Team-level, not deep. Developers need to learn config, include/exclude semantics, and CI wiring — days, not weeks. Editors see no change to the authoring workflow, which is the strong argument for adoption and should be stated plainly in stakeholder comms. The genuine ramp-up cost is institutional: shifting the team's mental model from "the server renders it" to "the pipeline rendered it earlier." That shift surfaces in runbooks, on-call rotation, incident response, and release process. Budget for writing those down rather than assuming they transfer.

Ramp-up sequencing recommendation. Ship the 4.1.0 bump independently and quickly — it is a low-risk unblocker and should not wait on the delivery-model decision. Run the static-delivery evaluation as a separate track with its own business case, its own staleness-budget sign-off from the content stakeholders, and a defined pilot surface (a docs portal or a sub-brand microsite is the right first target; a flagship marketing site is not). Prove the pipeline, the invalidation, and the interactive-feature replacements on the pilot before contemplating a flagship cutover.