# netbox-community/devicetype-library for NetBox Device Imports

> netbox-community/devicetype-library is a community collection of YAML device, module, and rack type definitions intended for NetBox. It is useful for reducing repetitive manual entry, but its CC0-1.0 data repository does not document a complete import workflow.

**netbox-community/devicetype-library** — A collection of community-sourced DeviceType definitions for import to NetBox

- Repository: https://github.com/netbox-community/devicetype-library
- Stars: 1,647 · Forks: 1,441
- Language: Python
- License: CC0-1.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/netbox-community-devicetype-library

## Why the devicetype-library Exists

netbox-community/devicetype-library addresses the cost of entering the same physical equipment definitions into NetBox repeatedly. A catalog administrator might otherwise need to create manufacturers, models, slugs, dimensions, components, and related attributes by hand for each server, switch, router, storage device, or other unit of hardware. The repository replaces that isolated workflow with YAML files arranged by manufacturer, allowing existing definitions to be loaded into NetBox.

The intended users are NetBox operators and contributors who manage infrastructure inventories. Contributors add or correct device definitions, while operators can select records that match the hardware in their environment. The scope extends beyond bare device models. Based on the repository layout, the project also contains `module-types/` and `rack-types/`, although the README explains device type and module type fields in greater detail than rack definitions.

This is a data library, not a NetBox plugin or inventory application. Its value lies in reusable metadata. It does not discover devices automatically, scan a network, create installations, or synchronize NetBox records with an external asset-management system. The README also points to a separate import project for duplicate checking and selective vendor imports. That division matters: this repository supplies definitions, while import behavior belongs to tooling maintained elsewhere.

## YAML Device Definitions and Their Required Fields

Each physical device definition is a YAML file representing one make and model. The core record identifies `manufacturer`, `model`, and `slug`. The model must be unique within its manufacturer, and the slug must also be unique there. Slugs are expected to follow the pattern `^[-a-z0-9_]+$` and should include the manufacturer name with a dash. That naming rule gives NetBox a URL-friendly identifier, but it also makes contributor review sensitive to inconsistent normalization.

Physical rack data is represented by `u_height`, which must be zero or a multiple of `0.5`, and by `is_full_depth`, which defaults to `true`. The special child-device constraint matters during review: the README states that `u_height` must be `0` for child devices. A definition can also declare airflow, weight, part number, comments, power status, parent or child role, and image flags. Weight values must have two decimal places, while `weight_unit` must be `kg`, `g`, `lb`, or `oz`.

The README’s Dell example is a valid minimal illustration of the expected record shape:

```yaml
manufacturer: Dell
model: PowerEdge R670
slug: dell-poweredge-r670
u_height: 1
is_full_depth: true
```

For new devices, contributors are asked to add `airflow`, `weight`, and `weight_unit` where possible. Those values are useful only when sourced correctly. A guessed rack depth, airflow direction, or weight can make an imported definition precise in syntax but wrong as inventory data.

## Components, Images, and Metadata Validation

Device definitions are broader than a manufacturer and model name. The README refers to schema definitions and component definitions for additional attributes, while the repository contains dedicated `schema/` and `tests/` directories. This indicates that validation is part of the contribution model rather than being limited to visual inspection. The pinned development dependencies include `jsonschema`, `PyYAML`, `yamllint`, `pytest`, and `pre-commit`, each at an exact version in `requirements.txt`.

Optional image flags point to files under `elevation-images/`. A `front_image: true` or `rear_image: true` value implies that the repository should contain a corresponding asset, and the README states that the folder name and file name must follow the slug-based naming rule. Such links are concrete cross-file references. A definition can therefore be structurally valid YAML while still failing repository-level expectations if its declared image is absent or incorrectly named.

Module definitions follow a related but different structure. A module requires `manufacturer` and `model`. It can optionally select a NetBox module `profile`, with documented profiles such as `CPU`, `Fan`, `GPU`, `Hard disk`, `Memory`, `Power supply`, `Expansion card`, and `Transceiver`. Profile-specific data is nested under `attribute_data`. Some profile attributes are required only in context. For example, GPU memory, hard-disk `disk_type`, memory `class` and `size`, and several power-supply attributes have documented constraints.

That context-dependent validation is more error-prone than a flat required-field list. A CPU profile does not require the fields belonging to a GPU profile, while a power supply has its own mandatory set. Contributors need to inspect the relevant schema rather than copying the most visually similar module.

## Preparing and Checking the devicetype-library Repository

The repository does not publish an installation procedure for consumers because it is a collection of definitions rather than an installable Python package. The README says that definitions can be loaded into NetBox and points contributors to `CONTRIBUTING.md`. It does not provide a NetBox import command, supported NetBox release, or a complete first-import example. Readers should not infer that cloning the repository and running Python automatically populates NetBox.

For contributors, the repository layout shows local tooling for inspecting and validating YAML definitions. The exact Python packages and versions are pinned in `requirements.txt`, including:

