NIMBY Rails: build guide — tracks, stations, lines and signalling that actually run

NIMBY Rails has no campaign, no tech tree and no unlocks. You get the whole Earth at 1 cm resolution, a loan of one billion of fake money, and a set of editing tools. That means every mistake is a building mistake, and the game will not tell you what you did wrong — it will simply run a beautiful, empty timetable while nobody boards.

This guide is the build order for a first working network, plus the hard numbers that decide whether it earns money: what makes passengers spawn, what breaks a junction, what a station can actually hold, and which misunderstandings cost new players their first ten hours.

Written for version 1.19.10 (18 August 2026) — the current release on Windows and Linux.

What version this is for

• Game version: 1.19.10, released 18 August 2026. 1.19 itself landed 9 August 2026; 1.19.10 is the newest patch note on the developer's Steam feed. 1.20 has not shipped.
• 1.19 changed the map, the OS support and the train physics. The map now uses industry-standard formats (OpenMapTiles schema in Maplibre Vector Tile/MLT format inside PMTiles containers) instead of the old proprietary NRMap files; the bundled map is over twice the old size and wants about 55 GB of storage. The game got a native Linux build alongside Windows. The map renderer was rewritten for Web Mercator, which is what enables the new map rotation (horizontal mouse wheel, or shift + vertical wheel; middle-click or the top-bar button cancels it) and custom map sources (raster PNG/JPG/WebP and vector MLT/MVT, styleable from the UI).
• 1.19 rewrote train motion, and that invalidated line timings. Train motion now runs on a fixed 0.01 s physics step, while the rest of the train logic runs on the slower frame step. The developer's own release notes say line timing "has changed again in 1.19", and that imported 1.18-and-earlier saves showed massive scheduling errors — commonly more than 50% invalid runs — because trains brake more slowly under the new, more correct loop. The fix shipped as a global brake factor in the 1.19 Company options; saves from 1.18 and earlier are set to 1.5 automatically. If you load an old network, that is the dial to reach for.
• 1.16 (April 2025) is where collisions became real. Before 1.16, collision handling only covered special cases around track branches. From 1.16 the game has a proper collision system based on train physical size and footprint, so train length and stopping positions now matter in ordinary track layouts. 1.16 also introduced stop selection signals and dynamic schedules (shift holes and train dispatching).
• 1.17/1.18 are the scripting versions. The top-level logic of path signals and balises was reimplemented in NimbyScript in 1.17 (a read-only preview), and 1.18 opened NimbyScript up so Workshop mods can add new mechanics — including custom signal behaviour.

The gameplay loop, in the game's own terms

Build rails. Create lines linking stations. Buy trains to run on those lines. Monitor the demand for your services and the satisfaction of your users. Generate income from fares. Repeat.

The objective and motivation text above is lifted straight from the wiki's Quickstart, because it is the whole game: NIMBY Rails is a sandbox that expects you to supply your own goals. There is no progression prompt, so the "build order" below is not something the game enforces — it is the order that avoids building yourself into a corner.

The build order that works

1. Choose the ground and set the demand factor. The global pax demand factor lives in Options under Company and Accounting. It exists so you can match local public-transport culture: the wiki gives 8–15% as realistic for Europe, and notes the US is much lower. Set this before you judge whether a line is busy.
2. Lay track. Every new track starts in blueprint mode. Blueprinting is free; blueprints cannot be used by lines or trains. Pay the bill with Build now in the blueprint bill dialog.
3. Add stations. A station is a set of platforms whose footprints overlap; a single platform is a valid station. The station's coverage area is its reach, and reach is what generates passengers.
4. Create a line. A line is an ordered list of stops. Give it a name, a code, a base ticket price and a price per km.
5. Buy trains and open the line. Pick a model, set the number of trains, purchase. Then set the line's Service Level to Full — lines start closed.
6. Close the loop. Add a yard (a station with zero coverage used as a depot), give trains nightly orders, and check the routeplanner to see what path passengers are actually choosing.

Track: levels, types and curves

Track is laid with the Tracks menu (default hotkey F2). Track can be placed on the ground (layer 0), on viaducts (+1, +2, +3) or in tunnels (−1, −2, −3), plus special +∞ and −∞ levels.

Tracks on the same level intersect each other. Track level is defined per control point and always changes at the midpoint between two control points, so you can start a section at ground level and switch to a viaduct before placing the second point.

The traps in this menu are specific:

