Updater Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy vs. adopt for self-update capability. This is the "adopt" option on the table for shipping in-application updates: fetch a release artifact, verify it, extract it, run migrations, restart. Evaluating it forces the real decision — adopt something, buy a managed distribution platform, or build a thin, signed, rollback-capable updater in-house.
• Roadmap input for self-hosted / on-prem distribution. The underlying need is real and recurring: customers running our PHP application on their own infrastructure who we cannot reach with CI/CD. If that segment is on the roadmap, update mechanics are a prerequisite, not a nice-to-have — and this package's high opportunity score reflects that gap, not the quality of the artifact.
• Deployment architecture fork: in-app updater vs. immutable images. Choosing an in-app updater implies mutable, long-lived application instances with write access to their own code. Choosing container images plus a registry implies replacing this entire category of tooling. Worth deciding explicitly rather than by default.
• Stack-fit triage — and a correction to the premise. Despite the framing, this is a Symfony bundle from the Superdesk Web Publisher lineage, not a Laravel package. It has no service provider, no config/updater.php, no Artisan command, and no auto-discovery. For a Laravel codebase it is not installable as a dependency; its value is purely as a reference design for what a self-updater must contain: version manifest, artifact fetch, checksum/signature verification, migration hooks, atomic swap, rollback path.
• Security-surface scoping. An updater is by definition a remote-code-execution channel into production. Reviewing this package is a useful forcing function to define our signing, checksum, backup, and rollback requirements before we ship anything in this category, rather than retrofitting them after an incident.
• Dependency intake policy calibration. A concrete test case for our OSS intake rules: archived status, copyleft license, near-zero adoption, and a privileged execution path all in one package. If our policy doesn't catch this, the policy needs work.

When to Consider This Package

Realistically, adoption requires all of the following — and even then it is a hard sell:

• You are running Symfony 2/3-era code following Superdesk Web Publisher conventions and can consume a bundle through AppKernel/config/bundles.php. Not Laravel.
• You accept AGPL-3.0. For a network-delivered product the §13 network clause is the deciding factor: users interacting with the service over a network must be offered the source. For most commercial SaaS or closed-source on-prem products this is a blocker, not a negotiation.
• You accept archived, unmaintained code inside a privileged execution path. No security patches, no upstream triage, no escalation path — for a component whose entire job is writing files and executing update logic on production hosts.
• You are comfortable with 1 star and 0 dependents: no ecosystem validation, no community troubleshooting, no third-party production track record to learn from.
• You are prepared to fork and own it, including a Symfony-to-Laravel bridge if you're on Laravel, plus ongoing license compliance.

When to look elsewhere:

• Laravel stack → not applicable. Build a small UpdateApplication Artisan command (manifest fetch via Http, ZipArchive extraction, Process for artisan migrate --force and optimize:clear), or use Deployer / Envoyer / a hosted release service.
• You can use containers → prefer immutable images and a registry; that removes the problem class and most of the risk outright.
• You want the pattern, not the code → read the underlying ahilles107/updater (it is small — a handful of classes) and implement a signed, rollback-capable updater scoped to your own release format.
• License-sensitive commercial product → any AGPL dependency in the delivery path needs legal sign-off; assume it will be refused.
• You need vendor support, SLAs, or a security review trail → there is nothing here to support.

How to Pitch It (Stakeholders)

Recommendation: do not adopt. Treat it as a design reference and a demand signal.

For executives: there is a genuine, underserved need here — self-hosted customers need a safe way to receive updates without our operations team touching their servers. That need is why this package scores high on opportunity despite almost no adoption. But the artifact itself is abandoned, carries an AGPL license incompatible with our commercial model, and has no user base. More importantly for us, it is a Symfony bundle, so it doesn't fit our Laravel application at all — adopting it would mean paying a fork-and-bridge tax on top of the legal exposure and an unpatched code-execution path. The right move is a short, time-boxed spike to define our own minimal updater or select a supported distribution product. Budget days, not a quarter.

For engineering: don't install it — read it. The ahilles107/updater core is small and shows the shape of the problem clearly: version manifest, artifact retrieval, checksum/signature verification, extraction, file swap, migration execution, rollback. Copy the shape, not the code. Build the smallest thing that satisfies our signing and rollback requirements — CLI-only, never web-request-first, maintenance mode around the swap, backup before extraction, atomic releases/<version> plus current symlink rather than in-place copies, and verify the archive before you unpack it. Threat-model the update channel before the first line is written: a hijacked manifest URL is a straight path to RCE, and that is the whole risk of this feature in one sentence.