Describe the problem/error/question
I’m receiving a out of memory error when running a workflow that connects to an SFTP where a zip file is loaded. It should download and unzip the file. The zip file is around 30MB and contains one csv file that has 30-50 rows. Each row represents a pdf which is also located within the zip file. When my decompress node runs, it times out after 13 minutes or so. This seems incredibly low. I’m on the cloud version but not sure of the edition (if that makes any difference). Is there a way to increase memory so we don’t run into this?
What is the error message (if any)?
Please share your workflow
(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)
Share the output returned by the last node
Information on your n8n setup
- n8n version:
- Database (default: SQLite):
- n8n EXECUTIONS_PROCESS setting (default: own, main):
- Running n8n via (Docker, npm, n8n cloud, desktop app):
- Operating system:
Hi @jon.parmley
This is how the memory allocation looks in each n8n cloud plan:
And according to your use case, where one PDF with 30-50 rows containing multiple PDFs can easily exhaust the memory limits in lower plans, the best possible solution to this will be to upgrade your current plan to a higher plan, or you can restructure your workflow to enable batch processing and heavy tasks divided into sub-workflows, which will make the memory free after parsing one PDF, which will significantly reduce the memory load.
good morning @jon.parmley
I would avoid extracting all PDFs inside n8n Cloud. A more stable architecture would be to extract the ZIP in an external service, save the files to storage like S3/GCS, and return to n8n only a manifest with URLs. That way n8n processes one PDF at a time and doesn’t load all binaries into memory.
The actual problem is how n8n processes the ZIP file. The entire file plus all contained PDFs end up in memory at the same time.
Concrete solution without a plan upgrade:
-
Download and unzip the ZIP file as before
-
Then add a Split In Batches node with batch size 1
-
Process each PDF individually
-
Merge them at the end
This way n8n only keeps one PDF in memory at a time instead of all 30-50 simultaneously. With a 30MB ZIP file, this should work even on lower plans.
Which plan are you currently using?
hi @Kemal_Automation
it seems to me that your answer is the same as mine.
According to the community guide, we cannot repeat answers.
Can you help me understand if they really are the same?
Moving up a plan level to Pro Plan 2 fixed the memory issue. Thanks for the suggestions.
@jon.parmley Please consider marking that as a solution to help other people in the future know what the correct answer to this problem is.
Hi tamy.santos, the approaches are different. You propose unpacking the ZIP externally with S3/GCS storage. That’s a valid architecture, but it requires additional infrastructure.
My proposal keeps everything in n8n with a Split In Batches node, so no external services needed and it’s simpler to implement.
Perfect Kemal, thank you so much!