Security Disclosure Recommendation: Redeploy Buckets and Reconnect GitHub After the Credential Reset

Author: Mykal Machon

This guide is part of Railway's response to the security disclosure published on October 21, 2026.

If your workspace uses storage buckets or GitHub, Railway reset their credentials. Here's how that appears in your audit log, and how to redeploy services with the new bucket credentials and reconnect GitHub.

If your workspace has storage buckets or a GitHub connection, Railway reset those credentials on your behalf as part of the incident response: the S3 credentials for every storage bucket, and the GitHub tokens Railway held for your account and services. The old values no longer work. This guide explains what changed, how it appears in your audit log, and what to do to get your services running on the new credentials.

Railway performed the reset rather than asking you to, so the exposed credentials stopped working as early as possible. The trade-off is that services that read those credentials need a redeploy, and you need to reconnect GitHub yourself.

## What Railway reset and who did it

Faraz Patankar from Railway's engineering team performed the resets. In your workspace audit log, these events show the actor type Railway Staff with his name, so you can tell them apart from changes made by your own team.

Two credential types were reset:

• Bucket credentials: the ACCESS_KEY_ID and SECRET_ACCESS_KEY for every bucket in every environment were invalidated and regenerated. The bucket name, endpoint, and objects are unchanged.
• GitHub tokens: the tokens Railway held for your GitHub account connection were invalidated, and the GitHub access tokens stored as registry credentials on your services were removed from Railway. Those registry tokens still work on GitHub until you revoke them. Railway can't create new GitHub tokens for you, so you need to reconnect yourself.

Workspace admins can confirm the timing on the Audit Logs page. Retention depends on your plan, so export the relevant entries if you need them for your own incident record.

## Redeploy your services with new bucket credentials

A bucket's credentials reach your services through reference variables, and containers read variables only at startup. The bucket already has its new credentials. Your services pick them up on their next deploy.

1. Open each bucket and click Credentials to see the new ACCESS_KEY_ID. Every environment has its own bucket instance with its own credentials, so check each environment you use.
2. Find the services that use the bucket. Open each service's Variables tab and look for references such as ${{ my-bucket.SECRET_ACCESS_KEY }}, or the variables Railway inserted when you used a library preset (for example AWS_SECRET_ACCESS_KEY). See variable references.
3. Redeploy each of those services. Open the service, click the latest deployment's menu, and select Redeploy, or use the CLI. railway redeploy --service uploads-api
4. If a service has the bucket's old key pasted as a plain value rather than a reference, replace it with a reference so the next rotation needs no manual edit, then deploy the staged change.
5. Update anything outside Railway that used the old credentials, such as local development, CI jobs, or an S3 file explorer. Fetch the new values from the Credentials tab or the CLI. railway bucket credentials --bucket my-bucket

Confirm each redeployed service can list or write objects. If a service still logs InvalidAccessKeyId or SignatureDoesNotMatch, it's running the old deployment or holds a pasted value.

If you want to rotate again yourself at any point, railway bucket credentials --reset invalidates the current credentials and generates new ones. See railway bucket.

## Reconnect to GitHub

If you deploy from GitHub or pull private images from ghcr.io, those stop until you reconnect, because Railway reset the GitHub tokens it stored. Two connections may be affected, and a project can use either or both.

### Reconnect your GitHub account

Your account connection is what lets Railway see your repositories and deploy on push. Autodeploy works only when at least one project member has a connected GitHub account with contributor access to the repository.

1. Open Account Settings and connect your GitHub account again when prompted.
2. Confirm the Railway GitHub App has access to the repositories you deploy. Review the installation at github.com/apps/railway-app, and accept any pending permission updates.
3. For each service deployed from a repository, open the service's Settings, find Source, and confirm the repository and branch are still connected. If the service shows as disconnected, click Disconnect and then Connect Repo to select the repository again.
4. Confirm autodeploy is enabled under Settings. If it was turned off during the reset, click Enable. See Controlling GitHub autodeploys.
5. Push a commit or open the Command Palette and select Deploy Latest Commit to confirm deploys work.

If autodeploy still can't be enabled, work through the troubleshooting steps.

### Replace GitHub registry tokens

Services that pull a private image from GitHub Container Registry (ghcr.io) store a GitHub personal access token as a registry credential. Those tokens were removed from Railway, and you must also revoke them on GitHub, because the token itself may have been exposed.

1. On GitHub, open Personal access tokens, delete the old token, and create a new one with the read:packages scope.
2. On Railway, open the service's Settings, find Source, and locate Registry Credentials.
3. Enter the new token in the GitHub Access Token field and save. Railway sets the username for GHCR automatically. See Private registries.
4. Redeploy the service so the next image pull uses the new token.

Registry credentials are per service, so repeat this for every service that pulls from ghcr.io. Private registry credentials require the Pro plan.

## Check for misuse

The reset stops future use of the old credentials. These checks show whether they were used in the meantime.

• Open each bucket and click Files to look for objects you didn't upload, or deletions you didn't make. Buckets don't have automatic backups, so note anything missing now
• Review the audit log for variable reads, registry credential changes, and deployments in the exposure window that weren't made by your team or by Railway Staff

If you have any other questions, contact Railway support at [email protected].