```text
jsonschema==4.26.0
jsondiff==2.2.1
pre-commit==4.6.2
pytest==9.1.1
PyYAML==6.0.3
yamllint==1.38.0
gitpython==3.1.62
psutil==7.2.2
```

The repository does not show shell commands for creating a virtual environment, installing these requirements, invoking `pytest`, or running pre-commit hooks. It would be unsafe to add undocumented flags or filenames. The concrete first supported step for contributors is to read `CONTRIBUTING.md`, obtain the repository, and follow that guide for contribution and validation commands.

For operators, the README identifies two paths: use the separate NetBox Community import script for automation, or load chosen definitions into NetBox instead of creating each type manually. The actual import syntax remains outside the commands documented by this repository.

## Choosing Between YAML Import Automation and Manual Entry

The clearest alternative named by the README is `netbox-community/Device-Type-Library-Import`. Its approach differs from manual NetBox entry. The README says that script checks for duplicates and allows selective vendor imports. That makes it the documented automation path when an operator wants control over which manufacturers enter an existing NetBox installation.

Manual entry is the other real approach. It may suit a small catalog where every manufacturer, model, component, and physical attribute is already known and reviewed. The disadvantage is repetition: the library exists specifically because defining device types manually can be avoided when suitable records are available. Automation does not remove data review. Duplicate detection can prevent repeated imports, but it cannot establish that a community definition matches the exact hardware variant owned by an organization.

The library should therefore be treated as a catalog input rather than an authority. An operator can search the manufacturer directories for a known model, review its YAML and any referenced images, and then choose between manual creation and the separate import project. The README does not document search commands, NetBox API calls, bulk-import limits, or rollback behavior, so this review cannot describe those steps as supported features.

## CC0-1.0 Data and devicetype-library Maintenance

The repository uses CC0-1.0. That license places the contributed definition data under a public-domain dedication rather than presenting it as a conventional executable package with a separate service license. The repository metadata does not indicate that the license applies differently to every external manufacturer image or to the separate import project. Teams should inspect `LICENSE.txt` and the provenance of referenced assets when those distinctions matter, without treating this article as legal advice.

The repository is not archived, and the last push was on 2026-10-15. That recency indicates recent repository activity, but it does not guarantee that every definition is current or that every contribution has passed an organization’s acceptance process. No GitHub releases are available, so there is no documented release train or versioned package upgrade path. Changes are observed through repository history rather than published releases.

Upgrade planning is consequently tied to data review. The README defines required fields and profiles, but it does not promise schema compatibility with every NetBox version. Operators should verify that a definition’s attributes match their installed NetBox model before importing it. Contributors can inspect `schema/`, tests, and pre-commit configuration to understand validation, but the repository does not state a migration policy.

## Failure Modes in Community Device Catalog Data

The most important limitation is provenance. The project is explicitly community-sourced, so a definition can be syntactically valid and still contain an incorrect model name, component layout, rack height, airflow direction, or image. The README gives formats and constraints, not a manufacturer certification process. It also does not document a formal review history for each record.

Another limitation is workflow incompleteness. This repository does not document rollback, NetBox version compatibility, duplicate behavior during direct loading, or a supported command for selective import. Those omissions matter in an existing production inventory. A failed or unwanted import may require a separate procedure, but the README does not define one, so operators should not assume that repository tooling provides recovery.

Schema complexity creates a further risk. Optional fields have profile-specific rules, image flags refer to repository assets, and child devices require `u_height: 0`. Copying a nearby file without checking those constraints can produce misleading records even when the YAML parses successfully.

For these reasons, the library is a poor choice when an organization requires signed vendor data, guaranteed support for a particular NetBox release, or a complete automated deployment with documented rollback. It is more suitable as a reviewable source for selected equipment records. The README does not state that every listed device is guaranteed accurate, and it provides no claim that NetBox imports are atomic.

## Conclusion

NetBox operators should adopt this library when they need a broad source of community-maintained catalog definitions and are prepared to review data before importing it. Organizations requiring traceable vendor approval, deployment automation, or a guaranteed import command should not treat the repository as a complete provisioning system. Verify first that the selected NetBox version accepts the relevant definitions, because the README documents the data model but does not provide the import workflow or version compatibility matrix.

## FAQ

### What is netbox-community/devicetype-library used for?

It provides community-sourced YAML definitions for populating device types in NetBox instead of creating each manufacturer and model manually. The repository also includes module types, rack types, schemas, images, and validation tooling.

### Does devicetype-library include a command for importing definitions into NetBox?

The README does not include an import command. It points to `netbox-community/Device-Type-Library-Import` for automation that checks duplicates and supports selective vendor imports.

### What license does netbox-community/devicetype-library use?

The repository declares the CC0-1.0 license. The license text is stored in `LICENSE.txt`.

## Sources

- [Issues](https://github.com/netbox-community/devicetype-library/issues)
- [License: CC0-1.0](https://github.com/netbox-community/devicetype-library/blob/master/LICENSE)
- [netbox-community/devicetype-library on GitHub](https://github.com/netbox-community/devicetype-library)
- [README](https://github.com/netbox-community/devicetype-library/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/netbox-community-devicetype-library