The estate model

The hierarchy

A project contains a tree of named containers, with racks wherever you need them. Choose common types such as Site, Building, Room, Cage and Row, or enter your own. Different branches can use different levels:

• Colocation — Site → Hall → Cage → Rack.
• Enterprise — Campus → Building → Floor → Room → Rack.
• Branch office — Office → Rack.
• Data centre — Data centre → Hall → Row → Rack.

These are starting templates, available in an empty estate. Skip any intermediate level, put a rack directly inside a container or at the estate root, and rearrange the structure as your design grows. Racks keep their U-by-U device elevations, dimensions, power and cabling. The tree and breadcrumbs follow every level you create.

Add and reorganise spaces

Choose Add space, enter a Space name, choose or type a Space type, and select its Parent space. Custom types are saved for reuse in the project. Choose Estate root for a top-level space.

Select an existing container to edit its name, type or parent in the inspector. Moving it carries its nested spaces and racks with it. The parent picker excludes the space itself and its descendants to prevent circular nesting. To move a rack independently, use its Rack space picker.

Types and physical layout

A type describes the space in your terminology. The separate Physical layout setting controls its physical behavior:

• Group contents — organise spaces and racks without defining a floor or row.
• Floor plan — keep geometry for rack positions, aisle spacing and cable measurements.
• Rack row — arrange racks in order with shared airflow settings.

Creation suggests a layout for common types; you can choose another. Renaming a space or changing its type leaves the physical layout unchanged. Switching an existing floor or row to another layout asks you to confirm because it changes the physical settings that apply.

Existing projects

Existing Location → Data centre → Row trees migrate automatically when opened, preserving their IDs, contents, floor geometry and rack order. You can then add cages, skip levels or rename the types to suit your customer. Use current Railyard clients and export tools when working with these projects; older integrations need to understand generic containers before editing the new hierarchy.

The URL is the source of truth

In server mode, the open project and selected container or rack live in the URL. Every screen is deep-linkable: paste a link to a rack into chat and it opens on that exact rack. Reloading the page, or using the browser's Back and Forward buttons, moves you around the estate exactly as you would expect — because navigation is the URL changing.

Projects, spaces and racks use readable slugs in their complete estate tree, for example:

• /acme/london-dc — the London project, company overview.
• /acme/london-dc/london/dc1/core — focused on the Core row inside DC1.
• /acme/london-dc/london/dc1/core/dc1-f01 — focused on rack DC1-F01.

Names, slugs and renaming

QR field labels remain stable when a container or rack is renamed or moved because their opaque codes resolve the current friendly path. Repeated sibling names receive readable numeric suffixes. Breadcrumbs and URLs show the current names and ancestry, while older marker-based links remain valid and are replaced with the current canonical path after opening.

Slugs spell accented letters without the accent, so “Müller Hall” becomes muller-hall. A project or organisation name the URL can’t spell, such as one in Cyrillic or Chinese, gets a short code made from the name instead (project-3f9a1c2b7d), so two different names never share a URL.

Consistent naming

Naming rules live under project settings. Add an opt-in rule for each space type you want Railyard to generate, such as Cage or Hall; types without a rule keep their current names. Templates can use the project, resolved parent, space type and a sibling counter, so different customer hierarchies do not need the same fixed levels.

Rack templates use the same generic context alongside the existing data-centre and row tokens. Before any names change, Railyard shows the exact affected spaces and racks. Empty results and duplicate sibling names block the whole operation, while a successful rename is one undoable step. See racks & rack types for where the naming scheme lives.