Weave Code
Updater Bundle Laravel Package
swp/updater-bundle
A Symfony bundle for managing application updates: organize sequential update routines, run them from a command or admin interface, and track which updates have already been applied so deployments stay predictable.
Provides integration for ahilles107/updater which gives an easy way to update your application.
Frequently asked questions about Updater Bundle
- Can I install swp/updater-bundle in a Laravel application?
- Not as a native Laravel package. swp/updater-bundle is a Symfony bundle built around Symfony's kernel, bundle registration, DI container, YAML configuration trees, and bin/console commands, while Laravel uses service providers, Artisan commands, facades, and a different container lifecycle. The only portable piece is the thin ahilles107/updater core, which is small enough to read and reimplement. Treat it as a design reference, not a Composer dependency.
- Does swp/updater-bundle support Laravel auto-discovery or Artisan commands?
- No. There is no Laravel package auto-discovery, no published config/updater.php, and no Artisan entry point. The bundle exposes its workflow through Symfony bundle registration and bin/console commands. You would have to write a Symfony-to-Laravel shim over unmaintained code, which is usually worse than a small first-party implementation.
- How do I install and configure swp/updater-bundle?
- In a Symfony app you would require it with Composer, register the bundle in AppKernel or bundles.php, define its YAML configuration, and run the provided console commands for checking and applying updates. Configuration is handled through the Symfony DI container and configurable services. In a Laravel app there is no supported installation path or config/updater.php to publish, so any integration would be custom glue.
- Which Laravel versions does swp/updater-bundle support?
- None natively. It targets Symfony, not Laravel, so there is no Laravel version matrix, service provider, or Artisan integration to pin. Composer constraints likely reflect the Superdesk-era PHP and Symfony versions rather than Laravel's current pins. Validate the PHP version matrix and Symfony component constraints before spending time on any spike.
- Will swp/updater-bundle conflict with Laravel's pinned Symfony components?
- Likely yes. Laravel pins Symfony components such as console, process, filesystem, and finder, and this bundle's Composer constraints probably target older Symfony versions from the Superdesk era. Composer may resolve, but runtime behavior is not guaranteed. Check autoload behavior, filesystem write permissions, and behavior under config:cache before trusting it.
- Is swp/updater-bundle safe to run as a production updater?
- Treat it as high risk. An updater is a deliberate remote-code-execution channel into production: it writes application files, mutates vendor code, and can trigger migrations, and this package is archived with no security patches or CVE triage. The context does not confirm checksum or signature verification, atomic release directories, or a rollback path. If you evaluate it, isolate it, run it as a user separate from the web worker, and gate it behind legal and security review.
- What license does swp/updater-bundle use, and can I use it in commercial SaaS?
- The reported license is AGPL-3.0, including the section 13 network clause. That is a blocker for most commercial SaaS and closed-source on-prem distribution, because network users must be offered the source. Any direct code reuse carries the obligation, while a clean reimplementation based on documented behavior is lower risk. Get an explicit license review before code enters your repository.
- How does swp/updater-bundle detect and apply updates?
- It provides console commands for checking and applying updates, version comparison to detect pending releases, extensible handlers for custom update steps, and environment-aware execution and logging. The thin core library follows a fetch, extract, copy sequence. The context does not specify the artifact format or whether checksums and signatures are verified, so confirm that before relying on it.
- Is swp/updater-bundle maintained, and what is the long-term risk?
- The assessment describes it as archived, with roughly one star and zero dependents. That means no security patches, no CVE triage, and nobody to escalate to when an update path breaks. If you fork it, name an owner and define an exit plan for a security patch in year two. For most teams the safer move is to own a small first-party implementation.
- What are the alternatives for Laravel, and how should I test or spike an evaluation?
- For self-hosted updates, design a first-party UpdateApplication Artisan command: define a manifest schema with version, channel, URL, and sha256 or signature; use immutable releases/<version>/ directories with a current symlink; and sequence download, backup, extract, migrate --force, optimize:clear, restart queues and opcache, then up, using Http::get, ZipArchive or Storage, and Process. Compare that build against Deployer, Envoyer, or a hosted distribution product. If you still want to evaluate the bundle, time-box a one-to-three-day spike to read ahilles107/updater, document its update sequence, and validate PHP and Symfony constraints, autoloading, filesystem permissions, and config:cache behavior, then stop. The context does not describe a test suite, so any testing is your responsibility.
Weaver
How can I help you explore Laravel packages today?