a month ago
Hi everyone,
I'm currently testing n8n on Railway (Hobby plan) as a beginner. I noticed that my Google credentials node (Google Doc, Google Sheets, etc.) keeps disconnecting multiple times a day. I have to reconnect and sign in with my Gmail account again, even though I haven't redeployed or restarted my project at all. This happens even when I'm not actively running any workflows—just editing or testing nodes.
Is this expected behavior for the Hobby plan on Railway?
Do I need to upgrade to the Pro plan to keep my credentials persistent, or is there something I might be missing in the setup?
At this stage, I'm just learning and building basic workflows (nothing running in production yet), so I'm a bit confused why the Google credentials require frequent re-authentication.
Any advice or explanation would be much appreciated.
Thank you!
Thananit
5 Replies
24 days ago
Hey Thananit,
I ran into the exact same behavior on Railway’s Hobby tier, and it wasn’t a bug in n8n at all but simply the way Railway handles storage combined with Google’s OAuth policies.
First off, Railway Hobby containers are inherently stateless. By default you get 10 GB of “ephemeral” storage inside the container, and anytime Railway sleeps or restarts your service (which it does automatically after a period of inactivity), that ephemeral filesystem is wiped. Since n8n uses a local SQLite file (in ~/.n8n) to store both your workflows and your OAuth credentials, every container restart nukes that file and forces you to re‑authenticate.
You don’t need to move to the Pro plan just to keep credentials persistent—you just need to give n8n a persistent volume to write to. On Hobby you still get 5 GB of volume storage; if you create and mount that volume at /home/node/.n8n, then your SQLite database (and all your Google credentials) will survive restarts and “sleep”/“wake” cycles. An alternative is to spin up Railway’s managed Postgres plugin and point n8n at it (via DB_TYPE=postgresdb and the usual Postgres env vars), so your data lives in a proper database rather than inside a container filesystem.
Even with persistent storage in place, you may still see a “disconnect” roughly every week if your Google OAuth app is left in Testing mode. Google’s policy is that refresh tokens issued while the consent screen is in Testing expire after 7 days, so n8n will lose access and prompt you to reconnect. The fix here is to go into the Google Cloud Console under APIs & Services → OAuth consent screen, click Publish App (moving to Production), and ensure your OAuth client is configured for offline access with the prompt=consent flag. Once you’ve done that and re‑authenticated in n8n, you’ll get a long‑lived refresh token that won’t drop out every week.
In short:
Add a Railway Volume (or switch to Postgres) so
~/.n8nisn’t lost on restarts.Publish your Google OAuth app to Production to avoid the 7‑day refresh‑token expiry.
With those two changes in place, your Google nodes will stay connected indefinitely without needing a Pro plan upgrade.
mycodej
Hey Thananit,I ran into the exact same behavior on Railway’s Hobby tier, and it wasn’t a bug in n8n at all but simply the way Railway handles storage combined with Google’s OAuth policies.First off, Railway Hobby containers are inherently stateless. By default you get 10 GB of “ephemeral” storage inside the container, and anytime Railway sleeps or restarts your service (which it does automatically after a period of inactivity), that ephemeral filesystem is wiped. Since n8n uses a local SQLite file (in ~/.n8n) to store both your workflows and your OAuth credentials, every container restart nukes that file and forces you to re‑authenticate.You don’t need to move to the Pro plan just to keep credentials persistent—you just need to give n8n a persistent volume to write to. On Hobby you still get 5 GB of volume storage; if you create and mount that volume at /home/node/.n8n, then your SQLite database (and all your Google credentials) will survive restarts and “sleep”/“wake” cycles. An alternative is to spin up Railway’s managed Postgres plugin and point n8n at it (via DB_TYPE=postgresdb and the usual Postgres env vars), so your data lives in a proper database rather than inside a container filesystem.Even with persistent storage in place, you may still see a “disconnect” roughly every week if your Google OAuth app is left in Testing mode. Google’s policy is that refresh tokens issued while the consent screen is in Testing expire after 7 days, so n8n will lose access and prompt you to reconnect. The fix here is to go into the Google Cloud Console under APIs & Services → OAuth consent screen, click Publish App (moving to Production), and ensure your OAuth client is configured for offline access with the prompt=consent flag. Once you’ve done that and re‑authenticated in n8n, you’ll get a long‑lived refresh token that won’t drop out every week.In short:Add a Railway Volume (or switch to Postgres) so ~/.n8n isn’t lost on restarts.Publish your Google OAuth app to Production to avoid the 7‑day refresh‑token expiry.With those two changes in place, your Google nodes will stay connected indefinitely without needing a Pro plan upgrade.
24 days ago
Thank you so much for the detailed explanation and helpful advice! I’ll definitely try your suggestions and see how it goes. Really appreciate you taking the time to share this.
24 days ago
You're very welcome, Thananit—glad I could help!
Feel free to reach out if you run into any issues while setting things up.
mycodej
Hey Thananit,I ran into the exact same behavior on Railway’s Hobby tier, and it wasn’t a bug in n8n at all but simply the way Railway handles storage combined with Google’s OAuth policies.First off, Railway Hobby containers are inherently stateless. By default you get 10 GB of “ephemeral” storage inside the container, and anytime Railway sleeps or restarts your service (which it does automatically after a period of inactivity), that ephemeral filesystem is wiped. Since n8n uses a local SQLite file (in ~/.n8n) to store both your workflows and your OAuth credentials, every container restart nukes that file and forces you to re‑authenticate.You don’t need to move to the Pro plan just to keep credentials persistent—you just need to give n8n a persistent volume to write to. On Hobby you still get 5 GB of volume storage; if you create and mount that volume at /home/node/.n8n, then your SQLite database (and all your Google credentials) will survive restarts and “sleep”/“wake” cycles. An alternative is to spin up Railway’s managed Postgres plugin and point n8n at it (via DB_TYPE=postgresdb and the usual Postgres env vars), so your data lives in a proper database rather than inside a container filesystem.Even with persistent storage in place, you may still see a “disconnect” roughly every week if your Google OAuth app is left in Testing mode. Google’s policy is that refresh tokens issued while the consent screen is in Testing expire after 7 days, so n8n will lose access and prompt you to reconnect. The fix here is to go into the Google Cloud Console under APIs & Services → OAuth consent screen, click Publish App (moving to Production), and ensure your OAuth client is configured for offline access with the prompt=consent flag. Once you’ve done that and re‑authenticated in n8n, you’ll get a long‑lived refresh token that won’t drop out every week.In short:Add a Railway Volume (or switch to Postgres) so ~/.n8n isn’t lost on restarts.Publish your Google OAuth app to Production to avoid the 7‑day refresh‑token expiry.With those two changes in place, your Google nodes will stay connected indefinitely without needing a Pro plan upgrade.
24 days ago
Thank you very much for the help here, but I'd like to clarify a few things.
OP has already been using Postgres with N8N, you likely deployed a template that was incorrectly setup, and that template you used does not reflect what OP has deployed, they have this deployed -
https://railway.com/deploy/n8n-with-workers
We will never sleep an application running on the Hobby plan unless the user has it enabled (they don't).
We will however redeploy an application sometimes, but that would only be for security or performance upgrades on the underlying host, see here for more information -
https://docs.railway.com/reference/deployments#railway-initiated-deployments
Thanks!
24 days ago
Thanks for the clarification, Brody—and sorry for the earlier assumptions on my part.
Given that OP is using the n8n-with-workers setup and Postgres, and that the service isn’t sleeping or restarting manually, the frequent Google disconnects are definitely unusual. While Google does limit refresh tokens in Testing mode (they expire after 7 days), that wouldn’t explain having to reconnect multiple times per day.
At this point, I’m honestly not sure what exactly is causing the credentials to drop so frequently. It might be something specific to how tokens are stored or refreshed in this deployment, or possibly a misconfiguration somewhere in the auth flow.
