Blade Selfhst Icons Laravel Package

Product Decisions This Supports

• Icon strategy for self-hosted/service-catalog UIs. blade-selfhst-icons wraps the selfh.st icon set as Blade components, so it directly supports product surfaces that display third-party self-hosted software logos — service launchers, homelab dashboards, integration directories, admin "connected apps" panels, status pages.
• Build vs. buy on asset plumbing. The real cost here isn't the SVGs; it's curation, naming normalization, and ongoing upkeep as upstream app logos are added or rebranded. This package is the "buy" side of that trade — small dependency, no service, no runtime cost.
• Roadmap signal for integration catalogs. A release adding 15 icons and removing 1 is a proxy metric for how fast the self-hosted ecosystem churns. If your roadmap includes "support N integrations visually," this package's release cadence is a cheap way to track coverage without owning the artwork pipeline.
• Scope control. Adoption commits you to Blade-rendered, build-time-resolved icons. That's fine for server-rendered Laravel views; it's a decision against runtime/API-driven icon delivery or client-side dynamic icon lookup.
• Risk flag from this release: the icon set changed in a patch version (v0.3.12) and it removed an icon. Icon identifiers are effectively a public API for a package like this. Any product surface that hard-codes icon names can break on a composer update with no semver warning. Treat icon names as pinned asset references, not stable identifiers.

When to Consider This Package

Adopt when:

• You're on Laravel + Blade and already render server-side views — zero integration friction, no JS bundle impact.
• Your UI shows self-hosted / open-source app logos (Jellyfin, Nextcloud, Grafana, etc.) and you'd otherwise be hand-managing SVGs and naming conventions.
• You want self-hosted, no-CDN assets — no third-party icon CDN in your dependency chain, no external request at render time.
• You accept pre-1.0 churn. At 0.3.x there is no stability guarantee; the maintainers may rename or drop icons in any release, as this one demonstrates.

Look elsewhere when:

• You need arbitrary or general-purpose iconography — this is a narrow, ecosystem-specific set, not a Font Awesome/Heroicons replacement.
• You need runtime-configurable icons (user-uploaded, admin-authored, or data-driven from a DB) — Blade components resolve at compile/render time from a fixed set.
• You're not on Blade, or your front-end is a SPA/Inertia app that would prefer an npm icon package or raw SVG sprite.
• You require semver-safe asset contracts. If icon names are referenced across teams or in persisted config, wrap this package behind your own enum/adapter layer — or vendor the SVGs you actually use and own them.
• The set overlaps with icons you already ship. Mixing two icon sources produces inconsistent stroke weights, viewBoxes, and visual sizing that design will notice.

How to Pitch It (Stakeholders)

For executives (one line): A small, free Laravel dependency that gives our Blade views a maintained set of self-hosted application logos, so we don't spend engineering time sourcing and normalizing artwork — trading a minor third-party dependency for saved design and maintenance effort.

For engineering (the honest version):

• It's a thin Blade component wrapper over the selfh.st icon set. Low blast radius: render-time only, no migrations, no service, no runtime dependency.
• Pin the version. This release (v0.3.12) added 15 icons and removed 1 in a patch bump. Icon names are not a stable interface pre-1.0. Do not let composer update float this package in production without review.
• Mitigation if we adopt: consume icons through one internal adapter (a PHP enum or a single Blade wrapper) so an upstream rename is a one-file fix, and add a smoke test asserting every icon name we reference actually exists.
• Cost of exit is near zero — worst case we vendor the SVG files ourselves. That's why the buy decision is low-risk.
• The only real risk is cosmetic breakage from a dropped icon, not data loss or downtime. Which is why the recommendation is: adopt with version pinning and an adapter layer, not with direct icon-name references scattered through templates.