Build failed multiple times
bobbysatya01
HOBBYOP

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
$10 Bounty

7 Replies

Status changed to Open Railway 15 days ago


what is sc-domain? is that an environment variable?


bobbysatya01
HOBBYOP

14 days ago

yes, the issue in only in staging, main doing well although both have same varaibles. removing variable also did not help


is that a sealed variable? usually sealed variable are not copied from main environment


bobbysatya01
HOBBYOP

14 days ago

no not sealed


any changes from last success build?


bobbysatya01
HOBBYOP

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


jeggob
FREETop 10% Contributor

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.


Welcome!

Sign in to your Railway account to join the conversation.

Loading...