# selfhst/icons is a logo directory for self-hosted software, served by jsDelivr > selfhst/icons is a repository of logos and icons for self-hosted and non-self-hosted software, published in five raster and vector formats and served directly from GitHub through jsDelivr. The free tier gives you light, dark and standard colour variants, while custom colours depend on a paid membership or running your own copy. **selfhst/icons** — Collection of icons and logos maintained by selfh.st - Repository: https://github.com/selfhst/icons - Website: https://selfh.st/icons - Stars: 992 · Forks: 93 - Language: Go - License: CC-BY-4.0 - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/selfhst-icons ## A directory of logos for the tools people actually self-host selfh.st/icons is a collection of logos and icons for self-hosted, and non-self-hosted, software. The name of the project describes the whole proposition: it is a directory rather than a library, a design system or a component package. The audience is people who build interfaces around a stack of open source services. A status page, an installer wizard, a dashboard listing your containers, a documentation site that explains what each piece does: all of them need a picture of the tool, and all of them run into the same problem, that the vendor logo is scattered across the vendor's own site, in a random format, at a random size. This repository solves that by collecting them in one place with consistent output formats. The collection is available for browsing through the directory at selfh.st/icons, and it is also served to users directly from the repository through the jsDelivr content delivery network. That second part is what makes it usable as a dependency rather than a download. Anyone can point a tag at a file path and get a cached, versioned asset without hosting anything. The homepage of the project is the same directory, selfh.st/icons, so the browse view and the raw files are the same collection seen two ways. ## The repository layout is the delivery format The top level entries of the repository are the interesting part, because they describe exactly how the collection is published. There is a directory per output format: avif, ico, png, svg and webp. Alongside them sit build, index.json, index-consolidated.json and tags.json, plus a CHANGELOG.md and the LICENSE file. Because the format directories sit at the root of a public repository, a consumer can address a file directly by path, and jsDelivr can serve it with caching and versioning, with the main branch referenced by name. The build directory holds generated output rather than sources, and the readme carries a badge that reads a version string from a VERSION file inside that directory over the jsDelivr CDN, which is how the release label on the page is produced. The presence of a VERSION file and a CHANGELOG.md also tells you the project has a notion of releases even though the repository has no GitHub releases published through the GitHub interface. The primary language of the repository is Go, which is consistent with a build pipeline that converts source assets into the five output formats. The readme does not describe the build process itself, so if you want to reproduce the collection locally you would be reading the code rather than following a documented command. ## SVG where it exists, raster for everything else The format policy is stated in one line and made precise in a table. When available, SVG icons are the starting point for all icon formats, and otherwise PNG is used. The availability column is the part to plan around. SVG is available for most icons, while PNG, WebP, AVIF and ICO are available for all of them. That means every icon in the collection can be fetched in a modern raster format with broad browser support, and the vector version exists for the majority, which is the set you want for anything that scales, themes with a colour scheme, or animates on hover. ICO carries an extra detail. The footnote in the readme says it includes the sizes 16x16, 32x32, 48x48, 64x64 and 128x128, which makes the ICO file directly usable as a favicon without further resizing. The AVIF directory is the one worth a second thought for anyone checking compatibility. It is the smallest of the raster options in most cases, but it is also the newest of the formats listed, so if your audience includes older browsers or an environment you do not control, the PNG path is the safe one and it is always present. Nothing in the repository tells you which browsers are targeted, so treat the format table as the compatibility contract. ## Standard, dark and light are the only free colour variants By default the directory provides SVG icons, when available, in standard, dark and light colours. That is the core constraint of the free offering, and it is stated as a fact rather than a limitation. Three variants cover the common cases: the standard colour for a light background, and the two inversions for dark mode. What you do not get is a tint that matches your own brand, because the icons carry fixed colour values baked into the SVG. There are two documented ways around that. Users who want to display the icons using colours of their choice can become a paid member of selfh.st, or they can deploy the collection themselves, and both routes are linked from the readme, the first to the perks page and the second to the repository wiki. That second route is the more interesting one technically, because it means the icons are not merely a service you consume. The wiki explains how to host the collection, which means the source assets and the build pipeline exist to be run outside the organisation's own deployment. What the readme does not say is how much work that is, so a team considering self-hosting should read the wiki pages before assuming it is a copy of a folder. ## Pointing a page at an icon There is no install step for a directory of files, so the tutorial is short. You reference an icon by URL, either through the jsDelivr package for the repository or through the self-hosted path if you run your own copy. The jsDelivr package page for the repository is where the file listing lives, and the CDN resolves paths under the repository and branch. ```bash https://www.jsdelivr.com/package/gh/selfhst/icons ``` The same host serves the version file used by the release badge, which shows how a pinned release can be addressed, since that badge reads a VERSION file inside the build directory of the main branch over the CDN. From there, an icon is a path inside one of the format directories, so a request for the svg or png directory gives you the vector or raster version of the same asset. The index files are the machine readable entry points: index.json describes the collection, index-consolidated.json is the merged view, and tags.json groups entries by tag, which is useful if your interface wants to filter a directory by category rather than render a flat list. The browsing view at selfh.st/icons is built from exactly this data, so if you want to see the names and tags before writing any code, that directory page is the fastest route. ## Requests go to discussions, contributions do not come from outsiders The contribution model is unusual enough to read twice. Requests for new or updated icons can be made through the repository's discussions. And then the readme says that to ensure quality and consistency, contributions and pull requests will not be accepted from non-organizational members. So the repository is open for reading and for requests, and closed to direct contributions from outside the organisation. There is no fork and merge path for adding an icon or correcting one. If a logo is missing, you ask, and the maintainers do the work. The reason given is quality and consistency, and the mechanism behind it is the pipeline. Because the collection is generated into five formats from a small number of source files, and because the SVG-first policy means a source asset has to exist before the raster formats can be produced, accepting an arbitrary SVG from a stranger would mean accepting an inconsistent source into a generated corpus. The rule is a consequence of the build design rather than a policy about trust in strangers. For an adopting team this has a practical effect. If your product needs an icon that is not in the collection, you are dependent on someone else's release cycle, and the path to getting it added runs through a discussion rather than a pull request. The CHANGELOG.md file is the place to watch for when it lands. ## A current repository with an unusual licensing and versioning setup The licence is CC-BY-4.0, a Creative Commons attribution licence rather than a software licence, which fits a collection of logos and is worth thinking about carefully. Attribution is required, and the logos themselves are the property of the companies they represent. Using a vendor's logo to identify that vendor is a different act from using a font or a code library, and your legal team will have views about whether the attribution obligation in CC-BY-4.0 is enough for your own use. That is not legal advice, and it is not the only open question. The readme says the collection covers self-hosted and non-self-hosted software, so it includes products whose brand guidelines govern how their logo may be used, and the repository does not restate those guidelines. On maintenance, the repository is not archived and the last push was on 2026-10-14, so the collection is being worked on. There are no GitHub releases, which means version pinning has to come from the VERSION file and the CHANGELOG.md rather than from a tag list, and the jsDelivr release badge is built by reading that file over the CDN. The practical approach for a consumer is to pin a specific commit or version in your own build rather than tracking the main branch, because the main branch is where new icons and re-rendered assets land. Self hosting gives you the same pinning freedom, which is one more reason the wiki route appeals to teams that care about reproducible builds. ## Conclusion selfhst/icons is a good fit when you are building a dashboard or a catalogue of tools and need a consistent icon for each one, and you can live with the standard, light and dark colour variants. It is the wrong choice when the icon has to match a custom brand palette, because custom colours require either a paid selfh.st membership or deploying the collection yourself, and the readme states that pull requests from outside the organisation are not accepted. Before committing, check the index.json file for the exact icon paths you need and confirm the attribution requirements of CC-BY-4.0 for how you publish the icons. ## FAQ ### How do I get an icon from selfhst/icons into my project? The collection is served directly from the repository through the jsDelivr content delivery network, so you reference a file by path under one of the format directories such as svg or png. You can also browse everything at selfh.st/icons or self-host the collection as described in the repository wiki. ### Which icon formats does selfhst/icons provide? SVG is available for most icons, while PNG, WebP, AVIF and ICO are available for all of them. When an SVG source exists it is used as the starting point for the other formats, otherwise PNG is the source. The ICO files include the sizes 16x16, 32x32, 48x48, 64x64 and 128x128. ### Can I use custom colours for the icons? Not in the hosted version, which provides standard, dark and light colour variants by default. Colours of your own require either a paid selfh.st membership or deploying the collection yourself, both of which are linked from the readme. ### How do I request a missing icon or contribute one? Requests for new or updated icons can be made through the repository's discussions. The readme states that contributions and pull requests from non-organizational members are not accepted, so an icon has to be added by the maintainers rather than by you. ### What licence applies to the selfhst/icons collection? The collection is released under CC-BY-4.0, which is a Creative Commons attribution licence rather than a software licence. The readme does not restate the brand guidelines of the individual products whose logos appear in the collection. ### How do I find the list of icons and their tags? The repository root holds index.json for the collection, index-consolidated.json as the merged view, and tags.json for grouping entries by tag. The published directory at selfh.st/icons is built from that same data. ## Sources - [Issues](https://github.com/selfhst/icons/issues) - [License: CC-BY-4.0](https://github.com/selfhst/icons/blob/main/LICENSE) - [Project website](https://selfh.st/icons) - [README](https://github.com/selfhst/icons/blob/main/README.md) - [selfhst/icons on GitHub](https://github.com/selfhst/icons) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/selfhst-icons