• Ground-level track cannot cross water at all, and cannot cross roads or streams at shallow angles. Viaduct track is explicitly able to cross roads at acute angles. If a route inexplicably refuses to build, this is usually why.
• Curves are speed-limited, and then forbidden. While laying, the game shows the curve radius and an indicative circle. If the curve is tighter than the track type's speed limit allows, the speed limit is reduced (the wiki's own example: a track type rated 160 km/h limited to 70 km/h by the curve). Track types also have a minimum curve radius, and track below it is invalid and cannot be built.
• Hold Ctrl to force the new section straight; hold Shift to keep laying sections.
• Insert converts built track back to blueprint. You are not refunded the original build cost, and you pay for the construction a second time when you build it again. This is a very expensive undo.

Key shortcuts for the track editor:

Stations: the numbers that decide your income

• A platform is a pair of contiguous tracks flagged as a station platform — so it must be free of branches and certain signals.
• A station is one or more platforms whose footprints overlap. A single platform is a valid station. There is no limit on how many platforms you combine, in any orientation or layer. Since 1.15 you can edit the station footprint directly: click inside a footprint to extend the station with a new platform, click outside to start a new station.
• Coverage area is the money dial. It sets the station's reach, which sets the population covered, which sets demand, which sets the spawn rate. A station with a reach of zero has no demand, will never spawn pax and will never be chosen as an origin or destination. Since 1.6, population is the only factor — there is no directional morning-into-town flow to exploit.
• Platform pax capacity is a slider running from 50 to 100,000 passengers. Overflow can be allowed into the station hall with a checkbox.
• Out-of-Station Interchanges (walking transfers) have a maximum radius of 2.3 km, set either by the station's auto walk transfer range or by an explicit walk link. Passengers walk between stations at 1 m/s, so a walking transfer is slow — their timer shows up in the destination station's hall while they do it.
• Stations are depots. A depot needs no special building: make a station, set its coverage area to zero, and (optionally) de-emphasise its label. Zero coverage is what stops passengers spawning there or setting it as a destination.

Lines and timetables

A line is a sequence of stops with fares and a duration. Train orders then tell trains how to run it.

• Every line is a circle. Trains run down the stop list and then wrap back to the start. If you want normal "reverse at the end" behaviour, you must list the stations in one direction and then list them again in reverse order, using the correct platform direction. Trains are allowed to reverse inside stations, which is how the wrap works in practice.
• Fares are two numbers. The base ticket price is paid once when a passenger boards a train on that line; the price per km is paid after leaving the train, on top of the base.
• Default timings live on the line, not the train. Cruise speed defaults to 90% of the reference train's maximum speed (trains will run faster than the set cruise speed to make up delays), plus max acceleration, max braking, a default stop time, and the line duration.
• Duration is a loop by default. The displayed line duration includes the run from the last stop back to the first. The non-loop duration, which excludes that return leg, appears when you hover the duration in the editor. The game estimates duration by running a phantom train, and the wiki warns the estimate is sometimes off.
• For a 24-hour service, the line duration must be a factor of 1440 minutes. Otherwise the remainder becomes a long stop at the first station around the start of the day. The line editor's custom duration feature will search for a duration that divides evenly into 24 hours or 7 days.
• Auto-run is 24/7 only. "Auto run a line" produces the same timetable every day, with no depot at night. Nightly depot visits require Manual Orders; "loop until next order" plus "auto copy manual orders" is the combination that keeps that manageable.

Launch trains, once you are in auto-run, offers two modes:

The two passenger rules that shape network design

• Passengers do not penalise transfers. They turn up and take whatever the timetable offers. The wiki's worked example: on a network where every line is 1 train per hour, for three-quarters of each hour an interchanging passenger will just board the first train toward the hub — so point-to-point lines end up carrying about 75% transfer traffic and little else, and stations fill with transfer passengers.
• The best transfer is two trains stopped at the same time in the same station, exchanging passengers both ways. That needs a reasonably long stop — the wiki suggests 2–3 minutes, as in real life — and partially overlapping, not fully overlapping (if every train wants to enter and leave at once you get signalling delays, not transfers).

Signalling: two rules and a 30-metre hitbox

The wiki's junction guide reduces to two rules, applied in the order "waypoint":

1. Place a path signal at the entrance of a junction, in front of the branch.
2. Place a block balise at the exit of a junction.

The catch in rule 1 is the hitbox: place the entrance signal about 30 m in front of the branching point, because trains carry an additional 30 m hitbox in front of them. For rule 2, the balise can go directly after the junction, but it is better to put it at least one train length past it.

How the two signal kinds differ:

Both path signals and balises can be tagged so they apply to all trains, are ignored by trains with a matching tag, or are ignored by everything except trains with a matching tag. A path signal also has a global "alert me after a waiting train" timer, configurable from 0 minutes to 24 hours.

Collisions in NIMBY Rails are three kinds, and only one of them is a signalling problem: merging collisions, crossing collisions, and head-on collisions. The first two can technically resolve themselves once the blocking train moves away, but they are what path signals and balises exist to prevent. Head-on collisions on single track are the genuinely blocking case — no signal configuration alone fixes them, they need track design that lets trains pass each other.

