22 days ago
Project: xfig
Service: just-comfort frontend
I'm trying to determine the supported way to pass a sensitive build-time secret to a Dockerfile RUN step on Railway without leaking it into Build Logs.
Specific question: does Railway's Docker builder support BuildKit's RUN --mount=type=secret,id=... syntax, with a Railway service variable bound to the secret id?
Use case: I need SENTRY_AUTH_TOKEN available only during npm run build for Sentry source-map upload, with no exposure in Build Logs or image metadata.
Desired Dockerfile pattern:
# syntax=docker/dockerfile:1.4
RUN --mount=type=secret,id=sentry_auth_token \
SENTRY_AUTH_TOKEN="$(cat /run/secrets/sentry_auth_token)" \
npm run build
Four questions:
1. Does Railway's Dockerfile builder support RUN --mount=type=secret?
2. If yes, how do I bind a Railway service variable to the secret id at build time? For example, how would SENTRY_AUTH_TOKEN become available as id=sentry_auth_token?
3. If no, what is Railway's recommended pattern for build-time secrets that must not appear in Build Logs?
4. Do sealed variables prevent Build Log exposure when used inside Docker RUN commands, or would they still be expanded/logged if passed through ARG/ENV?
Context: I previously had SENTRY_AUTH_TOKEN declared as ARG and passed inline on a RUN command. Docker/Railway logged the resolved RUN command with the token value expanded, so the token leaked into Build Logs. The token has been revoked. I'm looking for a Railway-supported safe pattern before adding the replacement token.
2 Replies
22 days ago
This thread has been marked as public for community involvement, as it does not contain any sensitive or personal information. Any further activity in this thread will be visible to everyone.
Status changed to Open Railway • 22 days ago
22 days ago
- No, we only support this for Railpack.
- N/A
- Build ARGs - not as big of an issue in this case, as your image is stored privately in our registry, just don't use it in RUN directly.
- They are expanded.
9 hours ago
Building on Brody's answer, I would keep the replacement Sentry token out of the Dockerfile build path entirely.
The risky pattern is this:
dockerfile
ARG SENTRY_AUTH_TOKEN
RUN SENTRY_AUTH_TOKEN=$SENTRY_AUTH_TOKEN npm run build
Even if the variable is sealed in Railway, once it is expanded inside RUN, it can still appear in logs, process output, or image metadata depending on how the command runs.
For this Sentry source-map upload case, I would use one of two safer patterns:
Switch this service to Railpack and run the source-map upload as part of the build command with SENTRY_AUTH_TOKEN set as a Railway service variable. Make sure the script does not echo the token, does not use shell tracing, and does not print the full environment.
If you need to keep the Dockerfile, build the frontend on Railway without the Sentry token, then upload source maps from CI using a CI secret:
-
run: npm ci
-
run: npm run build
-
run: sentry-cli sourcemaps upload dist/assets
env:
SENTRY_AUTH_TOKEN: ${{ secrets.SENTRY_AUTH_TOKEN }}
Since the previous token was exposed, I would do this before adding the replacement token:
Keep the old token revoked.
Create a replacement token with only the Sentry scopes needed for release/source-map upload.
Remove the token from Dockerfile ARG and inline RUN usage.
Test the new build path with a harmless canary value first.
Only add the real token after confirming the canary does not appear in build logs.
If the canary appears anywhere in the logs, the replacement token should not be used in that build path.