- What does argws/laravel-updater actually do?
- It adds a generic in-place self-update mechanism to a Laravel application: it fetches a release artifact, replaces application files, and runs post-update steps such as migrations and cache clears, all triggered from an Artisan command. It ships as a standard Laravel package with a service provider, an Artisan surface, and a publishable config file. The intended use case is self-hosted, on-prem, white-label, or long-lived single-tenant deployments where you cannot push releases through your own CI/CD pipeline.
- How do I install argws/laravel-updater?
- Install it with composer require argws/laravel-updater, then publish the config with php artisan vendor:publish and review the artifact source, target paths, and post-update hooks before enabling anything. Do the first run on a throwaway VM or snapshot, not on a live instance, because the package modifies the application root. The package is small enough to read end to end in an afternoon, which is worth doing given the limited documentation.
- Which Laravel and PHP versions are supported?
- There is no English documentation and no published support matrix, so the only reliable source is the composer.json constraints in the repository itself. Check those constraints against your Laravel and PHP versions, and test the update flow on a staging copy before trusting it. There is no visible CI matrix, so do not assume compatibility is verified for your stack.
- How does the package know when a new version is available?
- The update channel is defined in the published configuration, and the README is Portuguese-only, so you need to read the config and source to confirm whether it pulls GitHub Releases, a custom JSON manifest, or an arbitrary URL. Confirm whether the endpoint is hardcoded or configurable, and whether it can be disabled entirely for customers with strict egress rules. Pin the artifact host to something you control before going anywhere near production.
- Does it verify checksums or signatures on downloaded artifacts?
- Verification is not documented, and by design an updater that downloads and executes code makes your artifact host a remote code execution surface. If you adopt this, host artifacts somewhere you fully control over TLS and add your own signature or checksum check before extraction. Do not point it at public release assets you do not own.
- Is the update atomic, and is there a rollback?
- Based on the described behaviour, files are replaced in place rather than staged and swapped, which means a failure mid-update can leave the instance in a state that is neither the old version nor the new one. Partial extraction, disk exhaustion, permission drift, stale OPcache, and open file handles are all realistic failure modes. There is no documented rollback or previous-release snapshot, so take an image or filesystem snapshot immediately before every run.
- Which post-update steps does it run automatically?
- The package is described as running migrations, clearing caches, and restarting queue workers as part of the update. Composer install, config/route/view cache rebuilds, OPcache resets, and storage symlink repair are separate ops concerns you should verify in the source and handle yourself if missing. Put the app in maintenance mode for the duration and test the whole sequence on staging first.
- Will it overwrite my .env file, storage directory, or user uploads?
- Exclusion rules for .env, storage/, and user-generated content are not documented, so verify them in the source before the first real run and back all three up regardless. Overwriting .env silently is one of the fastest ways to take a customer instance down. If exclusions are not configurable, treat that as a blocker rather than a nice-to-have.
- Can I run it on multiple servers, and does it lock against concurrent runs?
- There is no documented multi-node awareness, so each instance would update itself independently and versions can diverge. There is also no confirmed lock against concurrent executions, so two overlapping runs could corrupt the application root. Run it on a single node behind maintenance mode, or wrap it in your own locking and orchestrations.
- Is it safe to use in production, or should I look at alternatives?
- Treat this as reference source code to vendor and own rather than a dependency to trust: it has effectively one maintainer, no dependents, and release metadata with anomalies that undermine provenance signals. For a standard SaaS on Kubernetes or ECS it is redundant and conflicts with immutable-image deployment; for appliance-style distribution it can be a reasonable starting point once you add signing, atomic swaps, and rollback. If you need a maintained alternative, evaluate the code here as a specification and build the update path yourself.