Hey!Have you modified the authentication-related variables since redeployment?

The Classic "Billing Suspension Strikes Again" ProblemMan, this is frustrating but unfortunately pretty common. I've seen this exact scenario play out multiple times - Railway does regenerate environment variables when services restart after billing suspension, but the actual MongoDB instance keeps the old password in its internal user database. It's like having a bouncer with an old guest list while you're standing there with new credentials.What Actually HappenedWhen your project hit the billing limit and got suspended, MongoDB gracefully shut down but preserved all its data (which is great!). However, when Railway brought everything back online, it regenerated new environment variables including MONGO_INITDB_ROOT_PASSWORD, MONGOPASSWORD, etc.The problem is MongoDB only uses MONGO_INITDB_ROOT_PASSWORD during the initial database initialization. Since your data volume already exists with the old password, the new environment variables are essentially useless decorations.The Solution PathHere's what you need to do, and fortunately there are a few approaches:Option 1: Check Your Railway Activity Log (Easiest) Head to your project dashboard → Activity tab and look for the environment variable changes that happened around the time of suspension. There should be a change that shows you the old password. Deploy MongoDB on Railway | Railway If you can spot the original MONGO_INITDB_ROOT_PASSWORD value, you can update your current variables to match it.Option 2: Reset MongoDB Password via Command Line Since the MongoDB container is healthy and running, you can exec into it and manually reset the root password:Go to your MongoDB service in RailwayClick the "View Logs" or use Railway CLI to exec into the containerRun these commands:### Connect to MongoDB without auth (locally within container)mongosh --authenticationDatabase admin### Switch to admin database and reset passworduse admindb.changeUserPassword("root", "your-new-password-here")Option 3: Temporary No-Auth Restart (Your Attempt Was Close) You were on the right track with --noauth, but you need to modify the start command properly. Instead of appending to the existing command, replace it entirely:mongod --bind_ip 0.0.0.0 --noauthOnce it's running without auth, connect and reset the password, then revert to the secure start command.Quick Fix for Right NowSince Brody asked if you modified auth variables, and you mentioned you changed MONGO_PUBLIC_URL and reverted it - try this immediate approach:Go to your Railway Activity log and find the exact MONGOPASSWORD value from before the suspensionUpdate your current MONGOPASSWORD and MONGO_INITDB_ROOT_PASSWORD to match that old valueRedeploy your application services (not the MongoDB service)The data is definitely safe since the volume is intact, it's just a matter of getting the credentials aligned again. This kind of thing always happens at the worst possible moment, but it's totally recoverable.Let me know if you need help with any of these steps!

Ah, classic. The logs are a massive pain when looking for an exact password value, it’s like finding a single needle in a haystack of terminal output.Since the log-diving didn't pan out, we need to move to the remaining two bulletproof options. We can't actually retrieve that old password, so the goal shifts to aligning the MongoDB's internal password with the new environment variables Railway has set for you.Here is the most reliable path forward, which involves securely resetting the password from inside the container.Next Steps: Resetting Credentials SecurelySince we can't get the old password, we need to force MongoDB to accept a new one. Given that your MongoDB container is marked as healthy (it’s running, just locked), the simplest method is to execute the password change directly within the running container.This bypasses the old data volume password mismatch and forces the database to accept new credentials.Option 1: The In-Container Password Reset (Recommended)This requires you to connect to the MongoDB instance locally, inside the container, where it usually runs without requiring authentication for the internal connection.1. Get Inside the Container:Go to your MongoDB Service in the Railway dashboard.Navigate to the Settings tab.Find the option for CLI or use the Railway CLI tool locally railway run bash). This will drop you into a terminal session inside the running MongoDB service container.2. Connect and Reset:Once inside the container, execute the mongosh client (or mongo depending on the image version) to connect. You usually need to specify the internal connection details, often just mongosh.Crucially, use the existing/new root credentials if the container requires some auth, or try connecting to the admin database directly:1. Connect to the local MongoDB instance using the mongosh client# Use the admin database contextmongosh --authenticationDatabase adminReset the Password: Assuming you can connect, switch to the admin database and force a new password for the root user (or the user specified by your existing MONGO_USER variable):use admin# Replace 'your-new-password-here' with the value from your current# MONGO_INITDB_ROOT_PASSWORD environment variable in the Railway dashboard.db.changeUserPassword("root", "your-new-password-here")quit()3. Confirm and Redeploy:Once the command is successful, the internal MongoDB user database will now match your new Railway Environment Variables.Redeploy all services (your application, worker, etc.) that connect to MongoDB to ensure they pick up the correct, new connection string.This is tedious, but it’s the cleanest way to fix the credential mismatch without needing to wipe data or poke holes in the MongoDB configuration. Give that a shot and let me know if you run into any permission issues once you're inside the container.

Howdy!Are you able to copy that public mongo URL and connect to it with an external database viewer?Something like compass.Want to nail down if this is a mongo password mismatch or some other bug.

I tried connecting externally with the exact MONGO_URL through mongosh on my machine:nginxand it still returns MongoServerError: Authentication failed. So a GUI like Compass would hit the same password mismatch.Everything points to the data volume still holding the original root password from before the suspension. I can’t recover that value and I can’t reach the running mongod to change it myself, so I’m stuck until the password is rotated on your end.

I tried connecting externally with the exact MONGO_URL through mongosh on my machine:nginxand it still returns MongoServerError: Authentication failed. So a GUI like Compass would hit the same password mismatch.Everything points to the data volume still holding the original root password from before the suspension. I can’t recover that value and I can’t reach the running mongod to change it myself, so I’m stuck until the password is rotated on your end.

I'm afraid the password cannot be rotated by Railway... can you look for history of where you saved it on your machine perhaps?

Also would love to make sure you know, that key is extremely private and should not be shared publicly. I can delete that message if you would like.

Here's what you're going to do.Go into the MongoDB service and change the start command to:mongod --ipv6 --bind_ip ::,0.0.0.0 --noauth --setParameter diagnosticDataCollectionEnabled=false --setParameter enableLocalhostAuthBypass=0Right click the service and copy the SSH command, paste that into your terminal.Type the following commands:mongoshuse admindb.changeUserPassword("mongo", passwordPrompt())Change MONGO_INITDB_ROOT_PASSWORD to be this new password.Exit this window and change your start command back to:mongod --ipv6 --bind_ip ::,0.0.0.0 --setParameter diagnosticDataCollectionEnabled=false