10 days ago
I configured the literal, service-scoped variable:
RAILPACK_VERSION=0.39.0
The value is not a shared/reference variable and was present before both builds.
The service has no railway.toml, railway.json, or custom Config-as-Code path.
However, two separate builds used Railpack 0.40.0:
-
2026-09-25, deployment ea786b06…:
source uploaded with
railway up, CLI 5.57.2 -
2026-09-26, deployment 8b89a309…:
GitHub-connected source
Both build logs contain:
[railway] prepare railpack-v0.40.0
and display the “Railpack 0.40.0” banner.
Earlier deployments used 0.39.0 only while 0.39.0 was the latest available version.
The documentation currently states that RAILPACK_VERSION can set the Railpack
version, but the dashboard exposes no Railpack version field and the new
Infrastructure-as-Code reference does not appear to expose one either.
Questions:
-
Is RAILPACK_VERSION supported for services that have never used Config as Code?
-
Is there any additional requirement for the variable to affect the builder version?
-
What is the supported way to pin Railpack after the Config-as-Code cutoff on
2026-12-01?
-
Is this a known issue, and is there a current workaround?
1 Replies
10 days ago
We don't currently offer a setting that reliably controls which Railpack version a build runs on. That covers RAILPACK_VERSION, dashboard settings, Config as Code, and Infrastructure as Code, and it applies to railway up and GitHub-sourced builds alike. It stays the case after the Config as Code cutoff on 2026-12-01, so pinning isn't a workaround here.
The version a deployment actually used is recorded in its own build logs, which is where you found it.
Status changed to Awaiting User Response Railway • 10 days ago
3 days ago
This thread has been marked as solved automatically due to a lack of recent activity. Please re-open this thread or create a new one if you require further assistance. Thank you!
Status changed to Solved Railway • 3 days ago