Weave Code
Ssg Laravel Package
statamic/ssg
Statamic SSG is a Laravel-powered addon that generates static HTML from your Statamic site for fast, secure, cache-friendly deployments anywhere. It supports incremental builds, multi-site setups, and familiar content workflows.
Generate static sites with Statamic.
Frequently asked questions about Ssg
- How do I install statamic/ssg in a Laravel Statamic application?
- Install it as a Composer dependency in your existing Statamic project with composer require statamic/ssg, then publish the config file so config/ssg.php exists. Build the static output by running php please ssg:generate from the Artisan entry point. No migrations, schema changes, or production runtime wiring are required. Expect hours to a day of work to get a first build and diff the output.
- Which Laravel and Statamic versions does statamic/ssg 4.1.0 support?
- Version 4.1.0 adds Laravel 13 support and widens the illuminate/* constraints; it contains no public API, config-schema, or generated-output changes versus 4.0. You must confirm those constraints co-resolve with the Statamic core major your site runs. Laravel 13-era constraints typically raise the PHP floor, so check CI images, build containers, and any preview hosts. Because the upgrade itself is non-breaking, version-matrix alignment is the real risk, not the release.
- Can statamic/ssg generate a static site for a Statamic multi-site setup?
- Yes, multi-site setups are supported, and each site's content is compiled into the static output tree. Your crawl scope, includes, and excludes in config/ssg.php determine what each site build covers. Verify route counts per site after the build so a missing site or locale is caught immediately.
- How does incremental generation work in statamic/ssg?
- Incremental builds regenerate only the content that changed instead of rebuilding the whole site each time. Whether you need them depends entirely on your content-freshness SLA: on-publish updates usually mean full rebuilds are fine, while hourly or daily rebuilds of a large site often justify incremental generation. Decide the SLA before you scope the pipeline, because it changes both CI duration and deployment design.
- What do I configure in config/ssg.php?
- config/ssg.php declares crawl scope, includes, excludes, and asset handling for the generator. It is a hand-maintained route manifest, so it is the file that determines what ends up in the static output. Treat changes to it as reviewed code, not as an ad hoc build setting, and keep it in sync with new page archetypes.
- Where can I deploy the static HTML produced by statamic/ssg?
- The output is a plain static HTML tree, so the delivery target is host-agnostic: S3 with CloudFront, Cloudflare Pages, Netlify, or plain nginx all work. That means you can evaluate the CDN on cost and operations independently of the package adoption. The package only writes files to disk through Laravel's filesystem; your deploy orchestration does the rest.
- Does statamic/ssg run in production at runtime?
- No, it is a build-time compiler rather than a runtime dependency. It executes inside your Laravel and Statamic application, crawls internal links, and emits static files to disk. Adopting it moves operational risk out of the public request path (uptime, latency, autoscaling, attack surface) and into the build path (CI duration, artifact correctness, deploy orchestration). Your team then owns the pipeline, which is the larger piece of work.
- How do I test or verify that a statamic/ssg build is complete and correct?
- Add a post-build route-count assertion that compares generated pages against the expected manifest. Pair it with a link checker over the output and a diff against the previous artifact for spot-checking content. You should also alert on build failures, because a broken CI pipeline will happily serve the last good artifact. These controls are cheap but only work if they are planned before launch.
- Why are pages missing from my generated static site?
- The most common cause is silent under-generation: config/ssg.php is a hand-maintained route manifest and nothing in the compiler catches omissions. A page absent from the manifest produces no build error, it simply is not there. This is a permanent low-grade correctness risk rather than a one-time bug. Mitigate it with route-count assertions, a link checker, and reviewed changes to the manifest.
- Is statamic/ssg actively maintained and what adoption risks should I know?
- The repository has a modest star count and effectively zero listed dependents, so peer validation is limited and there is little community troubleshooting to lean on. Expertise must be built internally rather than borrowed from a large ecosystem. The 4.1.0 release itself is low-risk, with only PHPUnit attribute migration and Laravel 13 support changes. Plan for the surrounding pipeline, staleness alerting, and rollback far more than for the package installation.
Weaver
How can I help you explore Laravel packages today?