Railyard

Export

Turn a sketch into your source of record.

Data, not pictures

Export produces structured, import-ready data — not screenshots. Open Export from the tool rail and choose one output from the list: a format under Import into a tool, or a sheet under For installers. The panel beside the list shows only that output's options, and the one button at the bottom says what you'll get — for example Download NetBox bundle (.zip) — so a sketch becomes the source of record in your DCIM in one click.

For an import format, Railyard checks the design straight away and shows one status: Review findings, any devices whose type it couldn't resolve and the export's own warnings. What's in the bundle lists the files the download contains. Export remembers the last output you chose in this browser and opens on it next time; on a phone the list comes first, and choosing an output opens its details.

A problem only leaves out what it breaks. A device is left out of the NetBox, Nautobot and Design Builder exports when the target could not place it: it sits outside its rack, overlaps another device, has an invalid face, shares its ID with another device, or is named automatically but has no name yet. The NetBox and Nautobot CSV bundles also leave out a device whose name, serial number, role or a tag starts with =, +, - or @, because a spreadsheet would run it as a formula; Design Builder keeps it. A port or power input named that way is left out on its own, with the cables and power feeds on it. A broken cable or port is left out on its own, so the device and its other cables still export, and a stale automatic name exports under the name it last had. Each of these is listed in the export's warnings.

Formats

  • Nautobot — a Nautobot 2.x bulk-import CSV bundle (nautobot-csv). Nautobot can't create cables from a CSV import, so a cabled design's cables come as a JSON list with a small Python script that creates them through Nautobot's REST API. The bundle's 00-IMPORT.md explains how to run it.
  • NetBox — a NetBox 4.x bulk-import CSV bundle (netbox-csv), written for the NetBox version you choose (see NetBox versions below).
  • Nautobot Design Builder — a bundle (designbuilder-yaml, downloaded as a .zip) holding a design.yaml for the Nautobot Design Builder app, a 00-README.md on applying it, and the project as Railyard JSON.
  • Railyard JSON — the canonical project document (json): the whole estate in one file, ideal for backup, diffing or feeding another tool. The exact list of targets your server offers is shown under Import into a tool. Without a connected Railyard server only Railyard JSON is available; the other formats are listed but can't be chosen.

NetBox versions

NetBox 4.5 changed how front ports import: it needs a positions column that NetBox 4.4 and earlier reject. Choose NetBox version in the Export dialog to match the NetBox you're importing into. NetBox 4.5 or later is the default; choose NetBox 4.0 to 4.4 for an older release. Export remembers your choice in this browser, and the bundle's 00-IMPORT.md says which release it was written for. On the command line use --netbox-version 4.4, and on the API netboxVersion=4.4.

Device status

Devices import with the status Active unless you choose otherwise. If the design is not built yet, choose Planned (or Staged) under Device status in the Export dialog so your DCIM does not treat it as live equipment. On the command line use --status Planned, and on the API status=Planned.

Include the store room

The NetBox and Nautobot bundles can carry the store room too. Tick Include store room in the Export dialog (off by default), or use --include-stock on the command line and includeStock=true on the API. Each unit becomes a device with no rack, in its own file (06a-stock-devices.csv for NetBox, 07a-stock-devices.csv for Nautobot): units in store or reserved are Inventory, ordered units Planned. A line of several becomes one device per unit, named from its label (SPARE-1, SPARE-2), else its serial number, else Model (store room 1). A unit reserved for a rack goes to that rack's site or location, the others to the fallback location. The supplier, order reference and expected date travel in the comments. NetBox also gets asset tags (when unique to one unit); Nautobot does not, and the bundle's 00-IMPORT.md says why. Items whose device type is not in the project library are skipped and listed in the warnings. The Design Builder YAML and Railyard JSON ignore the option (the JSON already holds the whole store room), and so do the sync documents.

Unknown device types

A device whose type doesn't match an entry in the project's device catalogue can't be imported as-is, because the target needs a real device type for it. By default the export leaves those devices out and lists each one, with its rack, so you can pick a catalogue type and export again.

For NetBox, Nautobot and Nautobot Design Builder, select Include devices with an unknown device type as generic placeholders to export them anyway. Each one is imported against a generic placeholder device type, so its rack position is kept; replace the placeholder type in your DCIM, or fix it in Railyard and re-export. Railyard JSON keeps every reference as written, so it doesn't offer the option.

Space hierarchy in exports

For NetBox, select Export this space as a site in the space inspector to choose a site boundary. A branch with no explicit site uses its root space; an unmarked root above explicit sites does not become a site of its own. Spaces below a site become nested locations. Because NetBox sites cannot nest, parent relationships above an explicit site remain in the bundle's project.json and are reported in its warnings.

Nautobot receives the full nested location tree and location types. If names repeat or a type appears under different parent types, export may use name aliases or separate type variants to make the import unambiguous. Follow the bundle's import order and review its warnings, especially when importing into an existing hierarchy.

Canonical Railyard JSON keeps the original names, custom types and physical layout settings, including details the target system cannot represent.

