homarr-labs/dashboard-icons: A CDN-Hosted Icon Set for Self-Hosted Dashboards

The Naming Problem dashboard-icons Actually Solves

Anyone who has assembled a self-hosted dashboard has hit the same wall. You have twenty services running, each with its own logo buried somewhere on a vendor site or a press kit, in whatever format that vendor chose. The file names disagree with each other. Half are white-on-transparent and vanish against a light theme. You end up with a folder of assets that no one else can maintain. This repository addresses that specific mess. It is a curated collection of over 1800 icons for services, applications and tools, according to the README, aimed at dashboards and app directories. The audience is narrow and identifiable: people running Homarr, Homepage, Dashy, Heimdall, Homer or similar tools who want the visual layer handled centrally. The value is not the artwork itself, which belongs to the respective vendors. It is the naming discipline and the format matrix applied uniformly across all of it.

Kebab-Case Names, Three Formats, Two Variants

The repository's real interface is a naming convention. Names are kebab-case, lowercase with hyphens, so a service called Nextcloud Calendar becomes nextcloud-calendar. That rule is mechanical, which means you can predict a URL before you check whether the file exists. Each icon is published in SVG as the original source, plus PNG and WEBP rendered at 512px height. The README describes the raster formats as auto-generated, so the SVG is the canonical artifact and the others follow from it. Variants use suffixes: -light for icons intended for dark backgrounds, -dark for icons intended for light backgrounds. Note the inversion, because it trips people up. The suffix describes the icon's own colouring, not the theme you are placing it on. The README's own examples are github-light.svg and github-dark.svg. There is no documented naming escape hatch for services whose names collide, and no documented versioning scheme for individual icons. If a vendor rebrands, the file at that path changes.

Two Base URLs and the Trade-Off Between Them

Icons are addressed with a pattern: base URL, then format, then icon name and extension. Two base URLs are documented. The recommended one is jsDelivr at https://cdn.jsdelivr.net/gh/homarr-labs/dashboard-icons, and the alternative is GitHub direct at https://raw.githubusercontent.com/homarr-labs/dashboard-icons/main. The README's example is an img tag pointing at cdn.jsdelivr.net/gh/homarr-labs/dashboard-icons/svg/plex.svg. The distinction matters more than it looks. The jsDelivr path is a CDN with caching and a separate availability profile; the raw GitHub path resolves against the main branch, so it tracks whatever is currently committed. Choosing raw GitHub means your dashboard's icon URLs are coupled to the branch state rather than to a cached edge copy. The README does not discuss rate limits, cache invalidation or fallback behaviour for either option, and I cannot confirm those from the supplied material. Command-line retrieval is documented with curl and wget examples against the jsDelivr URL, which is the pattern you would use if you wanted to vendor the assets locally instead of hotlinking them.

Getting an Icon Into Your Dashboard

There are three documented paths. The first is the browser: go to dashboardicons.com, search, open the icon detail, pick a format, then download it or copy the direct link. The second is the URL pattern itself, pasted into whatever field your dashboard uses for a custom icon. The README's HTML example is the clearest form of this: an img element with src set to the jsDelivr URL ending in svg/plex.svg and alt text of Plex. The third is shell retrieval, documented as curl -O with the same jsDelivr URL, or the wget equivalent, if you want the file on disk. Beyond those, the repository exposes an MCP server so that clients such as Cursor can search the collection and retrieve CDN URLs programmatically; the README points to web/docs/MCP.md for that. There is no documented npm package, no import path, and no config file that the repository asks you to write. That is the whole integration surface, and its smallness is deliberate.

The Submission Flow Bypasses GitHub on Purpose

