Variables Are Being Lost in Workflows (Self-hosted, Docker, v1.97.1)

[Sergio_Longhi]

Hi,

I’m running n8n self-hosted via Docker (v1.97.1) and I’m constantly fighting a problem where variables (especially file data or values from Set/Code nodes) disappear mid-workflow — especially after nodes like Merge, IF, or Function.

This is slowing me down massively. I’m forced to re-merge or re-Set values constantly just to “carry” important data forward. It gets messy fast.

---

What I need help with:

• Is there a clean way to persist variables (files or JSON) across an entire workflow?
• Should I use global memory, Workflow Context, or even a DB as a workaround?
• Any tricks to avoid repeating Merge nodes just to keep data alive?

Thanks — this issue is killing my productivity. Appreciate any advice.

[fahmiiireza]

Hi there, can you share an example workflow of your variable being lost?

[cutecatcode]

if you say “Entire workflow”, you can try with Execution Data node

[Sergio_Longhi]

I never used “Execution Data”, I will check the documentation. Is something like “Global Constant” where I can store some data?

[Sergio_Longhi]

I have several nodes, when I’m in the middle of a workflow or toward the end, I open a node, on the left I have all the variables, I drag them into a field. While I’m dragging them they are green (ok), when I let them go into the field they became red (Not OK) an the execution say that thare is no value inside.
I attached you two screenshot, one of the workflow and another an example of a node containing all the variales in the left part, but not working when I try to use them.

[automaxion]

Hey! Yep, this is a common frustration with n8n. I’d suggest using workflowContext to store values you want to reuse later — it helps avoid re-setting or merging. For files, storing them externally (like S3 or Supabase) and passing the link works best. Let me know if you want a quick example!

[Sergio_Longhi]

Is “workflowContext” an addon or you mean workflow Context? LOL I’m lost.
Yes, I was thinking to store variables externally and be done with that.

This is something they should fix, or they want to lure people into the incredibly expensive Enterprise version?

[automaxion]

Haha, no worries. I meant workflowContext, the built-in Workflow Context feature in n8n (not an addon). You can use it to store variables temporarily across the workflow run.

And yeah, totally agree it would be great if variable persistence was smoother by default. But no, this isn’t an Enterprise-only feature — just a bit of a workaround for now.

[Sergio_Longhi]

I see now, I guess I missed something really important. Would you mind to point me in the right direction on how to use this feature?

[automaxion]

Of course! To use workflowContext in n8n, here’s a quick example:

In a Function or Set node, you can store data like this:
$workflowContext.set(‘myData’, $json);

Then later in the workflow, use another Function node to retrieve it:

javascript

const data = $workflowContext.get(‘myData’);
return [{ json: data }];

This lets you carry data between nodes without needing to re-merge or pass it directly.

[Sergio_Longhi]

@automaxion

workflowContext

Thank you, I believe this will help a lot.

[Sergio_Longhi]

One more thing. I’m coding and developing the logic of this workflow with Gemini 2.5 Pro assistance. When I instructed Gemini to use the workflow context or a global constant, it responded with a concern: “What if two users run the workflow simultaneously? The constant would be overwritten by the second user.”

I understand that in most cases, only one user will be using the workflow at a time, but does this concern make sense?

[automaxion]

Good question — and Gemini’s concern makes sense in some contexts, but not here.

In n8n, each workflow execution is isolated. That means workflowContext is unique to each run, even if multiple users trigger the workflow at the same time. So there’s no risk of data being overwritten between users.

This only becomes a problem if you’re using global variables or writing to shared external storage. But for workflowContext, you’re safe — it’s meant for temporary data within a single execution.

[Sergio_Longhi]

Thank you very much; you truly know your subject.

I’ll inform my friend, Gemini, even though he probably won’t retain the information.

By the way, yesterday I discovered the mistake I was making. A wrongly configured switch was preventing part of the variables from working. Gemini was much more frustrated than I was because I couldn’t recover the variables. He started hallucinating and constantly apologizing, going back and forth, finding seemingly good solutions but unable to debug the problem. It’s the first time I’ve seen an LLM hallucinate so severely. When I asked questions, all it could do was apologize and offer another solution instead of answering my question.

[automaxion]

Haha, that’s a great story — and totally relatable!

LLMs are amazing, but yeah, once they hit a logic wall, they tend to spiral into polite confusion. Glad you figured out the real issue — misconfigured Switch nodes can definitely cause sneaky variable problems.

Thanks for the kind words, and feel free to tag me anytime Gemini starts panicking again!