The reference page currently groups all Railway-provided variables under "all builds and deployments" without distinguishing which ones carry a value at build time vs. only at runtime. We have noted the feedback to clarify that distinction in the docs, since variables like RAILWAY_DEPLOYMENT_ID that depend on a deployment existing would naturally be empty during the build phase.

Thank you! Is it possible to get an ETA on when we can get this list?

We don't have an ETA for that docs update, but your feedback is captured here and visible to the team.

can we get a list here?

Hey — docs still don’t publish a per-var build vs runtime matrix; what they do say (no invented empties):

Reference gap

Railway-provided variables still groups everything under “all builds and deployments” — one table, no build/runtime column. That’s the clarity ask; still open in the docs.

Documented injection

Using Variables + Build-time vs runtime secrets: service + Railway-provided vars go to the build and the running deployment. Railpack exposes them automatically; Dockerfile needs matching ARG in the using stage (Dockerfiles) — missing ARG → empty at build. Frontend env: both phases; NEXT_PUBLIC_ = client-bundle only. Volumes not mounted at build (secrets guide).

Conditionals

• Git vars: only if deploy from a GitHub trigger.
• Tracing / OTEL: to deployments when tracing is on.
• Replica IDs: for running replicas/tags (observability docs).

Your RAILWAY_DEPLOYMENT_ID + Next build

Blank at build matches the bot + your report, but that split is not in the reference table — undocumented. Prefer RAILWAY_GIT_COMMIT_SHA for build cache-busting (GitHub deploys), or read RAILWAY_DEPLOYMENT_ID at runtime in server-side Next. Don’t use build-time NEXT_PUBLIC_*/cache keys until build logs show it’s set. Dockerfile: ARG in build stage.

Undocumented: official per-key build/runtime emptiness matrix. Prefer reference names (RAILWAY_ENVIRONMENT_NAME/_ID).

The useful distinction is between variables whose values are known from project/service/environment configuration when the build is created, and variables whose values depend on the resulting deployment/runtime infrastructure.

For build-time use, the stable identifiers/names are the safe group to rely on: RAILWAY_PROJECT_NAME, RAILWAY_PROJECT_ID, RAILWAY_ENVIRONMENT_NAME, RAILWAY_ENVIRONMENT_ID, RAILWAY_SERVICE_NAME and RAILWAY_SERVICE_ID. For GitHub-triggered deployments, the documented RAILWAY_GIT_* metadata is also known from the source trigger and is appropriate for build metadata/cache keys.

I would treat the following as deployment/runtime-dependent rather than build identifiers: RAILWAY_DEPLOYMENT_ID, RAILWAY_SNAPSHOT_ID, RAILWAY_REPLICA_ID and RAILWAY_REPLICA_REGION. Likewise RAILWAY_VOLUME_NAME and RAILWAY_VOLUME_MOUNT_PATH only make sense where the deployment has an attached volume, and TCP proxy/domain variables are conditional on the corresponding networking configuration.

That explains the RAILWAY_DEPLOYMENT_ID behaviour you observed: Railway’s reference currently says the provided variables are supplied to “all builds and deployments”, but Railway’s reply above correctly notes that a deployment-dependent value can be empty while the image is being built because the deployment it identifies does not yet exist.

So for your Next.js build/cache-busting case I would not use RAILWAY_DEPLOYMENT_ID as the build version. For a GitHub deployment, RAILWAY_GIT_COMMIT_SHA is the natural immutable build identifier. If you need an identifier independent of GitHub, use a value you control or another identifier that is known before the build rather than a deployment/replica ID.

A docs table with columns such as Build value / Runtime value / Conditional would remove the ambiguity. At minimum I would document the groups as:

Build-safe project context: RAILWAY_PROJECT_NAME, RAILWAY_PROJECT_ID, RAILWAY_ENVIRONMENT_NAME, RAILWAY_ENVIRONMENT_ID, RAILWAY_SERVICE_NAME, RAILWAY_SERVICE_ID.

Build-safe when GitHub-triggered: RAILWAY_GIT_COMMIT_SHA, RAILWAY_GIT_AUTHOR, RAILWAY_GIT_BRANCH, RAILWAY_GIT_REPO_NAME, RAILWAY_GIT_REPO_OWNER and RAILWAY_GIT_COMMIT_MESSAGE.

Deployment/runtime-dependent: RAILWAY_DEPLOYMENT_ID, RAILWAY_SNAPSHOT_ID, RAILWAY_REPLICA_ID and RAILWAY_REPLICA_REGION.

Conditional infrastructure/runtime values: RAILWAY_PUBLIC_DOMAIN, RAILWAY_PRIVATE_DOMAIN, RAILWAY_TCP_PROXY_DOMAIN, RAILWAY_TCP_PROXY_PORT, RAILWAY_TCP_APPLICATION_PORT, RAILWAY_VOLUME_NAME and RAILWAY_VOLUME_MOUNT_PATH.

That also avoids implying that “available to the build environment” necessarily means “has a meaningful non-empty value during the build”. For cache keys specifically, RAILWAY_GIT_COMMIT_SHA is preferable to RAILWAY_DEPLOYMENT_ID for GitHub-triggered builds.