Can you provide more info? (eg, logs)

You reached the start of the range

Jul 27, 2026, 12:57 PM

Starting Container

npm warn config production Use --omit=dev instead.

@workspace/whatsapp-linked-device@0.1.0 start

node dist/index.js

[service] WhatsApp Linked Device Service starting up

[service] CRM base URL: https://dapsy-motors-crm.replit.app/api

[service] HTTP port: 3000

[service] Listening on 0.0.0.0:3000

I'm not seeing any errors here. Can you describe how the service is "failing"?

Hey so what it seems like your saying is that you have a container running a whatsapp service that works locally but fails on being deployed via a HTTP server through a domain or maybe QR code. We will need more information scope into your projects issue.

There are some inherent issues when migrating from a local execution to a railway service but a easy thing to look out for is volume mapping in your container.

Whatapps Auth State Wipe

In this case I'm thinking it's the Whatsapp auth state being wiped when you deploy the railways.

Railway gives you a fresh filesystem on every deploy and every restart. Both common linked-device libraries persist credentials to disk by default — Baileys writes wherever you point useMultiFileAuthState (often a relative auth_info/ folder), and whatsapp-web.js's LocalAuth writes to .wwebjs_auth/. Locally that folder survives between restarts, but doesn't on Railway. If this is the case you should receive unauthenticated errors, and device unlinks.

If this is what your case is just let me know and I'll post the rest of the fix :)

Best regards, and happy building

Running Whatsapp Bot is not allowed unless you're using Official Meta API

https://railway.com/legal/acceptable-use

Hey, looking at your logs the service is actually starting fine - it binds to port 3000 with no errors. The "keeps failing" part is most likely happening after that.

A couple of things to check:

1. WhatsApp session files aren't persisting Since it's a linked device setup, the session auth files (like auth_info_baileys/ or similar) get wiped every time Railway restarts your container. The service boots up, can't find the saved session, tries to re-authenticate, and just hangs or crashes. You need to add a Volume in Railway and point it to wherever your code saves the session folder. Go to your service → Settings → Volumes.

2. The CRM URL might be unreachable from Railway's network Your service is calling out to https://dapsy-motors-crm.replit.app/api - Replit apps spin down when idle. If Railway boots up and hits that URL while Replit is cold-starting, the connection can time out and take the whole service down with it. Worth adding a retry/timeout handler there.

My bet is it's #1 though. Add a volume, remount your session directory to it, redeploy and scan your QR code once more. Should stay stable after that.

Very interesting, thanks for posting that. Is there a error that shows up when a Whatsapp Bot is deployed? I can imagine that is kind of hard to enforce 🤔