Railway’s October 21 security notice listed database credentials among the secrets that environment variables can hold, and its follow-up guides on October 22 explain why that matters more on some projects than others. If a Railway database has Public Access switched on, the company says, a copied password can be used from any computer on the internet until it is changed. This guide covers database password rotation for Railway’s PostgreSQL, MySQL, Redis and MongoDB templates, and how to check whether an old password was used.
Where it stands: Railway’s latest status update, timestamped 01:22 UTC on October 22, linked separate rotation guides for each of the four database engines and cautioned that they “may require redeployment of services which you will not be able to complete until Builds are available again.” That was still the newest entry when we checked at 01:49 UTC, which was 9:49 in the evening Eastern time on October 21. The overall picture is in our Railway security incident explainer.
Why a leaked database password is different on Railway
A stolen database password is only as dangerous as the database is reachable, and on Railway that comes down to one setting. Railway’s PostgreSQL guide says: “If Public Access is enabled, the credential is usable from anywhere on the internet through the TCP proxy until you rotate.” The MySQL, Redis and MongoDB guides carry the same warning.
Public Access is a networking setting on the database service. With it on, Railway’s TCP proxy gives the database an address outside the project, which is handy for connecting from a laptop or a reporting tool. With it off, the database is reachable only from services inside the same project over Railway’s private network. A password copied from a private database is harder for an outsider to use, though it should still be changed.
Railway’s notice was broad about what may have been exposed: “Environment variables may contain secrets such as API keys or database and registry credentials.” A connection string such as a DATABASE_URL usually carries the host, user name and password in one line.
Three checks before database password rotation
Railway’s guides ask users to look at three things before changing anything.
- Who uses the database. In the database’s Variables tab, see which services read its values through Railway reference variables. Those pick up a new password on their next deploy. Railway adds a warning about the rest: “Services with a pasted connection string don’t, so note them.”
- Whether it is public. Open the database’s Settings, then Networking. Railway’s advice: “Remove public access now if nothing outside the project needs it.”
- What lives outside Railway. Local machines, CI pipelines, dashboards and scheduled jobs on other hosts that use the public connection string will need the new value entered by hand.
Regenerate, and do not edit the password by hand
“Regenerate is the supported way to change a database password on Railway,” the guides say. It sits in the database service under the Database tab, then Config, next to the password field, and it changes the password inside the database and in Railway’s variables at the same time.
The guides warn against two shortcuts: typing a new value into the password variable, or changing the password with a command inside the database. “Each changes only one side and leaves the variable and the database out of sync.”
| Engine | Do not hand-edit | Stale-password error |
|---|---|---|
| PostgreSQL | POSTGRES_PASSWORD, PGPASSWORD | password authentication failed |
| MySQL | MYSQLPASSWORD, MYSQL_ROOT_PASSWORD | Access denied for user |
| Redis | REDISPASSWORD | NOAUTH or WRONGPASS |
| MongoDB | MONGOPASSWORD, MONGO_INITDB_ROOT_PASSWORD | Authentication failed |
The cost: dropped connections and a redeploy
Rotation is not free. For PostgreSQL, Railway says it “restarts the database to apply the new password, so every open session drops, including any an attacker had open.” The guide then adds, bluntly: “During an incident, that is the goal.” For Redis, Railway says to “Expect clients authenticated with the old password to fail on their next command,” and for MongoDB, “Expect new connections with the old password to fail from this point.”
Your own apps then need to catch up. “Regenerate redeploys only the database, so these services keep the old password until you do.” While builds are paused, that redeploy cannot happen, so a rotated database may be unreachable for its own apps until Railway restores builds.
Railway’s position on that trade-off is clear: “If you suspect a leak, cutting off the old credential matters more than the short outage while your services redeploy. Regenerate first.” Redis users running background jobs should also plan for a pause: “Queue workers that hold long-lived connections reconnect on redeploy. Expect a short gap in job processing.”
Do not lean on health checks to find a service you missed. The PostgreSQL guide notes: “It won’t flag a service you forgot to redeploy, because Railway only runs healthchecks at deploy time.” The table above lists the error each engine logs when a service is still using the old password.
Is anyone still connected?
The restart helps here. Railway explains: “The restart dropped every session from before the rotation, so a session you don’t recognize connected with the new password.” In other words, an unfamiliar connection after rotation means the new password has also leaked, perhaps through a pasted copy somewhere.
Each guide names the place to look. PostgreSQL users can query the pg_stat_activity view, MySQL users the process list, Redis users the CLIENT LIST command, and MongoDB users the current operations and session listings. Railway’s guides also show how to end a connection you do not recognize.
Looking for what the old password was used for
Changing the password stops new access. It says nothing about what happened before. Railway’s guides suggest these checks:
- Railway’s audit logs, which show who viewed or changed the database’s variables and when.
- The database’s own deploy logs, filtered for failed logins.
- Inside the database: unfamiliar roles or users, new extensions, and unexpected changes in row or document counts. For MySQL, Railway adds: “Inside MySQL, look for accounts you didn’t create and for widened privileges.”
- For Redis holding login sessions or tokens: “If sessions or tokens live in Redis, invalidate them.” Railway explains why: “Flush the session database or rotate the signing secret in your application, because an attacker could have read them.”
If data was changed, Railway’s guides say to keep the evidence before restoring from a backup. Other secrets in the same project need the same attention; our Railway secrets rotation checklist covers AI, cloud and payment keys, and a broader search for exposed credentials is explained in how to check if your application secrets were leaked.
One limit is worth knowing before reading too much into a quiet log. Railway’s PostgreSQL guide states: “PostgreSQL doesn’t log successful connections or client addresses by default.”
Frequently Asked Questions
How do I change my Railway database password after the breach?
For Railway’s PostgreSQL, MySQL, Redis and MongoDB templates, Railway’s guides say to open the database service, go to the Database tab, then Config, and click Regenerate next to the password. That changes the password inside the database and the service variables together. Then redeploy every service that uses the database.
Is my Railway database reachable from the internet?
Only if Public Access is turned on in the database service’s networking settings. Railway says that in that case a leaked credential is usable from anywhere through its TCP proxy until you rotate it. If nothing outside the project needs the database, Railway recommends removing public access.
Why are my services failing after database password rotation?
Containers on Railway read variables only when they start, and Regenerate restarts only the database. Services that use it keep the old password until they are redeployed. Railway said redeploys could not be completed while builds were paused.
Can I tell if someone used my leaked database password?
Partly. Railway’s guides suggest checking audit logs for who viewed variables, searching the database deploy logs for failed logins, listing current sessions after the restart, and looking inside the database for accounts, roles or data changes you did not make. PostgreSQL does not log successful connections by default, so a clean log is not proof of no access.
Sources
- Security Disclosure Recommendation: Rotate PostgreSQL Database Credentials — Railway (Mykal Machon), October 22, 2026
- Security Disclosure Recommendation: Rotate MySQL Database Credentials — Railway (Mykal Machon), October 22, 2026
- Security Disclosure Recommendation: Rotate Redis Database Credentials — Railway (Mykal Machon), October 22, 2026
- Security Disclosure Recommendation: Rotate MongoDB Database Credentials — Railway (Mykal Machon), October 22, 2026
- Railway Platform Outage — Railway status page, October 21-22, 2026 (live page, checked October 22, 01:49 UTC)
- Security Disclosure: Wednesday October 21st — Railway (Jacob Cooper), October 21, 2026
This article is news reporting and general security information based on the public sources listed above, as they stood on the dates shown. Incident details often change as investigations continue; check the affected company’s own status page and notices for the latest. Data Breach Radar is not affiliated with any company named here.