- What is codedge/laravel-selfupdater used for?
- It is a Laravel package that adds basic self-update functionality to an application, letting it check for, download, and install new releases from sources such as GitHub or a private HTTP repository. It is a thin wrapper around resolving a remote release, comparing versions, and extracting an archive over the existing application tree. It is not a deployment system, so it does not provide atomic releases, rollback, or health verification on its own.
- Which Laravel and PHP versions does codedge/laravel-selfupdater support?
- The package targets the Laravel 8 to 10 era, and because the repository was archived in 2025 there are no guarantees for Laravel 11, Laravel 12, or future PHP 8.x releases. Validate PHP version ceilings and framework compatibility in a spike against your actual target matrix before planning. If you need Laravel 11 or newer, budget for a maintained fork from day one rather than assuming upstream fixes.
- How do I install and configure codedge/laravel-selfupdater?
- Installation is a standard composer require followed by publishing the package configuration, then wiring up an artisan command or route that triggers the update check. You configure the update source, either GitHub or a private HTTP endpoint, along with any required credentials in the published config file. Check the package documentation for the exact option names in your version.
- Can it update from a private repository instead of GitHub?
- Yes, the package bundles methods for a private repository delivered over HTTP alongside the GitHub option. You point the configuration at your endpoint and supply whatever authentication the source requires, such as a token. Keep in mind that you own the security of that endpoint, including authentication, signing, and availability.
- Is codedge/laravel-selfupdater safe to use in production?
- Treat it as a privileged code-execution path rather than a convenience feature. The repository is archived, so it receives no security patching or CVE response, and basic GitHub or HTTP update flows rarely include signed manifests or checksums by default. A compromised update endpoint would mean arbitrary remote code execution on every installation, so adopt it only with hardening funded as first-class scope.
- Does it handle database migrations and rollback if an update fails?
- No, the package does not provide transactional semantics; it downloads and extracts an archive over a live application tree, so a partial failure can leave a mixed-version application with no defined recovery. Database migrations compound the problem because code and schema can desynchronize mid-update. Rollback, atomicity, and health verification become your engineering responsibility.
- What alternatives should I use instead of a self-updating Laravel app?
- If you control the host, use your existing release pipeline such as Laravel Forge, Envoyer, Deployer, GitHub Actions, or Kubernetes, because those are reversible, auditable, and add no new risk. Self-update is only a plausible fit when you distribute a self-hosted artifact to customers whose environments you cannot reach with CI/CD. For SaaS deployments, integrating this package is a redundant and inferior copy of the pipeline you already own.
- Is codedge/laravel-selfupdater still maintained?
- No, the repository is archived and sits at around 398 stars with a community score of 2.18. Archiving means no compatibility updates for newer Laravel or PHP releases and no security fixes. Plan for a fork-and-patch maintenance cost for the life of your product if you adopt it.
- What file permissions does the self-updater need, and does it work with S3 or remote filesystems?
- The PHP process needs write access to the application root and vendor directory, which contradicts the usual production posture of read-only code and immutable images. It is intended for local filesystem use only, so do not attempt it on S3 or remote mounts. Also consider that mutating code beneath a running process invalidates opcache and autoloaders and can affect in-flight requests.
- How can I test the self-update flow before shipping it?
- Run the flow against a staging copy that mirrors your production layout, pointing the configuration at a test release or a mock HTTP endpoint. Watch for GitHub API rate limits and verify token scopes and rotation for private repositories. Confirm what happens when extraction succeeds but migrations or health checks fail, since the package gives you no rollback.