15 days ago
- Deployment ID:
12e484a8-0d7e-4839-a836-e61a8fdb582a - Error:
failed to solve: secret sc-domain not found - Service:
independent-hope - Last successful build: May 7 at 15:06 UTC
7 Replies
Status changed to Open Railway • 15 days ago
14 days ago
yes, the issue in only in staging, main doing well although both have same varaibles. removing variable also did not help
14 days ago
is that a sealed variable? usually sealed variable are not copied from main environment
14 days ago
no not sealed
14 days ago
yes, no, all variables remaining same. apart from the cs- domian ,its in main and thats working fine, its the stagic which is not building
12 days ago
The exact error failed to solve: secret sc-domain not found points at a Docker BuildKit secret mount, not a normal Railway runtime variable.
Look in the Dockerfile for something like:
```dockerfile
RUN --mount=type=secret,id=sc-domain ...
```
That syntax only works if the builder is explicitly given a BuildKit secret with the exact ID sc-domain. A normal Railway service variable named sc-domain is not automatically the same thing as a BuildKit secret mount.
There is a related Railway thread where a Railway employee answered that Dockerfile builds do not support RUN --mount=type=secret,id=... secrets; they only support that path for Railpack. So if your staging Dockerfile/build path relies on --mount=type=secret,id=sc-domain, staging can fail even if the Railway variable exists.
What I would check:
1. Search the repo/Dockerfile for --mount=type=secret and sc-domain.
2. If it is only needed as a build-time value, convert it to a Railway build variable read via ARG, for example:
```dockerfile
ARG SC_DOMAIN
RUN your-build-command
```
and rename the Railway variable to a shell-safe name like SC_DOMAIN. Hyphenated names such as sc-domain are awkward/impossible to use as normal shell env vars.
3. If it is truly secret, avoid echoing/interpolating it directly in RUN commands because Docker/Railway build logs can show expanded commands. Use it only as an env value consumed by the build tool, or move that step out of the Docker build if it must stay fully secret.
4. Compare staging vs main for RAILWAY_DOCKERFILE_PATH, root directory, and environment-specific variables. If staging uses a different Dockerfile or build context, it may be the only environment hitting the --mount=type=secret,id=sc-domain line.
5. If the variable was sealed in main and staging was created/duplicated separately, re-create it in staging manually. Railway docs note sealed variables are not copied when duplicating environments/services.
So the likely fix is not redeploying repeatedly. It is to remove the unsupported BuildKit secret mount from the Dockerfile build path, or switch that build to a supported Railway/Railpack secret mechanism, then redeploy staging.