railway-mcp — rgate
Manage multiple Railway CLI logins on one machine. Switch accounts instead of logging out.
The Railway CLI holds exactly one login, in ~/.railway/config.json.
railway logout throws it away, and there is no way back except a fresh
browser login. If you work across a personal account and a client account,
that is a login every time you change context.
rgate snapshots each login after you create it, and swaps them back in on
demand. There is no rgate logout — that omission is the point.
$ railway login # personal
$ rgate sync
synced michaelle.lubich@gmail.com (workspaces: Misha Lubich's Projects)
$ railway login # client
$ rgate sync
synced ops@client.com (workspaces: Client Inc)
$ rgate ls
# email name workspaces token
1 michaelle.lubich@gmail.com Misha Lubich 1 valid
2 ops@client.com Ops 1 valid active
$ rgate switch 1
switched to michaelle.lubich@gmail.com
Install
uv tool install railway-mcp # or: pipx install railway-mcp
Needs the Railway CLI on PATH.
Commands
| Command | What it does |
|---|---|
rgate sync |
Save the active railway login into the store |
rgate ls |
List stored accounts and credential status |
rgate switch <email|id|#> |
Make a stored account the active login |
rgate whoami |
Show the active account |
rgate projects |
Show the directories linked to a project |
rgate doctor |
Check the setup and credential health |
rgate path |
Print config and store locations |
rgate rm <selector> |
Forget a stored account |
rgate agent schema |
Machine-readable command list |
Run rgate sync after every railway login — that is what makes an
account switchable later.
Project links move with the account
Railway keeps per-directory project links in the same file as the login. A
link created by one account is meaningless to another: it points at a project
the other account cannot see. So rgate switch carries each account's links
with it, saving the outgoing set and restoring the incoming one. Everything
else in config.json — editor, sandboxes, keys Railway adds later — is left
exactly as it was, and the file is backed up to config.json.bak first.
"refreshable" is normal, not broken
Railway access tokens last about an hour. The CLI renews them from the refresh
token silently, so a stored credential whose expiry has passed is usually
fine — rgate labels that refreshable and switches to it without
complaint. Only a past expiry with no refresh token is expired, and only
that needs railway login again (or rgate switch --force to write it
anyway).
| Status | Means |
|---|---|
valid |
More than 24h left |
expiring-soon |
Under 24h left — still works |
refreshable |
Access token lapsed, refresh token will renew it — still works |
expired |
Lapsed with no refresh token — needs railway login |
unknown |
No expiry recorded |
RAILWAY_API_TOKEN beats all of this
If RAILWAY_API_TOKEN or RAILWAY_TOKEN is set in your environment, the
Railway CLI uses it and ignores config.json entirely — so rgate switch
will appear to do nothing. rgate doctor checks for this.
MCP
rgate-mcp exposes the same operations to AI agents: railway_sync,
railway_list_accounts, railway_switch, railway_whoami, railway_doctor.
{ "mcpServers": { "rgate": { "command": "rgate-mcp" } } }
Where things live
| Railway CLI state | ~/.railway/config.json (override: RAILWAY_CLI_CONFIG_DIR) |
| Account store | ~/.config/railway-mcp/accounts.json, mode 0600 (override: RAILWAY_MCP_STORE) |
Tokens are stored in plain JSON readable only by your user — the same protection the Railway CLI gives its own config file, no more.
Development
uv venv && uv pip install -e ".[dev]"
.venv/bin/pytest
See CONTRACT.md for the behavioural spec the tests enforce.
MIT.
Metadata
Release files for railway-mcp 0.1.1
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| railway_mcp-0.1.1.tar.gz | 45.3 kB | Without provenance | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| railway_mcp-0.1.1-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 62.5 kB
Release files / railway_mcp-0.1.1.tar.gz
| Download URL | railway_mcp-0.1.1.tar.gz |
|---|---|
| Size | 45.3 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
bc59b1dad61b35faba2c799db5342bc6f2793d85974e97762e64f8fcd4cbf2dc
|
|
BLAKE2b-256 checksum How to use checksums |
cea647edd91a6e5bdc9d99d5c005a0f343bac638930c672f5f37e866e003e70e
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
uv/0.13.5 {"installer":{"name":"uv","version":"0.13.5","subcommand":["publish"]},"python":null,"implementation":{"name":null,"version":null},"distro":{"name":"macOS","version":null,"id":null,"libc":null},"system":{"name":null,"release":null},"cpu":null,"openssl_version":null,"setuptools_version":null,"rustc_version":null,"ci":null}
|
Release files / railway_mcp-0.1.1-py3-none-any.whl
| Download URL | railway_mcp-0.1.1-py3-none-any.whl |
|---|---|
| Size | 17.2 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
909c4eb36571d4238fe14b142dbf9292102114617de0d623ce24491f00d5776f
|
|
BLAKE2b-256 checksum How to use checksums |
faf4c79551af1e19abcfab2a41bbfba89e1ef1a9294c5bff9cc8c995adbf3af4
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
uv/0.13.5 {"installer":{"name":"uv","version":"0.13.5","subcommand":["publish"]},"python":null,"implementation":{"name":null,"version":null},"distro":{"name":"macOS","version":null,"id":null,"libc":null},"system":{"name":null,"release":null},"cpu":null,"openssl_version":null,"setuptools_version":null,"rustc_version":null,"ci":null}
|
Security for railway-mcp 0.1.1
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.