Devices & the library

Device types vs devices

A device type is a hardware model — a specific switch, server or PDU, with its U-height, ports, power draw and weight. A device is one of those types placed into a rack. Because the type carries the detail, a placed device already knows its ports (which drive cabling) and its power and weight (which feed the rack budgets and design review).

When that planned device is built, open its details and enter its Serial number. The serial belongs to that physical device, so duplicated devices and pod patterns start without one. Railyard stores up to 50 characters and includes the value in NetBox device sync and CSV export. Clearing it in Railyard clears the serial on the next NetBox plugin sync.

Automatic device names

Under Project settings → Naming → Automatic device names, turn on automatic naming and build a template from a data centre, any named space type, rack, device role, device type, U position, face or mounting side. For example,{dc.code}-{space.Hall.code}-{role.code}-{u:02} uses short names for the data centre and Hall, plus a role short code such as Leaf switch → LEAF. The token picker also offers {location},{rack}, {deviceType}, {face}, and{seq:02} for a stable number. A space type with spaces can use a quoted token such as{space."Data hall"}.

Device names use letters in any script, numbers, spaces, dots, hyphens and underscores. Any other character a name part brings in becomes a hyphen, so the role ATS / STS gives ATS - STS and a data centre called King’s Cross gives King-s Cross. New {seq} numbers go out in rack order, from the lowest U up with zero-U devices last, so a duplicated rack numbers its devices the way the original was numbered.

Every role already has a short code, so {role.code} works without set-up: built-in roles use codes such as Server → SRV, Top-of-rack switch → TOR and PDU → PDU, and your own roles use their initials (Optical mux → OM). The table lists the roles your devices use; Show all roles lists the rest of the library. Type over a code to change it for this project, give a role its own template, or choose Resetto go back to the default. Codes you have already saved keep working, so existing names don’t change. Add custom roles under Library → Device roles.

Preview the exact label changes before applying a rule. New devices use it automatically while the project switch is on; existing labels remain manual until you choose to convert them. Editing a device label makes it manual, and Use automatic name restores the rule. A rule change updates only automatic names. When a device can’t be named yet, the preview says why and how to fix it: for example, a device with no role leaves{role.code} empty, and a missing short name can be entered in place. Nothing is renamed until every listed item is fixed, and a collision must be resolved by changing the template or device data.

{role} writes the role as the device inspector shows it, so a device saved by an older version with the role “power” is named with PDU, like any other PDU. When an update to Railyard changes what a rule gives, existing automatic names are not rewritten behind your back: Review lists each one as out of date with the name its rule now gives, and Apply device names previews and makes the renames. Editing something a name is built from, such as renaming its rack, updates that name straight away.

The built-in library

Search Device type by manufacturer or model to find hardware from the built-in device catalogue, the types this project uses and your organisation's custom types. Results show their source so different definitions remain distinguishable. Choose a result to use it on the device in one step — there is no separate import to do first. With an empty search, your recent choices come first, then the types used in this project, then your organisation's custom types.

Use the arrow keys and Enter to choose a result, or select it directly. Typing a query does not change the device; Escape cancels it. Recent choices are personal to you and your organisation, and cancelled searches are not added to them.

Power inlets use the type's declared power ports, or numbered PS / PSU module bays where available. Bay-derived inlets keep their original names but leave the connector unspecified; they are planning endpoints, not confirmation that a particular PSU is installed. You can also add a custom inlet in the Power workspace.

The project's copies

The project keeps its own copy of every type its devices use, so a design and its exports stay the same when the library changes. You never manage these copies: one is taken when a type is first used and removed when no device uses it any more. Project settings → Device types lists them as Used in this project, with where each came from.

Library copies are read-only. Choose Update… to compare a copy with the latest catalogue or organisation version — changes to height, ports, power inlets and outlets are listed before you apply them, and an update that would strand cables or power connections is refused. Choose Customise to turn a copy into a custom type you can edit for this project.

Library updates never replace a project's copies on their own or overwrite custom inlet definitions. Module records are kept separate from rack-device choices, and source information does not mean every hardware capability is modelled or that a particular module is fitted. Only supported device definitions can be selected; unsupported results explain why they cannot be used.

Placing devices

With a rack open in Physical mode, drop a device type onto a free span of the elevation. It snaps to the U grid and occupies its natural height. Select it to edit its name, role, face and position in the inspector, or nudge and resize it from the keyboard. Non-rackable gear — a floor-standing unit, a 0U side PDU — is modelled too, so nothing is left out of the design.

To place a run of the same device, choose Fill range… on an empty unit. Each new device is named as a single added device would be, so a role rule such as {rack}-{role.code}-{seq:02} numbers the whole run. See several devices at once.

Custom device types

When a model isn't in the catalogue, choose Create custom type… to define your own project type with its manufacturer, model, height, full-depth setting and optional named power inlets. Add device ports in Cabling, and edit other template details under Project settings → Device types. The type can then be reused across the project, and it stays in the project until you delete it, even when no device uses it. Choose Use unmodelled device explicitly if you only need a descriptive type label; that does not supply catalogue ports, power inlets or hardware defaults. An unmatched search is never silently treated as a modelled device.

Hardware details

Each device type can also record what the vendor states about the hardware, under Project settings → Device types (choose a type's details):

• Power — the typical draw the rack power budget counts, the vendor's maximum draw and, for a switch, its PoE budget (the total PoE power its ports can give; shown with the type, and not checked yet, since Railyard doesn't model PoE-powered devices).
• PSUs — how many are fitted, how many carry the maximum load (1 of 2 is 1+1), and one PSU's rating.
• Dimensions — weight, and the chassis width, depth and height in millimetres, without ears or handles.
• Mounting — 2-post or 4-post, and the range of front-to-rear post distances the rail kit supports.
• PDU input and banks — a PDU's input voltage, current, phases and plug, and its outlet banks with their breakers.
• Breakouts — the breakout modes the vendor lists for each port, such as 4×25G and 2×50G on a QSFP28 port, shown by runs of ports. They come from the catalogue; none listed means unknown, not that the port can't break out.

Leave a value blank when it is unknown; 0 is a stated value. Airflow is one of NetBox's values: front to rear, rear to front, left to right, right to left, side to rear, rear to side, bottom to top, top to bottom, passive or mixed. Older spellings such as “Front to rear” are tidied when a project opens, a copy of a library type takes “back to front” and similar older words as their NetBox value, and other older text is kept until you choose a value. The design review checks the depth, the mounting posts and the rail range against each rack (see Physical in the design review); the maximum draw, PSUs, width, height and PDU input are recorded and kept with the type for now. NetBox exports write each type's part number, airflow and weight, and Nautobot exports its part number.

For a type taken from the catalogue, the details show where each value came from: the page it was checked against, whether it is the manufacturer's figure, a measurement or an estimate, how confident the catalogue is, and when it was checked. Values found with AI assistance and estimates are marked, so you can check them before relying on them. Values without a source come from the NetBox device-type library. Update… shows the source of each value that changes. The sources stay in the catalogue and are not saved in your project.

Organisation custom types

Types your organisation created or corrected live under Organisation settings → Custom device types, and every project in the organisation can search them. Keep only what differs from the catalogue there, so a team standardises on the same hardware definitions rather than re-drawing the same custom switch in every estate. Copy a project's custom type to the organisation with its → action. After you change an organisation type, projects that use it can update their copies with Update….