Hey guys using a docker postgresql n8n 2.10.4 , and workflows inside n8n is not saving changes (Error Workflow → need to change the credentials since the old ones are not working anymore) . I get the “Changes saved to the worklfow” message and I am also able to publish the new version, but after tabbing out of the workflow it still says “changed 2 weeks ago” and the changes are not saved.
Any ideas what might that be ?
@codemc7
my first step would be to update to the latest n8n version and retest, and if it still happens, please share the browser Network/Console output when saving plus the server logs so we can see whether the workflow update request is failing at the API layer.
@codemc7 your compose has redis in there, if you’re running EXECUTIONS_MODE=queue the workers cache workflow definitions from redis and won’t pick up saves from the main instance until they re-fetch. restart your worker containers after saving or run docker exec <redis-container> redis-cli FLUSHDB to clear the stale cache, thats why it snaps back to “changed 2 weeks ago.”
We managed to resolve the issue by rebuilding the nodes within the same workflow. It appears there was a bug with one of the nodes, but everything is working correctly now.
“Saved successfully” message but the credentials don’t actually persist = classic N8N_ENCRYPTION_KEY mismatch on docker self-host. Three fast checks:
Confirm the key is set on the container, not just the host shell. docker exec <n8n> env | grep N8N_ENCRYPTION_KEY — if it’s empty or defaulted, every save encrypts with an ephemeral key that disappears on restart.
Is the postgres volume mounted and persistent? docker inspect <n8n> → check if the postgres data dir is a named volume vs. a bind mount that’s being clobbered.
Does n8n 2.10.4 logs on save mention “unable to decrypt existing credential”? If so, the key changed at some point and old rows are now unreadable — saving “works” but the ORM rolls back because the encryption handshake partially fails.
If the encryption key turns out to be the root cause, that’s the moment a lot of self-host teams consider pulling credentials out of n8n entirely — the gateway pattern means n8n stops needing to encrypt/decrypt anything. Happy to DM the writeup after you’ve unblocked the immediate save issue.
