# homelab-svg-assets: full-colour SVG icons for the software you actually run at home > homelab-svg-assets is a collection of over 600 full-colour SVG icons of homelab software, products, and brands, normalised to a common size and published to Packagist, NPM, jsDelivr, a Diagrams.net library, and as a Hugo module. The project ships a DISCLAIMER.md that every user is told to read before using it. **loganmarchione/homelab-svg-assets** — Full-color SVG icons of homelab-related software, products, and brands - Repository: https://github.com/loganmarchione/homelab-svg-assets - Stars: 1,258 · Forks: 80 - Language: Python - License: MIT - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/loganmarchione-homelab-svg-assets ## The collection exists because generic icons were not useful homelab-svg-assets is a collection of over 600 full-colour SVG icons of homelab-related software, products, and brands in a normalised size. The subject is the distinguishing feature, and it is worth being clear about why it matters. A homelab is a personal infrastructure setup where the point of the thing is that you chose the software. You run a specific container image, a specific database, a specific reverse proxy, and a specific hypervisor. A diagram of that setup with generic server or database icons tells the reader nothing, because every one of those components is distinguishable by its logo. The whole value of the collection is that the icon is the actual brand, so the diagram is legible without a legend. Full colour is part of that argument. Monochrome icon sets force you to pick a glyph, and a brand rendered in one flat colour often becomes unrecognisable, since many logos rely on a specific colour arrangement to be legible. Rendering the real logo in full colour keeps it recognisable at small sizes, which is where these icons are used. Normalised size is the other half. A collection assembled from many sources, rendered by different people, at different scales, has wildly inconsistent geometry unless someone imposes a standard. Normalising means every icon sits on the same canvas with the same padding, so a grid of them lines up. That is a painstaking, unglamorous piece of work, and it is the difference between a collection you can drop into a diagram and one you have to adjust file by file. The repository ships `ICONS.md` as a preview of all icons, and the `assets/` directory holds the SVG files themselves, with a badge showing the directory file count for svg files as the total icon count. ## Five distribution channels, because the users are five kinds of people The distribution story is the most interesting engineering decision in the project, and it is a decision about who the user is. The first channel is the raw files in the `assets/` directory, which is what you use if you are just pulling an icon into a design tool. The second is Diagrams.net, the diagram editor. There, you go to File, then Open Library from, then URL, and paste in: ``` https://raw.githubusercontent.com/loganmarchione/homelab-svg-assets/main/homelab-svg-assets.xml ``` The `homelab-svg-assets.xml` file at the repository root is the library definition that makes that work. There is also a link that starts a brand new project with the library built in, and if you self-host Diagrams.net, which is available as a Docker container, you can replace the domain with your own. The third is a CDN, jsDelivr, with the icon name substituted and `latest` replaceable with a specific version: ```html ``` The fourth is PHP, through Packagist. You run `composer require loganmarchione/homelab-svg-assets` or add the package to your `composer.json`, and the icons are available at `./vendor/loganmarchione/homelab-svg-assets/assets/linux.svg`. The fifth is NPM, with `npm install @loganmarchione/homelab-svg-assets` or the package added to `package.json`, and the icons at `./node_modules/@loganmarchione/homelab-svg-assets/assets/linux.svg`. The sixth, and the most involved, is Hugo. The repository has a `go.mod` file, so the pack can be used as a Hugo module, and you need Hugo 0.56.0 or newer. In your site directory you initialise the site as a module with `hugo mod init foo`, then in your `config.yaml` you add the section below, adjusting for the json or toml configuration files: ```yaml module: imports: - path: github.com/loganmarchione/homelab-svg-assets mounts: - source: assets target: assets/svg/homelab-svg-assets ``` Then `hugo mod get -u` downloads the module, and you create a shortcode at `layouts/shortcodes/homelab.html` with the following code, where the class `blah` is where you can apply custom CSS: ``` {{/*Get the parameters */}} {{ $path := (.Get "src") }} {{/* Concat to create the correct path */}} {{- $icon := resources.Get (print "svg/homelab-svg-assets/" $path ".svg" ) -}} {{- $icon.Content | safeHTML -}} ``` Finally, in your markdown files you reference the icon with `{{< homelab src="linux" >}}`. That shortcode is the only genuinely new code in the project, and it exists because Hugo's `resources.Get` needs a path inside the module mount rather than a path to a file on disk. The `safeHTML` call is there because the icon content is raw SVG being injected into a template. ## The tooling is a Python pipeline that lints and publishes The primary language is recorded as Python, and the repository layout shows where the Python lives. There is a `scripts/` directory, a `makefile` at the root, an `icons.json` at the root which is presumably the index of what exists, an `svgo.config.js` for the SVG optimiser, and two Python dependency files, `requirements.txt` and `requirements-dev.txt`. The runtime requirements file has a single entry, `prettytable==3.18.0`, which is a table formatting library, and the dev requirements add the rest. The choice of prettytable is a hint about what the scripts do. A tool that prints a table is a tool that reports on the collection, and a lint step for an icon pack is plausibly a script that checks every file in `assets/` against the expected geometry, the viewBox, the file naming, and the list in `icons.json`, then prints a table of what it found. The `svgo.config.js` is the SVG optimiser configuration, which is the step that makes the files small. SVGO rewrites paths, removes metadata, and collapses attributes, and running it across a collection of six hundred hand-adjusted files is what makes the CDN delivery practical. The GitHub workflows are visible in the badges at the top of the project summary. There is a `lint.yml` workflow, which is the check above, and a `publish.yml` workflow on the main branch, which is the release. The publish step is what pushes to Packagist and NPM and generates the GitHub tag, and it is why there are three separate version badges, for the GitHub tag, the Packagist version, and the NPM version, since all three have to move together. The `ruff.toml` is the configuration for Ruff, the Python linter and formatter, and the `.bandit` entry is the configuration for Bandit, the Python security linter. Both of those being present says the Python in this repository is held to the same standard as application code, which is the right call when the scripts are what generate the published artefacts. ## Every user is pointed at a disclaimer first The legal section of the project is short and points to a single file. The project summary opens the usage section with a warning that all users should read the disclaimer in DISCLAIMER.md before using this project, and the legal section at the end says the same thing, see DISCLAIMER.md. This is the correct handling of a project whose entire content is other people's logos, and the placement of the warning matters. It is not buried at the end of the document. It is the first thing under the usage heading, before any of the install instructions, marked with a warning sign on both sides. The reason a disclaimer is needed at all is fairly obvious once you think about it. A logo is a trademark, and trademarks are not licensed by the fact that the logo was redrawn as an SVG. A set of full-colour brand icons, each one recognisable as a specific company's product, used in a diagram that a company publishes, is exactly the situation trademark holders have opinions about. The MIT licence recorded in the package metadata covers the repository's own work, such as the scripts and the tooling, and it cannot grant rights in someone else's brand. The project also points out, with a paragraph that is worth reading as a piece of professional courtesy, that it would be remiss not to mention other great icon sets. The list names Simple Icons for monochromatic SVG icons of popular brands, Bootstrap Icons for mostly generic icons with some brand ones, Font Awesome as a mix of generic and brand icons, Devicon for programming languages and development tools, Dashboard Icons as a mix of SVG and PNG dashboard icons, Aegis Icons as unofficial 2FA entry icons for the Aegis authenticator, and theSVG. That paragraph is a deliberate signal about positioning. This collection is not the generic icon set, and the alternatives cover the generic case and the monochrome case better. What it offers is the specific case, the full-colour brand logo for self-hosted software, in one normalised set. ## The rest of the tree is a small project with a real toolchain A few remaining details in the repository are worth reading, because they describe the working practices. There is a `WORKFLOW.md` at the root, which is how the project documents the order in which things have to happen. For a repository where a lint step gates a publish step that pushes to three package registries, an explicit workflow document is what stops a contributor from publishing a broken index or a version bump that lands in one registry and not the others. There is a `composer.json` and a `go.mod` alongside the `package.json`, which is unusual and is the direct consequence of the distribution model. The Composer manifest exists so Packagist can install the package, the `go.mod` exists so Hugo can consume the repository as a module, and the `package.json` exists so NPM and jsDelivr can serve it. Three ecosystems, three manifests, one set of SVG files, and Hugo's module system reached through the Go tooling. The `go.mod` is minimal in the extreme. It declares the module path `github.com/loganmarchione/homelab-svg-assets` and `go 1.19`, and nothing else, because the module contains no Go code. It exists purely to give the Hugo module system something to resolve. The `LICENSE` file is MIT, matching the package metadata's MIT licence field and the version 0.5.0 in the NPM package.json. The version number being below 1.0 in a project with over 600 assets is worth reading as a signal: the collection grows, the naming and geometry conventions may change, and consumers should expect to check the changelog rather than assume the icon set is frozen. The `icons.json` file at the root is the machine-readable index, and it is what lets the lint script verify that `assets/` and the index agree. The `ICONS.md` file is the human-readable preview, the counterpart to it. ## Where homelab-svg-assets is the wrong tool The limits are narrow, and they come from the choice of subject and the choice of style. First, this is not a general-purpose icon set. It covers homelab-related software, products, and brands, and it will not have an icon for your payments provider, your insurance company, or the fictional product in your wireframe. If you need an icon for a SaaS dashboard, you want Simple Icons or Font Awesome, and the project says so itself. Second, full colour is a hard constraint. If your interface is monochrome, if it has to print well in one ink, if it follows a design system that mandates single-colour glyphs, then these icons do not fit, and the answer is a monochrome set or recolouring that may not be legally clean. The collection is deliberately the opposite of Simple Icons in this respect, and the two are not substitutes for each other. Third, the trademark position is a real limitation, not a formality. A logo is a trademark, and this collection is six hundred of them. The disclaimer exists because a set of brand logos used in a published diagram is a legitimate question for the brand owners, and the project asks you to read that file. That does not tell you the icons are safe for your use, it tells you the question is yours to answer. A commercial product publishing customer-facing diagrams with these logos is in a different position from a hobbyist drawing their own homelab. Fourth, the icon set is a moving target and the version is 0.5.0. The tags, the Packagist release, and the NPM release have to be kept in step by the publish workflow, and the last push was on 2026-10-15 with no GitHub releases attached. A consumer who pins a version gets a stable set, and a consumer who tracks the latest tag gets new icons and possibly changed geometry, because normalising is an ongoing process rather than a one-off. Fifth, the Diagrams.net integration depends on a raw GitHub URL pointing at the main branch, so the library you get is whatever is on main at that moment, and the same applies to the jsDelivr `latest` tag. For a diagram you intend to keep, that is a supply-chain consideration worth thinking about rather than a technical problem. ## Conclusion homelab-svg-assets fits a person documenting a home lab who wants the real logos of the software they run rather than generic server icons, and who needs the same set to work in a diagram, a wiki, a slide, and a site built with Hugo. It is the wrong choice for a general UI icon set, and it is the wrong choice if you need monochrome glyphs. Check three things before you use it: that you read DISCLAIMER.md, which the project asks every user to do and which is where the trademark position sits, that the icon you need actually exists, since ICONS.md is the preview of all of them, and that the Normalised size works in the place you are dropping it, because the whole point of the collection is that every icon shares one geometry. ## FAQ ### What is homelab-svg-assets and what does it contain? It is a collection of over 600 full-colour SVG icons of homelab-related software, products, and brands in a normalised size, so that every icon shares the same geometry. The SVG files live in the assets directory and ICONS.md is a preview of all of them. ### How do I use the homelab-svg-assets icons in Diagrams.net? In a Diagrams.net project go to File, then Open Library from, then URL, and paste the URL of the `homelab-svg-assets.xml` library file in the repository. There is also a link that opens a new project with the library already built in, and if you self-host Diagrams.net you can replace the domain with your own. ### How do I install homelab-svg-assets with npm, Composer, or Hugo? For NPM run `npm install @loganmarchione/homelab-svg-assets` and the icons land in `node_modules/@loganmarchione/homelab-svg-assets/assets/`. For PHP, `composer require loganmarchione/homelab-svg-assets` puts them under `vendor/`. For Hugo, the repository has a go.mod so it works as a Hugo module, and you add a module import with a mount from assets to assets/svg/homelab-svg-assets, then use a shortcode. ### What licence are the homelab-svg-assets icons under? The project is MIT licensed, and the package metadata records the same. The logo icons are trademarks of their respective owners, and the project asks every user to read DISCLAIMER.md before using it, with a warning at the top of the usage section. ## Sources - [Issues](https://github.com/loganmarchione/homelab-svg-assets/issues) - [License: MIT](https://github.com/loganmarchione/homelab-svg-assets/blob/main/LICENSE) - [loganmarchione/homelab-svg-assets on GitHub](https://github.com/loganmarchione/homelab-svg-assets) - [README](https://github.com/loganmarchione/homelab-svg-assets/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/loganmarchione-homelab-svg-assets