Summary

After @railway/cli v5.3.0 was published (2026-06-05 ~16:42 UTC), our GitHub Actions deploys started failing at railway up with "Not signed in.", even though a valid project token is provided via the RAILWAY_TOKEN environment variable. The identical workflow worked on v5.2.0. Pinning back to @railway/cli@5.2.0 restored it with no other changes.

Environment

• CI: GitHub Actions (ubuntu-latest)
• CLI install: npm install -g @railway/cli (unpinned → picked up v5.3.0)
• Auth: project token (environment-scoped to our production environment) supplied as RAILWAY_TOKEN
• We do not run railway login; auth is entirely via the token env var.

Command

railway up --service backend --environment production --detach

(run for several services in the same project/environment)

Output on v5.3.0

Not signed in.
  → Run `railway login` to authenticate, then re-run.
Error: Process completed with exit code 1.

Exit code 1; nothing is deployed.

What works

The same command, same token, same workflow, on v5.2.0 authenticates and deploys successfully.

Version timeline (from your GitHub releases)

• v5.2.0 — 2026-06-05 12:50 UTC — works
• v5.3.0 — 2026-06-05 16:42 UTC — fails as above

Questions

1. Is this an intentional change in v5.3.0 to how railway up accepts a project token via RAILWAY_TOKEN (especially when --service and --environment are passed explicitly)? If so, it's a breaking change that wasn't obvious from the release notes.
2. What is the supported way to run railway up --service <svc> --environment <env> non-interactively in CI on v5.3.0+ — should we switch to an account/team token via RAILWAY_API_TOKEN, drop the --environment flag, or something else?
3. Could you confirm whether project tokens in RAILWAY_TOKEN are still supported for railway up going forward?

We've pinned to v5.2.0 as a workaround, but would like to move forward on a supported configuration.