--- title: "Security Disclosure Recommendation: Redeploy Buckets and Reconnect GitHub After the Credential Reset" description: "Learn how to Security Disclosure Recommendation: Redeploy Buckets and Reconnect GitHub After the Credential Reset" date: 2026-10-22T00:45:56.133Z authors: ["Mykal Machon"] category: "Engineering" url: https://blog.railway.com/p/security-disclosure-recommendation-redeploy-buckets-and-reconnect-github-after-the-credential-reset --- # Security Disclosure Recommendation: Redeploy Buckets and Reconnect GitHub After the Credential Reset > This guide is part of Railway's response [to the security disclosure published on October 21, 2026](https://blog.railway.com/p/security-disclosure-wednesday-october-21st). *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](https://docs.railway.com/enterprise/audit-logs), 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](https://railway.com/workspace/audit-logs) page. [Retention depends on your plan](https://docs.railway.com/enterprise/audit-logs#audit-log-retention), 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](https://docs.railway.com/variables#referencing-another-services-variable), 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](https://docs.railway.com/storage-buckets#variable-references). 3. Redeploy each of those services. Open the service, click the latest deployment's menu, and select **Redeploy**, or use the CLI. ```Shell 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](https://docs.railway.com/deployments/staged-changes). 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. ```Shell 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`](https://docs.railway.com/cli/bucket#show-or-reset-credentials). ## 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](https://railway.com/account) 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](https://github.com/apps/railway-app/installations/new), 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](https://docs.railway.com/deployments/github-autodeploys#enable-automatic-deployments). 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](https://docs.railway.com/deployments/github-autodeploys#cant-enable-autodeploy). ### 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](https://github.com/settings/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](https://docs.railway.com/builds/private-registries#github-container-registry-ghcr). 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](https://docs.railway.com/enterprise/audit-logs) 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 . --- Open this post in a browser: https://blog.railway.com/p/security-disclosure-recommendation-redeploy-buckets-and-reconnect-github-after-the-credential-reset