The simulation has one more rule that constrains platform sharing: after a stop, a train always reserves the track up to the next signal in its direction of departure. That is a deliberate safety measure so trains cannot be trapped by a following train or collide on single track. It is also why two trains with overlapping stops in the same platform cannot be timetabled freely — Train 2 cannot reserve through to the platform-end signal while Train 1 occupies that end. A balise at the platform entrance overrides the reservation and lets a train enter regardless, but the wiki is blunt about the cost: the game will then no longer protect you, and it lists the specific ways that ends in a collision — a following train too long for the remaining space, arrivals out of order, an unrelated train scheduled for the same platform, or a same-line train delayed into the gap. Use it only with precise timetabling.

Depots, and why "technical maneuvers" matters

Since 1.5 there is no depot building and no "go to depot" order. A depot is a station used as a storage yard:

• Build a station (call it "Yard") with several parallel terminus tracks feeding a single entry signal. Zero its coverage area.
• Create a second line for the yard, with exactly one stop. Set that line's service level to "Technical maneuvers" — the line icon changes to the old depot icon.
• Schedule trains onto the yard line at night with manual orders.

The rule that makes this safe: passengers will never plan a trip that involves a technical-maneuvers line. They also cannot spawn in or target a zero-coverage station. So a yard is invisible to the simulation as long as you are consistent about the service level.

Which depot pattern you use is a function of line length. The wiki's worked guidance for a network run 4 am–2 am at 30-minute frequencies:

The reason the longest lines need the complicated pattern: a train running a line of 11 hours or more completes only one run in a day, so it "finishes the day" in the depot mid-afternoon while passengers are still out. Splitting the line with enter/exit stops in the timetable lets trains run more of the day.

Demand, spawn rate and satisfaction

• A station's spawn rate is how many new passengers it produces per second, per distance category. It is governed by demand (the base rate, per category) modulated by the station's average satisfaction — good satisfaction raises it above base, bad satisfaction pushes it below.
• Demand comes from the station's reach (population covered), the time of day and day of the week, and the global pax demand factor. The daily cycle peaks with commuter demand in the morning and evening; regional and intercity demand is more spread across the day; weekends are lower overall, though intercity demand is higher.
• Satisfaction tells you what combination of paid fares and journey time would put a station at a neutral level. You can compensate a slow train with a cheap fare, or charge more for a genuinely fast one. That is the trade you are actually optimising.

One caveat worth stating plainly: the wiki's Distance category page (local 0–15 km, regional 15–100 km, long distance over 100 km, used to decide how passengers pick a destination) is tagged by the wiki itself as a deleted feature, even though the page still describes it in the present tense. Treat those thresholds as historical unless you confirm them in your own version. The wiki also notes that hard cut-offs of this kind caused real problems — if your whole network sits inside a 100 km radius except for one station outside it, every long-distance passenger picks that one station.

The default train list

The game bundles 20 trains, with more available from the Workshop. Prices and top speeds below are the wiki's table, which states it was last updated for version 1.5.41 — several major versions before 1.19. Treat the relative ordering (a cheap MetroMover versus an expensive high-speed set) as reliable and the exact prices as indicative rather than current.

The traps

1. Blueprints do not run. Blueprinting is free and edits are unlimited, but no line or train can use blueprinted track. The network looks finished on the map and does nothing until you pay the bill with Build now.
2. Lines start closed. Until you set a line's service level to Full, passengers will not plan trips on it. An open-looking line carrying nobody is usually this.
3. Zero coverage means zero passengers. A station with no coverage area will never spawn a passenger or be chosen as a destination — which is exactly what you want for a yard and exactly what you do not want for a stop.
4. Ground-level track cannot cross water, and cannot cross streams or roads diagonally. Budget for viaducts or tunnels before you commit the route.
5. Curves are invalid below the track type's minimum radius. The build simply will not accept them, and the game's only feedback is the displayed radius and speed limit.
6. Every line is a circle. Forgetting the return leg means your trains run out and then wrap in a way you did not intend.
7. A walking transfer is capped at 2.3 km and runs at 1 m/s. It is a real transfer, not a free one.
8. Trains have a 30 m hitbox in front of them. Junction entrance signals placed at the branch point, rather than ~30 m before it, will let trains stop past the signal.
9. Junction protection is a pair, not a single signal. A path signal at the entrance with no balise at the exit lets reservations run on past the junction.
10. After a stop, a train reserves track to the next signal in its direction of departure. This is the rule behind almost every "why won't my second train enter the platform" question. Balises at platform entrances override it, and remove the safety net with it.
11. Station capacity is a slider, and stations do fill. Platform capacity runs 50 to 100,000; overflow can spill into the hall. The wiki's transfer-hub analysis treats around 10,000 waiting passengers as the practical ceiling, and notes a train standing in a station can warehouse passengers too.
12. Line duration must divide 1440 minutes for a clean 24-hour service, or the remainder becomes a long stop at the first station.
13. Importing an old save into 1.19 breaks timings. The new motion loop made trains brake more slowly; the developer's own testing found more than 50% invalid runs on pre-1.19 saves. The global brake factor (auto-set to 1.5 for 1.18-and-earlier saves) is the remedy.
14. Train size now matters anywhere, not just at branches. Since 1.16 the collision system uses real train footprints, so a train that fits a platform alone may not fit it alongside another.
15. Nothing here is a tutorial. The wiki's own tutorials for building stations, creating a line and scheduling a train were still unwritten at the time of this guide — the Contents page links them as redlinks — so the in-game UI and the reference pages are your documentation.

