Weave Code
Symfony Static Dumper Laravel Package
symplify/symfony-static-dumper
Symfony Static Dumper converts a Symfony application into a static HTML site. It crawls configured routes, renders pages, and writes them to disk, enabling fast, low-maintenance static deployments while preserving Symfony routing and templates.
Dump Symfony application to Static Website
Frequently asked questions about Symfony Static Dumper
- What does symplify/symfony-static-dumper actually do?
- It is a CLI tool that boots your Symfony kernel, enumerates the application's routes (or crawls links from a seed URL), dispatches a synthetic Request for each page, and writes the resulting Response body to a target directory as static HTML files. It also copies assets and lets you configure the output path so the folder can be served from a CDN or static host. Conceptually it is Symfony app to folder of HTML, not a templating or content pipeline tool.
- Is symplify/symfony-static-dumper still maintained?
- No. The package now lives under the repository's deprecated-packages directory, has no recorded stars or dependents, and the maintainer has retired it. That means no fixes for newer Symfony internals and no downstream community to absorb the maintenance burden. Treat it as pin-and-pray inside a matching legacy stack, or plan to fork and own it yourself.
- Which Symfony and PHP versions does it support?
- It targets the Symfony 4 and 5 era HttpKernel and Router internals, including route collection iteration, Request::create semantics, and KernelInterface::handle, all of which have shifted in Symfony 6 and 7. There is no official support statement for current Symfony or PHP releases, so verify by running a dump on a branch before committing. Pin it to the exact versions your application already runs.
- How do I install and configure Symfony Static Dumper?
- Add it as a Composer dev dependency, create a config file that defines the output directory, base URL, and the routes to include or exclude, then run the single console command. Installation is mechanically simple; the real cost is proving the dump is faithful. Expect a nontrivial audit of route coverage, trailing slashes, and generated URLs before you trust the output.
- Can it dump pages that require login, sessions, or cookies?
- No. Authenticated content, session-scoped pages, CSRF-protected forms, POST-driven flows, personalized output, and locale or cookie negotiation are all outside what a static dump can represent. The dumper renders with whatever context the kernel has during the run, so per-visitor variation cannot be reproduced. An app with any of those features is usually disqualified outright.
- Does the dumper need a live database and other services during the dump?
- Yes. Because it executes your real kernel against a synthetic request, every runtime dependency is live during the dump, including the database, cache, HTTP clients, mailer, and queue. That is a substantial operational coupling that the phrase static export does not imply. Run it in a controlled environment with only the credentials and data you are willing to render.
- How do I control which routes get dumped?
- Route inclusion and exclusion are handled in the package configuration, and there is also an internal crawler mode that walks links starting from a seed URL. You still need to verify coverage manually, including query-string variants and trailing-slash behavior. Be aware that URLs generated inside page content may point at the live domain rather than the static host, and cache headers no longer apply once files are served from S3 or Netlify.
- Does symplify/symfony-static-dumper work with Laravel?
- No. It is a Symfony-only tool built on Symfony's HttpKernel and Router, so it cannot dump a Laravel application. Laravel teams evaluating static export options should look at a first-party static site generator, a headless CMS export, or another approach entirely. Adding it to a Laravel composer.json will not produce a working site.
- What are the security risks of using it in production?
- The dumper renders pages with production credentials against a live datastore, so a misconfigured inclusion rule can publish internal, draft, or PII-bearing content to a public bucket. Treat that as a release-process risk requiring a hard gate rather than a config detail. Someone on the team should explicitly sign off that a generated dump contains only content intended for public release.
- What are the alternatives if I need an ongoing static publishing pipeline?
- Depending on your goal, consider Symfony's own HttpCache or HTTP client warmup, a headless CMS export, or a first-party static site generator. For a one-time marketing-site export the deprecation matters far less than for a recurring publish pipeline. If you need something maintained, either fork this package as an internal tool or replace it before your next Symfony upgrade.
Weaver
How can I help you explore Laravel packages today?