a month ago
My PostgreSQL service (ua-hub-db) lost all data after I changed the POSTGRES_PASSWORD environment variable today (April 21, 2026). The container appears to have been reinitialized. I'm on the Hobby plan with no backups. Can you check if a volume snapshot exists for recovery?
Project: [твій project ID з Railway dashboard]
Service: ua-hub-db
Pinned Solution
a month ago
I would suggest you switch the variable back to its original password. If you don't have access to the original password, do the following:
1. Disable all public networking on the database if you have any, as the following steps will disable user authentication
2. SSH into your database service (right click your service and select Copy SSH Command)
3. Run this command: sed -i 's/host all all all scram-sha-256/host all all ::\/0 trust/' /var/lib/postgresql/data/pgdata/pg_hba.conf (This will bypass user authentication)
4. Redeploy your database
5. SSH again, and run the command psql
6. Run ALTER USER postgres with password '<PASSWORD>'; where <PASSWORD> is the value of the variable PGPASSWORD in your Railway dashboard
7. Type exit
8. Run sed -i 's/host all all ::\/0 trust/host all all all scram-sha-256/' /var/lib/postgresql/data/pgdata/pg_hba.conf (This will re-enable user authentication)
9. Redeploy your database
3 Replies
Status changed to Open Railway • about 1 month ago
a month ago
You should not be changing the variables manually. If you need to rotate the password, you should do so through the Config panel of your database service in your dashboard.
a month ago
I would suggest you switch the variable back to its original password. If you don't have access to the original password, do the following:
1. Disable all public networking on the database if you have any, as the following steps will disable user authentication
2. SSH into your database service (right click your service and select Copy SSH Command)
3. Run this command: sed -i 's/host all all all scram-sha-256/host all all ::\/0 trust/' /var/lib/postgresql/data/pgdata/pg_hba.conf (This will bypass user authentication)
4. Redeploy your database
5. SSH again, and run the command psql
6. Run ALTER USER postgres with password '<PASSWORD>'; where <PASSWORD> is the value of the variable PGPASSWORD in your Railway dashboard
7. Type exit
8. Run sed -i 's/host all all ::\/0 trust/host all all all scram-sha-256/' /var/lib/postgresql/data/pgdata/pg_hba.conf (This will re-enable user authentication)
9. Redeploy your database
a month ago
In many Docker-based PostgreSQL setups, the initialization scripts (found in /docker-entrypoint-initdb.d/) only run when the data directory is empty. However, some configurations are set to treat a change in core credentials as a signal to "wipe and reset" to ensure the internal database state matches the environment variables.
• Container Lifecycle: When you changed the variable, Railway redeployed the service. If the volume wasn't correctly mapped or if the image logic perceived the password change as a requirement for a fresh start, it created a brand-new data directory.
• Variable Sync: As the moderator noted, changing credentials manually through environment variables is risky. Using the Config panel is the intended way to rotate secrets without interrupting the underlying storage.
Recovery Options
Since you are on the Hobby plan, there are specific limitations regarding how data is preserved:
• Volume Snapshots: Railway does not automatically take volume snapshots for users on the Hobby plan. This feature is typically reserved for Pro or Enterprise tiers. Unless you manually triggered a backup or have an external sync, a snapshot likely does not exist on their end.
• Ephemeral vs. Persistent Storage: If the service ua-hub-db was not attached to a Persistent Volume, the data existed only within the container's writable layer. Once the container was recreated due to the variable change, that layer was deleted.
Next Steps
Check the Volumes Tab: Go to your service dashboard and check the Volumes tab. If there is a volume attached, see if it shows multiple mounts or if the current usage is significantly lower than before.
Check your deployment logs to see if there was an error during the migration or if the logs explicitly state initdb: creating directory /var/lib/postgresql/data..., which confirms a fresh start.
Status changed to Solved 0x5b62656e5d • 4 days ago