Product Decisions This Supports
- Self-hosted update strategy. If the Redot dashboard ships to customer-controlled servers, "how do customers upgrade?" is a product decision with a direct support-cost line attached. This package productizes that flow (version check → download → apply → migrate → clear caches) instead of leaving it as a runbook in a knowledge base.
- Build vs. buy vs. fork for update orchestration. The recurring scope — version manifest fetch, download, file replacement,
migrate, asset handling, config/cache clear, failure handling — is small but fiddly and security-sensitive. Given it's MIT-licensed and narrow, this is a credible fork-and-own starting point rather than a from-scratch spec.
- Roadmap sequencing of "one-click update." The decision this most directly informs is whether in-dashboard updating is a v1.0 requirement or a post-launch quality-of-life item. It is cheap to defer while early adopters tolerate documented
composer update steps; it becomes expensive to defer once the installed base fragments across versions.
- Release channel and version-floor policy. Configurable update sources make stable-vs-beta channels, minimum-supported-version enforcement, and gating of breaking schema migrations across customer installs concrete product levers rather than vague intentions.
- Support and success model. Every manual upgrade step is a ticket. An updater shifts support effort from "help me upgrade" to "keep me current," and makes it realistic to hold customers to a supported-version floor — which in turn unblocks deprecation and breaking-change planning.
- Vendor/ecosystem risk register. One maintainer, 1 star, 0 dependents, no external usage signal. Adopting this is a bet on a single project's continuity, not on the broader Laravel ecosystem — the decision should be recorded as such, with a fork as the fallback.
When to Consider This Package
Consider it when:
- You are already operating (or building against) the Redot dashboard. The package is purpose-built for that topology — expected directory layout, config keys, schema, remote manifest — and will fit closer than a generic deploy tool.
- You have self-hosted installs you cannot reach with your own CI/CD, so the update must execute inside the customer's application.
- You want a small, MIT-licensed reference implementation to read, fork, and adapt instead of designing update orchestration from a blank page.
- Your team has Laravel depth to audit a modest codebase and own it indefinitely — because in practice you will.
Look elsewhere when:
- You run a hosted SaaS. There is no in-app updater problem; this only adds supply-chain surface area for nothing.
- You need a supplier with a security-patch SLA, an active maintainer, or third-party adoption evidence. One star and zero dependents means no community vetting and no proxy for reliability on a component that writes files and runs migrations on customer servers.
- The real requirement is deployment orchestration — zero-downtime rollouts, environment parity, blue/green. That is Deployer, Envoyer, container images, or platform release tooling, not an in-app updater.
- You need framework upgrades (e.g., Laravel 10 → 11) at customer sites. That is a codemod/upgrade-service problem (Laravel Shift and equivalents), distinct from "pull the latest release of our app."
- Your deployments are immutable containers or read-only filesystems — the package's core mechanism may be structurally incompatible regardless of version support.
- Procurement requires vendor risk review. A single-maintainer package with no adoption history will not clear it; plan to vendor the source into your own repo and treat it as first-party code.
How to Pitch It (Stakeholders)
To executives: A small, MIT-licensed component that automates updating self-hosted installations of our dashboard. The commercial case is support cost and version fragmentation: every customer on a stale version is a compatibility risk and a manual-upgrade ticket, and an in-app updater is the cheapest known way to shrink both. Adoption cost is low — permissively licensed, narrowly scoped, no new infrastructure. But the evidence behind it is equally thin: one maintainer, negligible public adoption, no disclosed security history. Frame it as a head start on a feature we would otherwise build, not as a strategic dependency, and fund a short engineering review before any commitment. The one-line pitch: "One-click updates for self-hosted customers — cheap to try, cheap to replace, expensive to keep doing by hand."
To engineering: Read the source before adopting. The update path is security-sensitive by nature — it downloads code and writes it into a running application, so whoever controls the update manifest controls code execution on customer servers. Before shipping we want artifact integrity/checksum (ideally signature) verification, a mandatory pre-update backup, a rollback path if migration fails, maintenance-mode handling, and tests around partial-failure states. Expect to pin or vendor the package so an upstream change cannot alter behavior in customer environments without our review. Sequence it as: repository diligence (every outbound host, every write path) → security review with authority to reject → sandboxed PoC on a disposable instance with egress logging → production only with change management and audit logging. If the internals don't meet the bar, fork it — the scope is small enough that a fork is a reasonable outcome, not a failure. Where possible, use it to generate an update artifact that flows through CI rather than letting it self-mutate live servers.