Set the environment variable NO_CACHE=1 on your service, then trigger a redeploy. This forces a full rebuild without cached layers, bypassing the stale snapshot referencing the old root directory path. Once the build succeeds, you can remove NO_CACHE=1 to re-enable caching with the correct configuration going forward.

The NO_CACHE=1 variable you suggested worked once but the build is still intermittently failing with the same snapshot error sha256:ea81a5cb62599320b1409e7bc985904563f4e436c9a89fcf11015a6b8a7b30a6. The snapshot keeps being reused. Please permanently delete/invalidate this specific snapshot from your build cache for my service. Project: Hermes Agent, Service ID visible at hermes-agent-production-cb05.up.railway.app.

Looking at your service config right now, the Root Directory field is actually set to dweber2026/hermes-agent, not blank. That's the value causing the failure.

There's no cached snapshot to delete on our side. The "snapshot" in the build log is just your source code being unpacked for this build session, which is why the same hash keeps appearing (it's the same source content). The error happens immediately after unpack, when the builder tries to enter the configured Root Directory inside the unpacked source:

unpacking archive
Build Failed: lstat .../snapshot-target-unpack/dweber2026: no such file or directory

dweber2026/hermes-agent is your GitHub repo path (owner/name). The Root Directory setting expects a subdirectory inside the repo, like apps/web or services/api. Since there's no dweber2026/ folder inside the repo, the builder can't cd into it.

Fix:

1. Open the service's Settings tab
2. Under Source, clear the Root Directory field (leave it blank, or set it to /)
3. Redeploy

You can also remove the NO_CACHE=1 variable once that's done. Apologies for the earlier suggestion, it wouldn't have fixed this since the failure is in the source unpack step before any build caching applies.

the root directory is blank. dweber2026/hermes-agent was in it previously, but i deleted it. must cached somewhere... see screenshot for reference

Thanks for the screenshot, that confirmed it. The issue is on our side, not something you can fix from the UI.

Your service had the root directory persisted in a legacy field that our newer UI doesn't read from, so the UI was showing it as cleared while the builder was still using the old dweber2026/hermes-agent value. There's no cache to invalidate either - the snapshot hash you keep seeing is just the hash of your source archive, which stays identical until your source changes.

I cleared the legacy value on our end. To pick up the fix, trigger a fresh deploy rather than clicking "Redeploy" on the failed one - push a commit to main, use the Deploy button on the Deployments tab, or run railway up from the CLI. Once that succeeds, you can also remove the NO_CACHE=1 variable. Apologies for the runaround.

That worked, thank you for the help! You can close this issue