Sources

Wiki (official, wiki.nimbyrails.com), read as raw wikitext through its own API (/api.php?action=parse&page=<Page>&prop=wikitext):

• Quickstart guide — the gameplay loop, blueprinting, lines-as-circles, service level, satisfaction vs fares.
• How to build track — track tools and hotkeys, control points and midpoints, ground/viaduct/tunnel levels, water and road crossing restrictions, curve radius and speed limits, Ctrl/Shift modifiers, Insert-to-blueprint and the double-charge on rebuild.
• How to signal a junction — the path-signal-entrance / balise-exit rule, the 30 m hitbox, balise placement one train length past the junction.
• Signal — the five current signal types and their tags, path-check range, the removed block signal.
• How to have multiple trains share a platform — platform reservation after a stop, the balise override and the specific collision cases it exposes.
• Guide to station approaches — why approaches are low-speed, and the 60/40 km/h figures for constrained junctions.
• Track layout guide — track capacity worked as trains per hour (a train every 5 minutes = 12 tph; a 3-minute junction crossing = 20 tph).
• How to use depots — stations-as-yards, zero coverage, "technical maneuvers" service level, passengers never planning over technical lines.
• Depot strategies — single / dual / mixed-days dual depot and the line-length thresholds.
• Transfer hub strategy — passengers not penalising transfers, same-time transfers and the 2–3 minute stop, the ~10,000 waiting-passenger ceiling.
• How to manual timetable — relative stop times, orders and runs, auto-run-24/7 limitation, first train departure, launch train modes, the fixed-interval gap example.
• Station — overlapping footprints, coverage as reach, the 2.3 km OSI limit and 1 m/s walking speed, the 50–100,000 capacity slider and hall overflow, station-as-depot settings.
• Spawn rate — demand from reach × time of day × global factor, satisfaction modulation, the 8–15% European demand factor, and the note that population is the only factor since 1.6.
• Pax, Simulation, Duration, Line, Order, Run, Stop, Platform, Track, Blueprint, Layer, Point of Interest, Demand Curve, Pathfinding, Distance category (tagged deleted feature), How to use the in-game routeplanner, Mapping resources, NIMBY:Contents — supporting definitions and the routeplanner procedure.
• List of trains — the 20 default trains with price per car, car counts and top speeds; the table states it is as of version 1.5.41.

Steam and developer:

• api.steampowered.com/ISteamNews/GetNewsForApp/v2/?appid=1134710 (Weird and Wry's own Steam announcements) — Version 1.19 (9 August 2026) map engine, PMTiles/MLT, map rotation, custom map sources, Linux port; Version 1.19.10 (18 August 2026), the current release; Version 1.18 NimbyScript; Version 1.17; Version 1.16.
• carloscarrasco.com/nimby-rails-january-2025/ — the developer's devblog on the 1.16 dynamic schedules: multiple trains per shift, shift holes, dynamic dispatch, and the rule that passengers always treat a shift hole as a technical maneuver.
• carloscarrasco.com/nimby-rails-march-2026/ — the 1.19 motion loop: fixed 0.01 s physics step, the resulting timing changes, and the global brake factor (1.5 for pre-1.19 saves).
• carloscarrasco.com/nimby-rails-may-2026/ — 1.19 raster layer work and the new map coordinate system.
• steamdb.info/app/1134710/patchnotes/ — patch timeline used to confirm 1.19 = 9 August 2026 and 1.19.10 = 18 August 2026.

Not verified, and flagged as such in the text: the default train prices, car counts and top speeds date from the wiki's version 1.5.41 table; the local/regional/long-distance thresholds come from a wiki page the wiki itself marks as a deleted feature; and no source found states track construction costs per metre, so this guide gives none.