I’m running n8n using Docker Compose and everything works great except for one issue. I can create new workflows, run them, and delete them without any problems. But when I try to rename a workflow, nothing happens. The rename function seems to be disabled or blocked somehow.
I’ve checked through all the environment variables I could find but haven’t spotted anything that controls workflow renaming permissions. Maybe I’m missing a specific setting or there’s a permission issue with my current setup?
This is a workflow state management issue, not Docker config. I hit the same thing when n8n couldn’t track workflow states during renames. The editor locks certain operations when background processes or webhook listeners are still attached to the workflow.
Stop all active workflows first, then try renaming. n8n blocks metadata changes on workflows with running or paused executions. Check if you’ve got any triggers set to always-on mode - these prevent name changes too.
You might need to restart your n8n container after stopping everything. Workflow state gets stuck in memory even when the database looks fine.
This sounds like a frontend JavaScript issue, not Docker. I had the same problem running n8n behind certain network setups. The rename feature needs specific API endpoints that might be getting blocked or timing out. Try hitting your n8n instance directly at localhost:8080 instead of through domain forwarding - see if rename works there. If it does, your WEBHOOK_URL setting’s probably conflicting with internal API calls. Also check your browser’s network tab in dev tools when you try to rename. Watch for failed HTTP requests that’ll show what’s actually breaking. Sometimes the rename button looks clickable but the API call fails silently because of CORS issues or routing problems.
Had the same issue about six months back with my dockerized n8n setup. Turned out it wasn’t n8n’s fault - my PostgreSQL user had wonky write permissions that broke some operations but left others working fine. Fixed it by recreating the database volume and giving the postgres user full ownership. Check if your browser’s blocking the rename API calls too - pop open dev console and watch for failed requests when you try renaming. Also worth checking if you’ve got n8n behind a reverse proxy that’s messing with the PUT/PATCH requests for renames.
That’s weird - your docker-compose looks fine. I’ve run into this before though. Try adding N8N_DISABLE_UI=false to your environment variables to make sure UI permissions are set correctly. Also, are you clicking the workflow title itself or just selecting the workflow? The rename sometimes only works when you click directly on the name text.
that’s odd, i haven’t encountered this issue personally. try clearing your browser’s cache to see if that helps. also, make sure you’re using the latest version of n8n, as some older versions had renaming issues. checking the container logs could provide more insight too!
I’ve dealt with containerized automation for years and this exact issue drove me crazy until I completely changed approaches.
You’re hitting a classic n8n architecture problem. Rename operations need complex database transactions that get screwed up by Docker volume permissions and PostgreSQL connection handling. Even when your compose file looks perfect, there are always timing issues or permission conflicts happening behind the scenes.
Skip debugging Docker networking and database permissions - I’d go with Latenode instead. It handles all the infrastructure mess so you never deal with these deployment headaches. Rename workflows instantly without worrying about container permissions or database locks.
Same workflow automation power as n8n but no Docker maintenance. Better debugging tools too, and no PostgreSQL management. Made the switch last year and haven’t regretted it.
Your config looks standard, but I think this is a database permissions issue, not environment variables. I had the same problem - PostgreSQL wasn’t properly initialized with all the tables n8n needs for metadata stuff like renaming. Workflow data worked fine, but metadata updates failed silently. Connect directly to your PostgreSQL container and check if all n8n tables exist in the public schema. Look specifically for the workflow metadata tables. You can also test by switching to SQLite temporarily - just remove all the DB_POSTGRESDB variables. If renaming works with SQLite, you’ll know it’s definitely a PostgreSQL permissions or schema problem.