Updater Bundle Laravel Package

Getting Started

Before anything else: this is a Symfony bundle from the Superdesk Web Publisher lineage, not a Laravel package, and the repository is archived. You cannot composer require it into a Laravel app and get a working updater — there is no service provider, no auto-discovery, no config/updater.php, and no Artisan command. Treat it as reference source code for the underlying ahilles107/updater library, and port the pattern rather than the package.

If you are genuinely on a legacy Symfony app and want to run it directly:

1. composer require swp/updater-bundle
2. Register SWP\UpdaterBundle\SWPUpdaterBundle in config/bundles.php (or AppKernel.php on Symfony 2/3).
3. Read DependencyInjection/Configuration.php to discover the actual config keys — documentation is thin.
4. bin/console list to find the updater command, then run it with -vvv.

Where to look first (all Symfony side): src/Command/ for the CLI entry point, Resources/config/services.yml for how the updater service is wired, and vendor/ahilles107/updater/src/ for the actual download → extract → replace logic. The underlying library is small — reading it end to end takes less time than reverse-engineering the bundle wiring, and it is the only part with transferable value to a Laravel app.

First Laravel use case you would actually build: an admin-triggered "check for updates and apply" flow. A small UpdateApplication Artisan command hits a static JSON manifest (version, url, sha256, optional channel), downloads the archive with Http::get(), verifies the checksum, extracts into releases/<version>/, runs artisan migrate --force and optimize:clear, then flips a current symlink. The bundle gives you the shape of that flow; you write the Laravel-native implementation.

Implementation Patterns

• CLI-first, never web-request-first. Expose updates as an Artisan command, never as a synchronous HTTP route. Downloads and extraction are long-running and will time out a PHP-FPM worker. Trigger from cron, a supervisor, or an admin UI that shells out to php artisan app:update.
• Manifest-driven, not API-driven. Host a small JSON manifest on a static endpoint keyed by version, url, sha256, channel, php/laravel constraints. Keep version resolution in the manifest; the updater's only job is fetch → verify → extract → swap. This mirrors what the bundle does and is far easier to test.
• Down → backup → update → migrate → clear → up, orchestrated by you. The bundle does not put the app into maintenance mode, snapshot the database, or clear caches. In Laravel this is $this->call('down'), a backup step (Spatie backup or a DB dump), the file swap, migrate --force, optimize:clear, queue:restart, opcache reset, then $this->call('up').
• Atomic releases over in-place copies. Extract into releases/<version>/, run migrations against the new release, then flip a current symlink. Rollback is a symlink flip back plus a DB rollback. This is the single pattern most worth copying from the package's design, and it fits Laravel's Storage/File facades cleanly.
• Port the library, not the bundle. ahilles107/updater is tiny — a handful of classes for download, unzip, copy. Vendoring that logic into an internal App\Services\Updater behind an interface (with your own signing/checksum verification) is cleaner than reproducing Symfony DI wiring for an unmaintained dependency.
• Config surface in Laravel: a config/updater.php with manifest_url, channel, backup_path, allow_prerelease, releases_path, current_symlink, verify_signature, timeout. Bind it to a service provider and register the Artisan command — the equivalent of the bundle's service definition and command registration, but idiomatic Laravel.
• Extension points (Symfony side, for reference). The bundle lets you decorate the updater service or override constructor arguments in services.yml to inject authenticated downloaders, custom logging, or post-extract hooks. In the Laravel port, these become driver bindings (e.g., a Downloader contract with Http, S3, or Local implementations) and events (UpdateDownloaded, UpdateApplied, UpdateFailed) for post-extract hooks.
• Keep the web user read-only. Run the updater as a separate deploy user with write access to releases/ and current; the PHP-FPM user should never be able to write to application code. This is the operational pattern the package assumes and the one you must preserve.

Gotchas and Tips

• Archived, 1 star, 0 dependents. No maintenance, no security patches, no one to escalate to. Given that the package's job is to write files and execute update logic on production hosts, "archived" is effectively disqualifying for a dependency — fork-and-own is the only realistic stance.
• AGPL-3.0 is a real constraint. In a network-delivered Laravel product, the AGPL §13 network clause obligates you to offer source to users interacting with the service. For most commercial apps this is a legal blocker, not a negotiation. Get sign-off before adopting, or port the pattern into your own code.
• No Laravel auto-discovery, and Composer conflicts are likely. The bundle targets older Symfony/PHP constraints that will collide with Laravel's bundled Symfony components. Do not assume you can install it "just to look" in your app — sandbox it in isolation or read the source.
• It moves files, nothing more. No migrations, no config:cache, no queue restarts, no opcache reset. All schema changes, compiled-view clears, and worker restarts are your responsibility to sequence after the extract.
• Verify the archive yourself, and then some. Checksum verification (ideally minisign/signature) before extraction is non-negotiable — a hijacked manifest URL is a straight remote-code-execution path into production. The package's verification (where present) is not the same as your security policy; assume you must add signature verification.
• Permissions pain. Extraction runs as the CLI/deploy user and needs write access to app directories, which fights normal hardening. Expect permission errors as the most common failure; document the deploy-user ownership model before the first run.
• Debugging workflow. Run with -vvv (Symfony) or --verbose (Artisan port), tail storage/logs/laravel.log, and first confirm the manifest URL is reachable from the server — proxies, TLS certs, and redirects are frequent culprits. The two most common real failures are a 404 on the manifest and an unwritable target directory.
• Security review up front. An updater is a deliberate RCE surface. Threat-model download authenticity, manifest integrity, archive path traversal (../ in zip entries — validate and reject), symlink handling during extraction, and rollback before writing the first line. The package has had no such review; you cannot inherit safety from it.
• Multi-instance deployments need a lock. The updater does not coordinate across instances. Wrap the run in an atomic lock (Cache::lock()), and only run on one instance at a time, or every node will try to extract concurrently.
• Skip the bundle, read the library. Because ahilles107/updater is small, vendoring the two or three classes you need into a Laravel service — with your own manifest format, signature checks, atomic swap, and rollback — is almost always cleaner than dragging an unmaintained Symfony bundle into a Laravel codebase it was never designed to fit.