My pipeline is made of several webhook triggers and several schedule triggers, plus around 15 nested sub-workflows (called through Execute Workflow).
Recently I wanted to set up a dev environment. I cannot point my webhooks at a separate dev target, so the best idea I came up with was to copy the whole pipeline and wire the copy into the main one through an IF node and a global variable dev: on/off. When dev is on, every incoming payload is duplicated and also pushed to the dev copy through a webhook. When dev is off, only prod runs. The goal was to test the exact same real data that hits prod, but on the dev copy, and once something works there, move it to prod. This matters because, as I said, I have around 15 nested sub-workflows, so I really want to validate changes on real traffic before promoting them.
After I connected the dev copy to prod, I started getting strange problems that I never had before:
Some sub-workflows that were clearly published in the main workflow started throwing errors like “unpublished sub-workflow”. That made no sense to me, they were published.
I started getting race condition problems on basically every node that touches the n8n Data Tables / built-in DB.
Deleting the dev pipeline made all of this go away immediately.
So I have two questions:
If n8n started behaving like this (false “unpublished sub-workflow” errors and race conditions) just from roughly doubling the number of sub-workflows and executions, should I be worried that simply growing my normal prod with more nested sub-workflows over time will trigger the same bugs? Is there a known limit or known issue around the number of nested sub-workflows or concurrent executions on the Pro plan?
What is the recommended way to build a dev environment in my situation? I cannot easily repoint the webhooks, I have many nested sub-workflows, and I want to test against the same real data that prod receives.
What is the error message (if any)?
“unpublished sub-workflow” on sub-workflows that are actually published, plus intermittent race condition errors on nodes using the n8n Data Tables.
Share the output returned by the last node
(the failing sub-workflow call returns the "unpublished sub-workflow" error instead of running)
Given that you have 15+ nested workflows and are seeing race conditions, you have outgrown the “single-instance” approach for development.
The gold standard for n8n is to have a completely separate n8n instance for Dev. Since you can’t change the webhook source, use your Prod instance as a “dumb proxy.”
Prod Instance: Receives the webhook → Immediately sends an HTTP Request to the Dev Instance’s webhook URL → Continues with Prod logic.
Dev Instance: A totally separate n8n Cloud account/instance.
Why this works: The Dev instance has its own database. There is zero resource contention. If the Dev instance crashes or locks up, it has zero impact on your Prod execution.
I had dev pipeline exactly as you mention: on every trigger i had node if/else which check on global variable (dev: on/off) and than http POST node that sends (pass) data to the dev. With understanding that this logic should not potentially overload resources, I still have faced with some unexpected behavior from n8n side. Maybe n8n has limit resources when hosted by cloud?
There’s no documented hard limit on sub-workflows. The problem you hit isn’t about count, it’s about SQLite and concurrency. Your Cloud instance uses SQLite by default, and SQLite has a single-writer lock. When you doubled your pipeline, both prod and dev copies were writing to the same Data Tables simultaneously, causing write contention. The “unpublished sub-workflow” errors are likely a side effect of this contention: when n8n can’t resolve a sub-workflow reference fast enough under resource pressure, it can throw misleading errors. So growing your normal prod over time won’t cause the same issue unless you’re also doubling concurrent writes to Data Tables.
For a dev environment on Cloud, kjooleng’s separate instance approach works. A cheaper alternative that stays within one instance: instead of duplicating the entire pipeline, use n8n’s workflow versioning. Make changes in a workflow, save without publishing, then test manually. Production executions always use the currently published version, so your prod keeps running the last published version while you test changes on the saved draft. Once validated, publish. This doesn’t cover testing with live webhook traffic, but it avoids the duplication problem entirely.
For live traffic testing specifically, kjooleng’s proxy-to-separate-instance approach is the right call.
@pohgen good news: no hard limit on nested sub-workflows, growing prod won’t trigger this. On Cloud, concurrency (Pro = 50) only counts webhook/trigger executions, not Execute Workflow calls, so more nested sub-workflows don’t eat your budget.
What broke it was cloning the pipeline into the same instance: the “unpublished sub-workflow” errors are prod and dev copies colliding (duplicate sub-workflows let Execute Workflow hit the wrong/unpublished copy), the Data Table races are both copies hammering the same built-in tables at once, and you doubled the webhook executions that do count toward the 50 cap. The dev copy being deleted fixing everything confirms it’s the duplication, not the count.
For dev: use a separate n8n instance with its own Data Tables so it can’t contend with prod. To test real data without repointing webhooks, capture the prod payloads and replay them into dev rather than live-forking traffic.