Summary

railway up consistently fails with prefix not found immediately after the local archive finishes compressing (100%), before any deployment record is ever created server-side. Reproduced identically across every variant of the command tried, on two different CLI versions, from two different machines/contexts (agent session and the account owner's own terminal).

Project / service

Workspace: mvelez88's Projects

Project: voxtter-hw-test (fe5ce6bd-4b58-42d1-95e1-683db4a8e22f)

Environment: production (9a3354c1-c42b-47c7-bf7c-83add059ff9f)

Service: voxtter-app (a1890f09-88b8-414d-88db-414ce6d7b213)

Builder: DOCKERFILE, dockerfilePath: "/Dockerfile", rootDirectory: null

Domain: voxtter-app-production.up.railway.app (currently online, serving a build from 2026-07-24, six days before this report)

Exact error

Indexing...

Compressed [====================] 100%

prefix not found

Exit code 1. No further detail printed, even with --verbose.

What was tried (all fail identically)

railway up . -p -s -e production -y -c -m "..."

Same, with -s voxtter-app (service name instead of ID)

railway link -p ... -s voxtter-app -e production (succeeds, prints correct resolved IDs) followed by bare railway up . -y -c -m "..." relying on the link instead of explicit flags

Upgraded CLI from 5.26.4 → 5.30.1 (Homebrew), retried — no change

Set service variable RAILWAY_DOCKERFILE_PATH=/Dockerfile (the fix Railway support gave for a superficially similar "prefix not found" report on the Help Station, tied to a misconfigured railway.json) with --skip-deploys, then retried railway up — no change

Confirmed no railway.json / railway.toml exists anywhere in the repo, ruling out the documented root cause for that other report

What was ruled out

Not a local/CLI-invocation issue: identical failure whether IDs or names are passed, whether relying on an explicit railway link or passing all three of -p/-s/-e directly.

Not environment-specific: reproduced from an agent sandbox and from the account owner's own interactive terminal, same machine, same Railway account/session.

Not a stale-CLI bug: reproduced on the latest CLI version (5.30.1) after a clean Homebrew upgrade.

Not the documented railway.json-path bug: no such file exists in this repo; the RAILWAY_DOCKERFILE_PATH workaround Railway support gave for that case had no effect here.

No orphaned/partial deployment: railway deployment list for the service shows the last entry is still the 2026-07-24 SUCCESS build; none of the failed up attempts today created any deployment record (successful or failed) server-side — the dashboard's Deployments tab confirms the same. The failure happens before Railway's backend ever registers an attempt.

Additional steps taken (all still fail identically)

Full local session reset: rm -rf ~/.railway, fresh railway login, railway whoami confirms clean re-auth as the account owner — retried railway up, same prefix not found.

Created a brand-new, never-before-deployed service in the same project (railway add --service voxtter-app-v2), replicated all app config onto it via Railway variable references (${{voxtter-app.KEY}}, so no secret values were ever read/exposed), and ran railway up targeting that new service. Identical prefix not found failure, at the same point (right after local compression, before any deployment record is created). The test service was deleted afterward (railway service delete) since it added nothing.

Conclusion

Since a freshly created, empty service in the same project fails identically to the six-day-old production service, this rules out any service-specific corrupted state. The problem is at the project, account, or platform level — not fixable by recreating resources, and not fixable from the client repo or CLI flags/session state.

Ask

Given the failure occurs before any deployment object is created, this looks like a platform-side issue with how this project resolves its upload prefix (object-storage key prefix?) rather than anything fixable from the client repo or CLI flags. Requesting help identifying what's misconfigured for project voxtter-hw-test (fe5ce6bd-4b58-42d1-95e1-683db4a8e22f) specifically, since it reproduces for every service tried within it.