Contribution is where this project's design choices are most opinionated. The README states plainly that the preferred route is the submission form at dashboardicons.com, and it carries a warning block saying that submitting an old-style GitHub issue instead may take significantly longer to be reviewed. Submissions through the form can be approved and published directly by admins or contributors of Homarr Labs. So the review queue lives in a web application, not in the repository's issue tracker, even though the issue templates still exist as the slower alternative. If you want to help triage, the README asks you to make contact through the project's Discord or by email at homarr-labs@proton.me, and it describes an admin role on the site. For a consumer of the icons, the practical consequence is that a missing icon is a request against a form rather than a pull request against a directory, and the turnaround depends on a small group of volunteers. There is no documented SLA, and the README does not state how long review takes.

Where a Static Asset Collection Stops Being Enough

The honest limitation is that this is a pile of files with a naming scheme, not a versioned dependency. If you hotlink from jsDelivr, an icon can change appearance under you when a contributor updates the source SVG, and nothing in the README describes a pinning mechanism, a content hash, or a changelog per icon. The repository has no retrieved releases in the supplied material, so there is no release train to pin to. Offline or air-gapped deployments get nothing from the CDN pattern and must vendor the files themselves, at which point you own the update problem the project was solving. There is also a licensing layer that the README is careful about: the disclaimer states that all product names and trademarks belong to their respective owners and that icons are used for identification purposes only, without implying endorsement. The website additionally indexes externally hosted icons from Simple Icons through its colorable CDN, and the README notes that the CC0-1.0 collection licence on that subset does not waive third-party trademark, patent or brand-guideline restrictions. If your use is commercial or promotional rather than identificational, that caveat is the thing to read before anything else. I am not in a position to give legal advice on it, and neither is the README.

How It Differs From Self Icons and Simple Icons

The obvious alternative for a self-hosted dashboard is Self Icons, which solves the same visual problem from the opposite direction: it generates icons from a service's favicon or from a URL you supply, so coverage is effectively unlimited and no one has to approve your request. The difference in approach is curation versus generation. dashboard-icons gives you a hand-checked, stylistically uniform SVG with light and dark variants, which is why a row of them looks like a set rather than a collage. Self Icons gives you whatever the service's favicon happens to be, at whatever quality, with no variant suffix and no guarantee it reads well at small sizes. The second comparison sits inside this project's own README: Simple Icons is a general-purpose brand icon library, and dashboard-icons indexes a subset of it through the Simple Icons CDN with brand-colour, black and white variants, crediting the source on each external icon page. Simple Icons is broader on brands and narrower on the dashboard-specific long tail of self-hosted tools. If your dashboard is mostly mainstream commercial services, Simple Icons alone may cover you. If it is mostly self-hosted software, that is exactly the gap dashboard-icons was built to fill.

Maintenance Cost and the Apache-2.0 Question

For a consumer, maintenance cost is close to zero as long as you hotlink: there is nothing to upgrade, no dependency to bump, no build step. The cost moves to the maintainers, who review submissions through the website form and regenerate the PNG and WEBP derivatives from the SVG sources. The README describes the raster formats as auto-generated but does not describe the generation pipeline in the material supplied, so I cannot say how that runs or how often. The repository itself is Apache-2.0. That licence covers the repository's own contents, and it does not extend to the trademarks depicted in the artwork, which the disclaimer addresses separately. The Simple Icons subset carries CC0-1.0 for the collection, and the README is explicit that this does not waive third-party brand restrictions. If you are redistributing the icons as part of a product rather than using them to label services in your own dashboard, the licence file and the disclaimer are the two documents to read in that order. Nothing here is legal advice, and the README does not attempt to resolve the tension between an open licence on the files and the brand guidelines on what the files depict.

Editorial conclusion

Adopt it if you run Homarr, Homepage, Dashy or a similar dashboard and want consistent iconography without curating your own assets, and if referencing icons by CDN URL fits your setup. Do not adopt it if you need guaranteed long-term asset stability, offline operation, or a licence grant covering the trademarks in the artwork, since the repository explicitly disclaims endorsement and the CC0-1.0 terms on the Simple Icons subset do not waive third-party brand restrictions. Verify first that the exact icon names you need resolve under the kebab-case convention, and that your dashboard accepts a remote URL rather than requiring a local file.

Official sources

1. homarr-labs/dashboard-icons on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README