2 months ago
Hello Railway Support,
We are trying to use Railway CLI non-interactively in GitLab CI for deployments, but
newly created tokens are being rejected by the CLI immediately.
Issue summary:
- We created multiple fresh Railway tokens from the dashboard
- We tested them both locally and in GitLab CI
- None of them authenticate with Railway CLI
- The failure happens before deployment, during basic auth/link commands
Repro steps:
1. Set a newly created token as an environment variable:
export RAILWAY_TOKEN=""
2. Run a basic auth check:
railway whoami
3. Run a project link command:
railway link --project 2bb7e018-0831-4880-984b-f67b0eded84c --service backend
--environment staging
Expected result:
- railway whoami authenticates successfully
- railway link succeeds for a valid token with access to the specified project/
environment
Actual result:
Unauthorized. Please login with railway login
Project context:
- Project ID: 2bb7e018-0831-4880-984b-f67b0eded84c
- Services: backend, worker
- Environments: staging, production
What we observed:
- The same unauthorized error occurs locally and in CI
- We tested multiple freshly created tokens
- We believe we tested both project/environment-style tokens and account/workspace-level
tokens
- None of them work even for railway whoami
Questions:
1. What exact token type should be used for headless CLI auth in CI for commands like
railway whoami, railway link, and railway up?
2. Should current Railway CLI use RAILWAY_TOKEN or RAILWAY_API_TOKEN for non-interactive
auth?
3. Do project/environment tokens support railway link, or only deploy commands such as
railway up?
4. Is there any propagation delay or activation step for newly created dashboard tokens?
5. Is there a known issue where dashboard-generated tokens are rejected by the CLI with
Unauthorized. Please login with railway login?
This is currently blocking our GitLab CI deployment setup.
Thanks.
Pinned Solution
2 months ago
Hello!
Building on what was mentioned above, that's exactly the root cause. Scoped tokens (Project Tokens) only support deploy commands like railway up, railway redeploy, and railway logs. They can't run railway whoami or railway link.
To get full CLI functionality in CI, you need an Account Token set as RAILWAY_API_TOKEN (not RAILWAY_TOKEN).
One thing to watch out for: if both RAILWAY_TOKEN and RAILWAY_API_TOKEN are set, the project token takes precedence and silently overrides the broader one.
For your GitLab CI, create an Account Token from Account Settings in the dashboard and use it like this:
Variables: RAILWAY_API_TOKEN: $RAILWAY_ACCOUNT_TOKEN
Deploy:
image: ghcr.io/railwayapp/cli:latest
script:
- railway whoami
- railway link --project 2bb7e018-0831-4880-984b-f67b0eded84c --service backend --environment staging
- railway up --ci
Hope this helps unblock things!
4 Replies
2 months ago
Your project and services (backend, worker) are active and healthy on our Pro plan. The CLI distinguishes between two environment variables: RAILWAY_TOKEN is exclusively for project tokens (created in project settings, scoped to one environment), and RAILWAY_API_TOKEN is for account or workspace tokens (created at railway.com/account/tokens). These are not interchangeable - setting an account/workspace token as RAILWAY_TOKEN will fail because the CLI sends it with a different authentication header internally. Commands like railway whoami and railway link require an account or workspace token set as RAILWAY_API_TOKEN. Project tokens set via RAILWAY_TOKEN only support deployment commands like railway up, and they already know their target project/environment so railway link is unnecessary. For your CI pipeline, if you need railway link and railway up, use a workspace token set as RAILWAY_API_TOKEN; if you only need railway up to a specific environment, use a project token set as RAILWAY_TOKEN and skip the link step. There is no propagation delay for newly created tokens.
Status changed to Awaiting User Response Railway • about 2 months ago
2 months ago
This thread has been marked as public for community involvement, as it does not contain any sensitive or personal information. Any further activity in this thread will be visible to everyone.
Status changed to Open Railway • about 2 months ago
2 months ago
Hello!
Building on what was mentioned above, that's exactly the root cause. Scoped tokens (Project Tokens) only support deploy commands like railway up, railway redeploy, and railway logs. They can't run railway whoami or railway link.
To get full CLI functionality in CI, you need an Account Token set as RAILWAY_API_TOKEN (not RAILWAY_TOKEN).
One thing to watch out for: if both RAILWAY_TOKEN and RAILWAY_API_TOKEN are set, the project token takes precedence and silently overrides the broader one.
For your GitLab CI, create an Account Token from Account Settings in the dashboard and use it like this:
Variables: RAILWAY_API_TOKEN: $RAILWAY_ACCOUNT_TOKEN
Deploy:
image: ghcr.io/railwayapp/cli:latest
script:
- railway whoami
- railway link --project 2bb7e018-0831-4880-984b-f67b0eded84c --service backend --environment staging
- railway up --ci
Hope this helps unblock things!
2 months ago
I ran into a similar issue and found that the scoped tokens explainer to be the solution to my issue. Thank you.
Edit: Still can't get CD working even with a personal unscoped token in Github Actions.
Status changed to Solved 0x5b62656e5d • about 1 month ago