Nixpacks Build Pipeline and Railway Runtime: Where Should Bottleneck Measurement Live?

Answer

Instrument the Nixpacks install and build phases with timestamps in the deploy logs; this gives a reliable split between build time and runtime startup latency, with only ~second‑level distortion from the log pipeline. Health‑check/DNS latency appears after the start phase log line, so it belongs to the runtime side. Failed health‑check deploys retain Nix store artifacts that count toward the project’s disk quota, but only the aggregate quota is visible in the dashboard.

Confirmed facts

• Nixpacks writes phase timestamps (detect, install, build, start) to stdout/stderr; Railway’s log collector forwards these lines.
• The log pipeline adds buffering of roughly 100‑500 ms per line, so phase boundaries are accurate to about ±1 s but sub‑second granularity is distorted.
• Nix store caching works at the derivation level (/nix/store path); a lockfile change that alters any transitive dependency hash invalidates the entire derivation subtree.
• Railway’s internal DNS (service-name.railway.internal) resolves after the container reports healthy; the first resolution can add 2‑5 s of latency that shows up in application logs, not in build logs.
• Failed health‑check deploys do not purge the Nix store; the retained layers count against the project’s disk quota. Only the total quota usage is shown in the Railway dashboard; per‑deploy cache size is not exposed.

Likely explanation & measurement steps

1. Add a simple timestamp wrapper around the Nixpacks phases, e.g.:

   # in your repo, create a script `measure.sh`
   #!/usr/bin/env bash
   echo "[$(date +%s%3N)] Nixpacks detect start"
   # let Nixpacks run its detect phase (automatically)
   echo "[$(date +%s%3N)] Nixpacks detect end"
   echo "[$(date +%s%3N)] Nixpacks install start"
   # Nixpacks install phase
   echo "[$(date +%s%3N)] Nixpacks install end"
   echo "[$(date +%s%3N)] Nixpacks build start"
   # Nixpacks build phase
   echo "[$(date +%s%3N)] Nixpacks build end"
   echo "[$(date +%s%3N)] Nixpacks start start"
   # your app start command
   echo "[$(date +%s%3N)] Nixpacks start end"
   

   Make the script executable and set it as the entrypoint in your Railway service (or wrap the start command). The timestamps appear in the deploy logs; subtract consecutive values to get phase durations.
2. To distinguish cache invalidation from health‑check delay:
   • Look for lines like "Reusing cached layer" or "Building fresh layer" in the install/build section of the logs. Their presence indicates whether the Nix store derivation was reused.
   • Compare the start phase timestamp to the first line of your application log (e.g., the first console output). The gap includes internal DNS resolution and the health‑check probe.
3. If you suspect the health‑check is the culprit, temporarily set healthcheckPath to an endpoint that returns 200 immediately and healthcheckTimeout to a low value (e.g., 1s). Observe whether the gap between start and the first app log shrinks.

One missing diagnostic detail

To confirm whether log‑pipeline distortion is affecting your decision, please share the observed duration (in seconds) between the start phase timestamp and the first line of your application log for a recent deploy. If that gap is consistently >2 s, the health‑check/DNS latency is likely dominant; if it’s <1 s, focus on build‑phase caching.