a month ago
Description: Self-hosted WhatsApp REST API with Postgres + Redis. Hardened defaults.
Category: Other
URL: https://railway.com/deploy/evolution-api-whatsapp-rest-api
2 Replies
a month ago
Evolution APi keep on showing error anytime I'm making a settings change and also if an instance get deleted it says error but the instance is still there and it will say instance doesn't exit if you try deleting it again, if u get number connected messages won't be reaching Ur WhatsApp app but just hang there in evolution instance chat. What is wrong please. This is spoiling work flow
a day ago
Sorry you hit this, and thanks for the detail those three symptoms together (settings changes erroring, a deleted instance lingering then reporting "instance does not exist" on the second try, and a connected number where messages just hang in the Evolution chat instead of reaching WhatsApp) almost always trace back to the Postgres and Redis state getting out of sync, plus the WhatsApp session not persisting. A few things to check:
-
Make sure both stores are actually wired. In the Evolution service Variables you want DATABASE_ENABLED=true with DATABASE_CONNECTION_URI pointing at your Postgres service, and CACHE_REDIS_ENABLED=true with CACHE_REDIS_URI pointing at your Redis se use the private references (e.g. ${{Postgres.DATABASE_URL}} and ${{Redis.REDIS_URL}}), not localhost. If Redis is enabled but unreachable, deletes only half-complete: the DB row is removed but the cached instance key stays, which is exactly the "still there / doesn't exist" loop you're describing.
-
Clear the ghost instance. Restart the Evolution service once (Deployments -> Restart). That flushes the instance cache and the stale instance should disappear and be re-creatable. If one specific instance is still stuck, its Redis key is wedged deleting that key (or flushing Redis if it's a throwaway setup) clears it.
-
Messages hanging = the WhatsApp (Baileys) connection dropped even though it shows connected. Delete and re-add that instance and re-scan the QR to re-establish the socket. To stop it recurring after every redeploy, confirm a volume is attached so the auth/session state survives restarts, and if you use webhooks make sure the webhook URL is set and reachable.
If you can share the Evolution API image tag you're on, whether Redis and Postgres are both attached, and a snippet of the exact error from the Evolution service logs when you change a setting, I can pinpoint it from there.