I forgot to mention I have the n8n installation that connects with a PostgreSQL database.

Hmm, that’s odd. Can you share a screenshot of your config?

Is this the first time it happened? What version were you on and what’s the version you are now?

It’s always safer to update to the latest version and not the next/beta version.

I'm at my technical limit using the basic features of Railway :). So happy to provide a screenshot of my config if you let me know exactly where that is....

Where you have the worker, redid, Postgres etc.

Also the other questions

Is the attached screenshot what you mean?

To answer your other questions:

It happens every time I redeploy n8n on Railway to update it.

Currently on version 1.93.0

Oh it must be the template you’re using. It has no redis and no worker.

Check this template here: https://railway.com/deploy/r2SNX_

And test deploying it and creating a credential, then updating to a newer version to see if they keep intact.

When deploying n8n on Railway and updating it to a new version, it’s common to experience the loss of credentials especially OAuth-based connections like Google or LinkedIn. This happens because n8n encrypts credentials using an internal key, and if that encryption key changes or isn’t explicitly set, the new instance won’t be able to decrypt previously stored credentials.

To prevent this issue, you should always define the N8N_ENCRYPTION_KEY environment variable in your Railway project settings. This key should be a randomly generated string, and it must remain the same across all redeploys and updates. By setting this once and keeping it consistent, you ensure that all encrypted credentials can still be read by n8n after an update.

Equally important is ensuring your PostgreSQL database is persistent. Since you're using a PostgreSQL instance, make sure that your DATABASE_URL environment variable points to a Railway-managed or external database that is not recreated or reset during redeploys. If the database is wiped or a new one is connected without restoring previous data, n8n won’t be able to find or decrypt your credentials—even with the correct encryption key.

When updating n8n, simply redeploy the service using the same N8N_ENCRYPTION_KEY and connected DATABASE_URL. Avoid resetting the environment or database unless necessary. This ensures your credentials and workflows remain intact and usable across updates.

If you’ve already redeployed without these protections and lost your credentials, unfortunately, you’ll need to re-authorize each connection manually. After doing that, make sure to apply the encryption key and persist your database to avoid this in the future.

In summary, set and persist your N8N_ENCRYPTION_KEY, use a stable and persistent PostgreSQL connection, and redeploy carefully without resetting your environment. This approach ensures your credentials remain safe and your n8n workflows continue to operate smoothly through version upgrades.

Thanks. I believe that has worked as I added N8N_ENCRYPTION_KEY and DATABASE_URL, redeployed, and I still had working credentials.