Updater Laravel Package

Getting Started

Start by reading the repository before installing it. With 1 star, 0 dependents, and a single maintainer, there is no community safety net — the only trustworthy documentation is composer.json, the service provider, and the console commands in src/. Because this package is purpose-built for the Redot dashboard, the first thing to confirm is that your host application is a Redot dashboard instance; if it isn't, architectural fit is effectively zero and you should stop here.

Minimal setup on a non-production branch:

composer require redot/updater

If Composer requires a custom repository, a minimum-stability override, or a dev branch constraint, treat that as a red flag before you go further.

Next, register and publish. Auto-discovery should register the provider, but verify it:

php artisan package:discover   # confirm Redot\Updater\... is listed
php artisan vendor:publish --provider="Redot\Updater\UpdaterServiceProvider"

Check what got published — an updater.php config (update endpoint, channel, install path) and possibly a migration. Read every key. Then inspect the command list:

php artisan list | grep -i updat

Expect something in the shape of updater:check, updater:update, and possibly updater:install. Inspect their signatures and any --dry-run/--force flags before running them.

First use case: a read-only version check on staging. Clone your production dashboard to a disposable staging instance, run the check command, and confirm it can read the installed version and compare it against the remote manifest. Do this with network egress logging enabled so you can see exactly which host it contacts. Do not run updater:update until you've seen the check succeed and read the download/apply code path.

Have the escape hatch ready before you start: a pre-migration database dump and composer remove redot/updater as the documented rollback.

Implementation Patterns

Decouple "check" from "apply." These are different risk profiles and belong in different execution contexts. Run updater:check on a schedule and surface the result in the dashboard; run the apply step only on explicit admin action, and never inline in a web request.

// app/Console/Kernel.php or routes/console.php
$schedule->command('updater:check')->dailyAt('03:00');

Persist the check result. Cache or store the available version, release notes, and channel so the dashboard can render an "update available" banner without hitting the remote endpoint on every page load. Key it by installed version + channel so a stale entry is obvious.

$available = Cache::remember('updater.latest', now()->addHours(6), fn () =>
    app(\Redot\Updater\Updater::class)->latest() // adjust to the actual API
);

Run the apply step in maintenance mode, from the CLI, via a queued job. The apply path will write files and run migrations; doing that mid-request risks a half-updated app serving traffic. The safe shape:

Artisan::call('down', ['--render' => 'errors::503']);
try {
    Artisan::call('updater:update', ['--force' => true]);
} finally {
    Artisan::call('up'), // always bring back up
}

Wrap it in a queued job with a generous timeout and a single-worker lock (->withoutOverlapping()), so two admins clicking the button doesn't double-apply.

Wrap it, don't expose it directly. Put your own command or job in front of the package's commands so you control logging, notifications, and the pre-update backup. The package becomes an implementation detail you can swap or fork.

Log::info('updater.start', ['from' => $current, 'to' => $target]);

Gate the dashboard UI behind an admin gate. If the package ships routes, they are almost certainly mounted under web. Verify the middleware stack and add auth + an authorization gate if it isn't already there. An update endpoint reachable by any authenticated user is a privilege-escalation surface.

Keep customizations outside the update path. Put your overrides in app code, not by patching vendor files that the updater will replace. The updater's write paths define what "your application" means for updates; anything you've edited inside those paths is at risk on every run.

For fleets, use it to generate, not to mutate. The most defensible integration for anything beyond a handful of self-hosted installs is to have the package produce a signed artifact that flows through your CI/CD pipeline, rather than letting it rewrite live servers. That keeps you inside your existing change-management and audit story.

Gotchas and Tips

The trust model is the real hazard. A package that downloads and applies code to a running app is a supply-chain surface — whoever controls the update manifest controls code execution on your servers. Check in the source whether downloads are verified (checksum or signature) and whether the remote host is HTTPS-only and pinned. If not, add verification yourself or fork before production.

Writable webroot is a hard requirement. The apply path writes into the application tree. Immutable container builds, read-only filesystems, and hardened deployments may be structurally incompatible regardless of Laravel/PHP version support. Test this first — it's the fastest way to know whether the package is viable in your topology.

Assume partial-failure states exist. File replacement is rarely atomic. If the process dies mid-download or mid-copy, you can end up with a hybrid install that passes no one's checks. Build a snapshot/restore step before the first apply, and design your wrapper to abort loudly on a non-zero exit rather than treating "no exception" as success.

Clear the caches the updater may forget. After an apply, explicitly run php artisan optimize:clear (config, route, view, and opcache if you're on FPM). Stale config or route caches are a classic "it updated but nothing changed" symptom.

Run migrations deliberately. If the package runs migrate for you, confirm it uses --force (production guard) and how it handles a migration that fails partway. If it leaves migration handling to you, do it in the same maintenance window and log the output.

Version comparison quirks. Semver parsing and dev-branch strings (1.2.x-dev, dev-main) are a common source of "wrong update offered" bugs. Test the check against a few malformed manifests and a pinned dev version.

Fake the HTTP layer in tests. Point the config at a local JSON manifest served by Http::fake() and assert both the happy path and a mid-download failure. Without that, you cannot responsibly run this outside a sandbox.

Vendor or fork it. With one maintainer and zero dependents, upstream may go quiet without notice, and any behavior change lands in customer environments without your review. Pin the version in composer.json, or copy the source into your repo and treat it as first-party code — the scope is small enough that a fork is a reasonable outcome, not a failure. Budget an engineer-day to read and document the internals before anyone else operates it.