This generally means there is a required variable missing from your railpack deployment configuration.

Do you have a railpack.json defined?

No, there is no railpack.json defined in the repository. We are using Railway's default Railpack configuration with custom Build and Start commands configured in the Railway UI.

The issue still occurs with Railpack 0.38.0 before dependency installation:

using build driver railpack-v0.38.0

install apt packages: libatomic1

install mise packages: node, pnpm

Build Failed: build daemon returned an error < failed to solve: secret N not found >

scheduling build on Metal builder "builder-geiqef"

There is no environment variable or secret named N.

A previous attempt on the same builder also failed with no active session / context canceled.

The repository builds locally with the pinned pnpm@11.19.0.

Could this be related to the generated Railpack plan or the BuildKit secret session on builder-geiqef?

Did the build succeed with an old version of railpack, or has the build always failed?

This is really odd! Could you download the railpack binary and run railpack info --show-plan . and drop the output here? I can't think of reason this would occur.

Thanks — I ran Railpack 0.38.0 locally.

It detects:

node 24.19.0

pnpm 11.19.0

The generated plan does not contain any secret named N.

The step that fails remotely:

packages:mise

→ mise install

→ install mise packages: node, pnpm

has no explicit secrets field in the locally generated plan.

The only secrets-related entry I can see is on the later build step:

"secrets": ["*"]

There is no top-level railpack.json in the repository.

I also noticed my first local railpack info run did not include Railway's UI build/start overrides or DATABASE_URL, so I'm going to generate a second plan with those inputs to make it closer to Railway's generated plan.

The remote failure still happens before dependency installation:

install mise packages: node, pnpm

failed to solve: secret N not found

This seems especially odd because the locally generated packages:mise step does not reference N.

Interesting! It must be something in your railway service variables. Could you share any vars that don't contain sensitive variables?

Thanks. I verified the variable configuration.

The only custom service variable is:

DATABASE_URL

It is configured as a Railway Postgres Reference, not as a manually entered URL.

The other variables are Railway-provided system variables:

RAILWAY_PRIVATE_DOMAIN

RAILWAY_PROJECT_NAME

RAILWAY_ENVIRONMENT_NAME

RAILWAY_SERVICE_NAME

RAILWAY_PROJECT_ID

RAILWAY_ENVIRONMENT_ID

RAILWAY_SERVICE_ID

There are no custom variables named N, and no custom variable names containing spaces or unusual characters.

I also generated the Railpack 0.38.0 plan locally with a dummy DATABASE_URL. The generated plan contains only:

"secrets": ["DATABASE_URL"]

and no N secret anywhere.

Could the Railway Postgres reference expansion or BuildKit secret handling be producing the stray N?

We isolated the issue further.

The Docker build now succeeds, but the runtime container does not receive the service variable at all.

DATABASE_URL is configured on the @workspace/api-server service as:

${{Postgres.DATABASE_URL}}

The Postgres service is online and the reference resolves correctly in the Railway UI.

To verify whether the variable reaches the container, we temporarily added this runtime diagnostic:

Boolean(process.env.DATABASE_URL)

The deployment logs show:

DATABASE_URL present: false

The application then exits with:

Error: DATABASE_URL must be set. Did you forget to provision a database?

There are currently no visible pending/staged changes on the project canvas.

So the variable is visible/configured in the Railway dashboard, but it is not being injected into the runtime environment.

Could you please check whether this project/environment is stuck in a variable injection/configuration state on Railway’s side?

Project: refreshing-balance

Environment: production

Service: @workspace/api-server

The application itself appears to behave correctly — it only fails because DATABASE_URL is genuinely absent from process.env.

Try run echo $DATABASE_URL to check if it's actually injected or not

You can also check the Deployment Details to see the Deployment Configuration and Variables