To help diagnose this issue, could you please provide more details:
When you say the inputs don’t appear, do you mean the input connectors are completely missing from the nodes, or they exist but data doesn’t flow through them?
Could you share a screenshot of how the workflow looks in GCP CloudRun vs how it looks locally?
What environment variables have you configured in CloudRun? Specifically, do you have N8N_HOST, WEBHOOK_URL, or N8N_EDITOR_BASE_URL set?
Are you accessing the n8n editor through the same URL that’s configured in those environment variables?
Do you see any errors in the browser console (F12 → Console tab) when loading the workflow?
This will help us understand if it’s a configuration issue, a frontend rendering problem, or something else.
however those entries are not really safe in my opinion. Do you have any specific recommendations what to really keep in CSP when hosting n8n? I would like to follow some guideliness without opening too much.
For the n8n domain, avoid using a generic and overly restrictive CSP inherited from other applications. If you already enforce a strong global CSP, create a specific exception or rule for the n8n host.
First, test the setup without any Content-Security-Policy to confirm that the issue disappears.
Then, if you want to reintroduce a CSP, do it incrementally, testing the editor after each change.
In cases reported by other users, working configurations typically used a very permissive CSP (for example frame-ancestors * or even a complete removal of the CSP) for n8n. There is currently no documented “minimum safe” CSP profile in the available sources.
Since there is no official documentation defining a “secure and supported” CSP for n8n, any stricter policy you choose to keep must be validated through testing in your own environment (loading the editor, opening AI nodes, connecting nodes, running workflows, etc.).