Hi Railway team, After uninstalling/reinstalling the Railway GitHub App, ALL of my services that connect to GitHub now show "Bad credentials" and cannot auto-deploy. This is account-wide, not one service. I believe the reinstall left my account pointing at a stale/orphaned GitHub App installation_id that the dashboard can't fix. Please reset the GitHub integration state for my account and re-link it to the current installation. — Account / identifiers — Railway login email: GitHub account: btclending (personal account, not an org) Affected: ALL GitHub-connected services on this account Project ID (one example): Service (example): WingmanPro Backend (Service ID: ) Environment: (production) Repository (example): btclending/wmp-app-fork (private), branch main, root /backend — Timeline — 1. I repointed one service's Source Repo from btclending/wmp-api-fork to btclending/wmp-app-fork (two repos merged into a monorepo). 2. That service showed "Auto deploy unavailable" → tooltip "No project member has access to this GitHub repository," even though the App had All-repositories access and my other services deployed fine. 3. On support-doc guidance I uninstalled + reinstalled the Railway GitHub App and revoked/re-authorized OAuth. Now EVERY GitHub-connected service shows "Bad credentials." — What I've already verified / tried — • Railway GitHub App reinstalled on btclending with All-repositories access and full read/write perms; no pending permission updates. • Revoked Railway under GitHub Authorized OAuth/GitHub Apps and re-authorized. • Disconnected/reconnected repos, re-set source/branch/root, waited for cache. • I have ADMIN on the repos; they are private. • Still account-wide "Bad credentials." My read: the reinstall created a new installation_id but my account record still references the old one, so GitHub calls 401 across all services. Please reset/re-link my account's GitHub integration. Happy to provide any additional IDs privately. Thanks — this is affecting all my production services' ability to deploy.

GitHub showing bad credentials - Railway Central Station

GitHub showing bad credentials

btclending

HOBBYOP

3 months ago

Hi Railway team,

After uninstalling/reinstalling the Railway GitHub App, ALL of my services

that connect to GitHub now show "Bad credentials" and cannot auto-deploy.

This is account-wide, not one service. I believe the reinstall left my

account pointing at a stale/orphaned GitHub App installation_id that the

dashboard can't fix. Please reset the GitHub integration state for my

account and re-link it to the current installation.

— Account / identifiers —

Railway login email:

GitHub account: btclending (personal account, not an org)

Affected: ALL GitHub-connected services on this account

Project ID (one example): <PROJECT_ID>

Service (example): WingmanPro Backend (Service ID: <SERVICE_ID>)

Environment: <ENVIRONMENT_ID> (production)

Repository (example): btclending/wmp-app-fork (private), branch main, root /backend

— Timeline —

I repointed one service's Source Repo from btclending/wmp-api-fork to

btclending/wmp-app-fork (two repos merged into a monorepo).
That service showed "Auto deploy unavailable" → tooltip

"No project member has access to this GitHub repository," even though the

App had All-repositories access and my other services deployed fine.
On support-doc guidance I uninstalled + reinstalled the Railway GitHub App

and revoked/re-authorized OAuth. Now EVERY GitHub-connected service shows

"Bad credentials."

— What I've already verified / tried —

• Railway GitHub App reinstalled on btclending with All-repositories access

and full read/write perms; no pending permission updates.

• Revoked Railway under GitHub Authorized OAuth/GitHub Apps and re-authorized.

• Disconnected/reconnected repos, re-set source/branch/root, waited for cache.

• I have ADMIN on the repos; they are private.

• Still account-wide "Bad credentials."

My read: the reinstall created a new installation_id but my account record

still references the old one, so GitHub calls 401 across all services.

Please reset/re-link my account's GitHub integration. Happy to provide any

additional IDs privately.

Thanks — this is affecting all my production services' ability to deploy.

$10 Bounty

3 Replies

Status changed to Awaiting Railway Response Railway • 3 months ago

mykal

EMPLOYEE

3 months ago

Hey! just took a look and everything seems solid from our side?

Are you still seeing this issue?

Status changed to Awaiting User Response Railway • 3 months ago

btclending

HOBBYOP

3 months ago

hey there! Thank you for getting back to me. It is connected but for some reason auto-deploy does not work for this repo only. The other repos work for autodeploy but not this one. Any ideas? I gave Railway all permissions for all repos.

Status changed to Awaiting Railway Response Railway • 3 months ago

Railway

BOT

3 months ago

This thread has been opened as a bounty so the community can help solve it.

Status changed to Open Railway • 3 months ago

ayalaa12

FREETop 5% Contributor

13 days ago

Your follow-up changes the diagnosis: because the repository is connected and your other repositories still autodeploy, this is no longer an account-wide stale GitHub installation. It is now isolated to this service's trigger configuration or to delivery of the push event for btclending/wmp-app-fork.

I would separate those two paths in this order:

In the affected service, run Deploy Latest Commit from the command palette. If it builds the current main SHA, Railway can read the private repository and the source credentials are healthy; the remaining fault is only autodeploy filtering/webhook ingestion. Do not use Redeploy, because that rebuilds the existing deployment rather than proving Railway can fetch the latest commit.
Open deployment history and enable Show Skipped. Check whether the missing push appears as skipped. Because this service moved from a standalone repository into /backend of a monorepo, inspect Watch Paths before changing the GitHub App again. Railway evaluates watch patterns from repository root even when Root Directory is /backend, so the matching pattern is /backend/** (or clear Watch Paths for one controlled test). An old pattern from wmp-api-fork can silently skip every commit in the new layout.
Confirm the service's trigger branch is main, Root Directory is /backend, and autodeploy is enabled. Apply any staged configuration change, then push one real commit that changes a file under /backend; an empty commit is not a valid test when Watch Paths are configured.
If the push produces no deployment or skipped-deployment entry at all, refresh Railway's repository cache with Add -> GitHub Repository -> Refresh, then disconnect and reconnect only this service's source to btclending/wmp-app-fork / main. Preserve the last healthy deployment and do not uninstall the account-wide GitHub App again. The current CLI exposes the same narrow operation with railway service source disconnect followed by railway service source connect --repo btclending/wmp-app-fork --branch main --service <service> if the dashboard source selector is stale.
Repeat Deploy Latest Commit, then make one new /backend change. If manual latest-commit deployment succeeds but the push still creates no event, send Railway support the project/service/environment IDs, missing commit SHA and its UTC push time. That is the exact evidence Railway's current troubleshooting guide requests and lets staff trace the repository webhook without another destructive reinstall.

The key discriminator is simple: manual latest-commit works + skipped entry exists means branch/watch-path configuration; manual latest-commit works + no entry exists means the push event is not reaching that service; manual latest-commit cannot read the SHA means source authorization is still wrong.

Official references:

Welcome!