Solder Laravel Package

Product Decisions This Supports

• Build vs. buy for modpack distribution. Solder is not a library you composer require — it is a self-hosted Laravel application that implements the Technic Launcher's pack-delivery protocol. The decision it informs is "do we spend a sprint building a pack/build/version catalog API with MD5-verified artifact serving, or do we fork this and spend the sprint on differentiation instead?"
• Roadmap sequencing. If launcher or community-server distribution is on the roadmap, Solder covers the commodity layer (pack → build → modversion hierarchy, client keys, mirror URLs, S3/CDN-backed artifact delivery). That frees engineering capacity for the parts users actually judge you on: pack authoring UX, moderation, analytics, entitlements.
• Ecosystem/interop bets. Adopting it is a commitment to the Technic wire format. That is a product decision about which launchers your packs must serve, not an implementation detail — the API shape is dictated by the client, so you inherit its constraints (MD5 as the integrity primitive, the pack/build/version model, key-gated private packs).
• Vendor and maintenance posture. MIT licensed, with disciplined release hygiene visible in the repo (semantic tags, CHANGELOG.md, auto-generated GitHub releases, SOLDER_VERSION pinned in AppServiceProvider). That supports a "fork and own" strategy with a low legal and process burden.
• Platform fit. It targets a stack we can staff: PHP 8.4, Laravel 13, Sanctum, Fortify, MariaDB in production, PostgreSQL for dev, PHPUnit tests, Pint, and two non-layered Docker Compose stacks. Relevant as a criterion if you are weighing "adopt a PHP service we can operate" vs. "rewrite the same CRUD in our primary language."
• Not supported by the data: treating it as an ecosystem dependency or a growth bet. 181 stars and 0 dependents means there is no downstream community to absorb breaking changes for you; the Opportunity score (18.14) is weak and the package shows no compounding adoption curve.

When to Consider This Package

Consider it when:

• You distribute Minecraft modpacks to Technic Launcher users, or you are building/maintaining a launcher that speaks the Solder API and want a reference implementation that is already documented (docs/api/read/root.md defines the versioned root contract — usable for your own client contract tests).
• You want a working admin surface today — pack/build management, client keys for private packs, MD5 generation, mirror/CDN configuration — rather than a blank Laravel skeleton.
• Your team is already Laravel-fluent. The repo ships agent/contributor conventions (boost.md, laravel.md, php.md, testing.md, releasing.md) that make onboarding a PHP engineer cheap and make a fork genuinely maintainable.
• You need small surface area to audit and fork. A single-purpose Laravel app with feature tests is far cheaper to own than a bespoke distributed artifact system.
• You are comfortable with operational ownership: a stateful PHP app plus MySQL/MariaDB you deploy, patch, and upgrade yourself.

Look elsewhere when:

• You need a general-purpose artifact or package registry (multi-format binaries, retention policies, org-wide access control). Use object storage + CDN or a dedicated repository manager; Solder's domain model is modpacks, not arbitrary artifacts.
• You target Modrinth or CurseForge as the distribution channel — use their APIs with a thin service of your own and skip this entirely.
• You need multi-tenant SaaS: authorization is admin-centric single-instance, so tenant isolation, quotaing, and per-customer billing become a fork-level rewrite, not a config change.
• You cannot staff a PHP service owner. Dependents = 0 means you will not get upstream fixes you didn't write.
• Security must be pristine out of the box. Plan for a threat-model pass before exposing the admin UI: Fortify-based auth is a starting point, not a finished posture, and MD5-based integrity checking is a compatibility requirement rather than a modern guarantee.
• You are not on the Technic protocol at all. Protocol lock-in without a corresponding user base is pure cost.

How to Pitch It (Stakeholders)

For executives (one paragraph). Solder is an MIT-licensed, self-hosted service that publishes Minecraft modpacks and their version history to the Technic Launcher. Buying it means we do not build, test, or maintain the pack-distribution API ourselves — we host it and fork it where we need to differ. Cost is infrastructure and a small ongoing maintenance allocation, with no license fee and no vendor contract. The honest caveats: it is a small project (181 stars, no downstream dependents), so it arrives as a codebase we own, not a supported product; and it commits us to one launcher ecosystem. Recommendation is to adopt it as a fork for the distribution layer and not extend it beyond that — it is a floor to stand on, not a platform to build on.

For engineering. It is a Laravel 13 / PHP 8.4 application on Sanctum and Fortify, with a documented versioned API contract, PHPUnit coverage, Pint formatting, and two deliberately separate Docker Compose stacks (dev on PostgreSQL, shipped production stack on MariaDB — do not merge them). Domain model is well-bounded: packs, builds, modversions, client keys, mirrors. Expect to own upgrade cadence against Laravel majors, run a security review before the admin UI is internet-facing, and treat the API docs directory as the compatibility contract we cannot break for existing launcher clients. Adopting it trades roughly one to two sprints of greenfield API work for a code review, a deployment, and a fork policy.