For installers

The same list holds the working sheets for the people doing the install. In the local editor they're built in your browser, so they work without a backend. They are deliverables, so a hosted project needs a plan that includes them (see Deliverables and your plan below). The cable schedule, cable labels and power schedule take a Scope — one rack, a space such as a row or a data centre, or the whole estate — which starts with your selection or the level you're viewing and carries over between them and the build pack:

  • Build pack (PDF) — a printable handover document; see Build packs below.
  • Cable schedule — every run, from your structured cabling. A cable is included when either end is in scope.
  • Cable labels — a label sheet for the physical install, one wrap label per cable end.
  • Optics and DACs — the transceivers, DACs and AOCs to order, one row per rack, item, form factor, speed and medium (multimode, single-mode, fibre, copper or unknown). Each cable end on a transceiver cage needs a module at the link's speed (a 10G link in an SFP28 port takes an SFP+), unless the cable is a DAC or AOC, which is counted once. A broken-out port's lanes share one item: a breakout DAC such as QSFP28 to 4×SFP28, or the port's own transceiver at its whole speed. A blank speed is unknown, and cable ends whose port type is unknown, or whose link has a port compatibility warning, are counted as unknown rather than guessed. The build pack prints the same list on each rack page. It comes with the cable schedule.
  • Power schedule — one row per device inlet: the PDU and outlet feeding it, or unfed, with its status and device demand, the PDU's input plug (so facilities provision the right receptacle) and the cord the connection needs, or unknown when a connector isn't recorded. It matches the Connections table in Power.
  • Power cords — the cords to order, one row per rack and cord type (PDU end → device end, such as C14→C13), with the connections whose cord is unknown or for which nothing fits. The build pack prints the same list on each rack page. It comes with the power schedule.
  • Power report — the per-rack load and capacity from power & thermal, for every rack in the estate.
  • Rack QR labels — Prepare QR labels opens the label set-up for the racks you choose. Each code opens its rack in Railyard, so labels need a saved, hosted project, an editor, and the main design rather than a branch or commit; Export says which is missing.

Build packs

A build pack is one printable handover document for the people installing a rack, a row, a data centre, a site or the whole estate. Choose Build pack (PDF) in Export, pick its scope (it starts with your selection or the level you're viewing) and select Open build pack, or pick Build pack… from a rack or space's menu in the estate tree or from the command palette. The pack opens a print view with a cover naming the project, scope, design revision and when it was generated, then the outstanding design review findings, front and rear elevations for each rack with its 0U side equipment and device list, the cable schedule, the power connections and every topology that includes a device in scope. A topology that reaches beyond the scope is drawn whole, and says so.

Select Print or save as PDF and choose Save as PDF as the printer to keep a copy. Pages are numbered and print in the light palette whatever theme you use. The pack is built from the same data as the workspace, so its counts match Review, Cabling and Power. On a branch or a saved commit it shows the version you're viewing.

Installer checklist. Tick Print as an installer checklist to get a pack the engineer on site can fill in as they go. Each device gets a box to write its serial in, and tick boxes for Racked (Mounted for 0U equipment) and Labelled. Where a serial is already recorded, it is printed with a box to tick once it matches the device. Each cable gets Run and Labelled boxes and each power connection a Connected box. Every rack, the cable schedule and the power connections end with a sign-off for the engineer's name, the date and a signature. The rows are taller to leave room for handwriting, so the checklist runs to more pages than the plain pack.

Deliverables and your plan

The outputs you hand to someone else are deliverables: the build pack PDF, cable schedule, cable and rack labels, power schedule, power report, NetBox bulk-import bundle and Nautobot bulk-import bundle. Nautobot Design Builder counts as part of the Nautobot bundle, and rack QR labels count as labels. On a hosted service a deliverable needs a Project Pass for the estate or a Pro, Team or Partner plan; Community can open a one-rack build pack preview with a watermark. A deliverable is generated from the saved design, and the estate's rack count must be within its plan's limit.

Keeping NetBox or Nautobot in step. The NetBox plugin and the railyard-sync CLI sync a saved design into your DCIM. They read the netbox-sync or nautobot-sync deliverable from the API: the same objects the bundle imports, as JSON, each with the Railyard id it came from, so a renamed rack or device updates the existing object rather than creating another. They are the NetBox and Nautobot deliverables, paid exactly like the bundles.

Railyard JSON is never a deliverable. Downloading, importing and exporting the project file is free on every plan, including when a paid plan has ended. The local editor and a server running without billing include every output. See Plans & billing.

Command line & API

The same export runs headless — the Railyard core is a Go binary you can drive from the command line (for example railyard export project.json --format nautobot-csv -o out/) or over the REST API, so exports fit into a pipeline. A bundle (every format but Railyard JSON) is written to the directory you name with -o; Railyard JSON goes to standard output unless you name a file. The command line runs on your own machine and is not limited by plan. On a hosted service with billing on, the anonymous /api/export endpoint serves only Railyard JSON; deliverables come from the project's own deliverables endpoint, which checks the plan. See API & MCP.