Incompatibility with latest n8n – API/Worker Mismatch with Tesseract Node

[masterkey2000]

I am trying to use n8n-nodes-tesseractjs with the Self-hosted AI Starter Kit on Windows 11 (Ubuntu Terminal) using Docker with an Nvidia GPU.

Setup:

n8n: latest (Docker, Self-hosted AI Starter Kit)

Community Node: n8n-nodes-tesseractjs

OS: Windows 11, Ubuntu Terminal

Docker: Compose, GPU profile enabled

Additional components: Ollama, Qdrant, PostgreSQL

Problem:
When trying to install the community node via the UI, I get the following error:

Error installing new package Error loading package "n8n-nodes-tesseractjs": The specified package could not be loaded Cause: require() of ES Module /home/node/.n8n/nodes/node_modules/pdfjs-dist/legacy/build/pdf.mjs not supported. Instead change the require of /home/node/.n8n/nodes/node_modules/pdfjs-dist/legacy/build/pdf.mjs to a dynamic import() which is available in all CommonJS modules.

If I try to use older n8n versions (1.68.0, which the node documentation says it was tested against), I immediately get warnings that I should upgrade.

Additional Details:

The node also triggers an API/Worker mismatch, because modern n8n versions (latest) and the node expect different versions of Tesseract / PDF.js.

Manual installation of packages inside the container also fails (npm install tesseract.js@... tesseract.js-core@...), since some versions do not exist.

The issue seems to stem from a combination of the community node, PDF.js ESM modules, and the current n8n architecture (CommonJS vs ESM).

Expected Behavior:

The node should install successfully on current n8n versions, without API/Worker mismatches or ES module errors.

Alternatively, the documentation should clearly specify which n8n versions are officially supported.

Steps to Reproduce:

Clone the Self-hosted AI Starter Kit and configure .env

Run Docker Compose (latest n8n version)

Open http://localhost:5678 in the browser and try to install the community node

Error appears immediately

Questions / Feature Request:

Are there plans to update the node to support the latest n8n versions?

Are there any workarounds for the ES module issue and the API/Worker mismatch?

[jreyesr]

Hello @masterkey2000, and thanks for the report! I'll test this later, it works for me on 1.106.2, but it may be an error that only happens on node install or something, which I haven't done in a while.

(also, I'm constitutionally ordered to point out that your description ends with the remains of a ChatGPT or similar text generation: "If you want, I can also create an even more concise version formatted perfectly for GitHub, highlighting the error, setup, and reproduction steps in a minimal way. Do you want me to do that?" is absolutely LLM-generated) :)

[jreyesr]

Well, this is strange. I've just successfully installed the most recent version of the plugin (v1.4.2) in the most recent version of N8N (v1.107.4) in Docker, and it has worked normally. Which versions are you on?

Also, while I don't work on N8N itself, I can't quite make sense of require() statements happening anywhere near the code that handles custom nodes. N8N is a reasonably modern codebase and it uses import nearly everywhere, with just a handful of require()s near the edges of the code. This node certainly doesn't use require(), so I can't see where such an error may be coming from.

When you get an error in the UI while installing a node, you should also get it in the N8N console logs. Since you're on Docker with the AI Starter Kit, that should be on docker compose logs -f. Can you run that command and then retry the install, and then provide a screenshot or the error text itself? I hope that includes a stacktrace, which would allow me to follow the error further.

Thanks for the help!

[masterkey2000]

The docker Compose logs -f error is the same. " Problem in node ‘Tesseract‘ The API version "5.4.54" does not match the Worker version "5.3.31"."

For debugging I installed n8n again without the starter kit and get the same error.

I used the following docker-compose.yml:

version: '3.8'

services:
  n8n:
    image: n8nio/n8n:latest
    restart: unless-stopped
    ports:
      - "5678:5678"
    environment:
      - N8N_HOST=localhost
      - N8N_PORT=5678
      - N8N_PROTOCOL=http
      - NODE_ENV=production
    volumes:
      - n8n_data:/home/node/.n8n
      - /mnt/c/Users/XXXXX/Documents/PDF:/data/pdfs  # windows-folder → linux-mountpoint  
    networks:
      - n8n_network

volumes:
  n8n_data:

networks:
  n8n_network:

Installation process:

# Create directory
mkdir n8n
cd n8n

# Create Docker Compose file
nano docker-compose.yml

# Start containers
docker-compose up -d

I created a workflow with the following nodes:

• Read Files from Disk - Reads an image or pdf file
  

• Extract from File - Extracts text from the file
  

• Tesseract - Performs OCR
  

Here a screenshot of the workflow and the error message:

The result is again the error:
Problem in node ‘Tesseract‘ The API version "5.4.54" does not match the Worker version "5.3.31".

Unfortunately, I'm not very familiar with n8n yet. I managed to get the Tesseract node working by using Docker Compose down and up. But then I get this mismatch with the extract from file node.

What exactly are the worker and API versions? Can't I just fix them somewhere and bring them to the same version?

[jreyesr]

From what I gather, the "worker" and "API" are two pieces of the PDF library that this node uses in order to extract all the images that come in a PDF. In fact, the version mismatch is somewhat known to the maintainers of pdf.js, though most times it's due to caching in a browser, which can't be the case here because no browsers are involved.

I don't have Windows available to test this, but I think that volumes are stored in \\wsl.localhost\docker-desktop\mnt\docker-desktop-disk\data\docker\volumes (you should be able to press Windows+R and copy that path there, it should open the File Explorer on that path). Then, try to find a folder called n8n_data. That's where the n8n_data volume that you declared in the Docker Compose file is actually stored. Then, go to _data/nodes/node_modules/pdfjs-dist/build, and open the files pdf.min.js and pdf.worker.min.js.

Both should contain, after the first 20 lines (those are the license under which the package is released), a comment that says something like this:

/**
 * pdfjsVersion = 5.4.54
 * pdfjsBuild = 295fb3ec4
 */

Also, repeat that for the two files with the same names (pdf.min.js and pdf.worker.min.js) but in the directory _data/nodes/node_modules/pdfjs-dist/legacy/build.

Please check all four files, see what's the version and build mentioned on each, and report it here. Also, check the file _data/nodes/node_modules/pdfjs-dist/package.json, check the version line (should be near the top of the file) and report it.

In my install all five files have the same value, the version 5.4.54 that I pasted above, so things work fine for me, but in yours they may differ. If you see mixed versions, that's the cause of the issue and we can keep digging from there. In any case it's very strange, since all files should come at the same time from the same source (namely, the Mozilla release of the package), and those would surely all have the same version.

Did you by any chance poke into those files while trying to debug the install issue? Either directly via the Windows File Explorer, or perhaps by accessing /home/node/.n8n/nodes/node_modules/pdfjs-dist/... in the container shell, via docker compose exec?

---

Also, I've just noticed that there's an issue in N8N's repo about your original error, the require() error. There may be something going on in N8N itself, especially since that report concerns the Extract from File node, which is a core node that usually works perfectly fine. I'll keep an eye on that issue and see what comes out.

Another interesting point is that the N8N folks have a manual patch for some kind of issue in PDFjs, and that patch seems to be targeted at v5.3.31, which happens to match the version that one of the halves is using in your error. That seems slightly suspicious too, maybe N8N pins the version to 5.3.31 and when the Tesseract node comes in wanting to use 5.4.54 things break. I'm not sure.

[masterkey2000]

fixed it now with this command:

docker compose exec n8n sh -c '\
  mkdir -p /home/node/.n8n/nodes/node_modules/pdfjs-dist/build && \
  wget -q https://unpkg.com/pdfjs-dist@2.16.105/build/pdf.min.js -O /home/node/.n8n/nodes/node_modules/pdfjs-dist/build/pdf.min.js && \
  wget -q https://unpkg.com/pdfjs-dist@2.16.105/build/pdf.worker.min.js -O /home/node/.n8n/nodes/node_modules/pdfjs-dist/build/pdf.worker.min.js && \
  echo "✅ pdf.js Bundles installiert"'

now I get the Error the other way round when execute the node "Extract from File":
Problem in node ‘Extract from File‘

The API version "5.3.31" does not match the Worker version "5.4.54".

So I have come to the conclusion that the node n8n-nodes-tesseractjs in n8n is currently not usable in a meaningful way. Am I correct in this assumption?

Maybe I can find another way to do OCR on a self-hosted n8n system.

[jreyesr]

fixed it now with this command:

Yeah, that forces both halves of the library to the same version, so it now would work. The issue is that it's fairly old (about three years old) and contains a serious vulnerability that would allow malicious PDFs to run code as N8N, I believe. Which could be bad if you're trying to parse random PDFs that come from the Internet or allow people to submit PDFs to N8N for some sort of processing (you should be OK if you're only using the node to process, say, scanned PDFs that you personally scanned, or PDFs that come from Word documents that you personally wrote and saved as PDF). In fact, that's the reason why the people at N8N upgraded the version a few versions ago ("We tried postponing the pdfjs upgrade for a year, but had to finally cave in because of a large influx of security reports complaining about the older version of pdfjs.")

In general, you shouldn't need to mess with those files, they should be consistent on installation. Could you check the versions of those files as I described in my previous comment, before overwriting the files with the wget commands? Now they'll likely both say v2.16.105, but it would be interesting to see what they had before.

So I have come to the conclusion that the node n8n-nodes-tesseractjs in n8n is currently not usable in a meaningful way. Am I correct in this assumption?

It does work and is usable, at least for me, both in a native install and on Docker. And a few weeks ago I got an issue (which is the reason this node supports PDFs, by the way; it used to only support images), and while working with the person that raised the issue it also worked for them (we had issues with large files and N8N running out of memory, but that's another story. It worked fine for smaller files. So it appears to be something that is different in your installation, but I don't know what it is.

Maybe I can find another way to do OCR on a self-hosted n8n system.

You could install OCR (the CLI, the original tool) and use it via Execute Command and by reading and writing to disk, but since you're on Docker that would involve modifying the Docker image, which is more involved than just pulling the official image. Or you could check out OCR APIs (e.g. Google Cloud has some kind of OCR product (with AI!)), but those are usually paid and ship data out to a third-party service.

I'll keep trying to reproduce the issue, feel free to let me know if you find anything else.

[JoshBour]

I'm having the same issue. I'm running a self-hosted instance of n8n with docker, installed the community node, added it to a workflow and when I run it I got:

EDIT: I updated n8n to 1.109.1, but the problem still exists.

[timrasche]

I'm having the same issue. I'm running a self-hosted instance of n8n with docker, installed the community node, added it to a workflow and when I run it I got:

EDIT: I updated n8n to 1.109.1, but the problem still exists.

Same here....

[patelhe]

I tried to install the n8n-nodes-tesseractjs on self hosted docker container and got the exact same issue as the OP. It completely crashed my container and was forced to reinstall all including my persistent data folders as it was trying to load some tesseract js files from it.

[jreyesr]

Hello everyone! Sorry I've not answered in a while, these times I have very little time left for not-work.

I've managed to make the Tesseract node fail reliably when a Extract from File node has already run. That's why I couldn't reproduce it previously, because I just used the Tesseract node and that one, by itself, seems to work fine. Can you all verify if that's the case? See for example the workflow linked in #5 (comment). I'm interested if the following is true for everyone:

• Do you have an Extract from File node in the WF? Or on other WFs that have run after N8N's last restart?
• Has that node been run before the Tesseract node? Either it's in the same WF and it runs first, or it's on other WFs that have run separately
• After the Extract node has run once, do you see the Tesseract node start failing and not recover? For me, even if I clear the execution data and try again, or reload the page, it'll fail anyways, even if I don't run the Extract node again that time
• But, even if the Tesseract node is failing, the Extract node keeps working normally
• Can the issue be "fixed" by restarting the N8N container or the N8N process (depending on whether you're using the Docker install or the NPM install)? After that, does the Tesseract node start working again, until the Extract node is run, at which point it breaks down again until the next restart?
• Does the same thing happen in reverse? That is, if you run the Tesseract node first, does the Extract node start failing now? For me, it behaves in nearly the same way both sides, whichever node is run first will cause the other to stop working

Can you run those tests (run the Tesseract node just after restarting N8N, run the Extract node first and then the Tesseract node, try to run the Tesseract node again after it fails, restart N8N and run the Tesseract node again and then the Extract node) and report what happens? If you get errors, please record what made them happen (for example, I ran the Tesseract node and it worked, but then running the Extract from File node doesn't work, it fails with the error The API version "5.3.31" does not match the Worker version "5.4.149".. But if I restart N8N, then run the Extract node, which works normally, and then try to run the Tesseract node, it fails with the error The API version "5.4.149" does not match the Worker version "5.3.31".). It appears that running each node makes the other stop working until the next restart, and the version mismatches go both ways (5.3.31 on the API and 5.4.149 on the worker or viceversa) depending on which node was run first. That is interesting behavior, if any of you can confirm that you see the same things.

I am not an expert on the internals of N8N, but it feels to me like the Extract from File node (set to Extract from PDF) and this node are somehow "poisoning" each other, such that once one of them runs the other doesn't run anymore, until N8N is restarted. I know that they had to do special things precisely to get PDF.js to work, which is the library that is giving us trouble here.

@masterkey2000 @JoshBour @timrasche @patelhe Thank you all for the reports and for your help diagnosing this!

[tmeekes]

Not sure if it's related, but when I updated to the latest version of n8n (1.110.1), my container crashes with a 132 exit code. Something seems to be failing.

After resetting my n8n instance and removing this community node, I'm able to proceed as usual.

This definitely seems to be triggered when I try to run my workflow that attempts to use an "Extract from File" node.

Interestingly, with the Tesseract node installed, my n8n instance is unable to recover. I have to manually recover it. Also, removing Tesseract doesn't prevent the initial problem happening with the Extract from File node either - I'm still getting an OOM error there.

Execution stopped at this node
n8n may have run out of memory while running this execution. More context and tips on how to avoid this in the docs

Jumping over to this related issue to focus on solving the foundation of my problem, but figured it may be relevant regardless

[jussihi]

Same here, having n8n-nodes-tesseractjs after Extract from PDF fails to worker and API version mismatch. With bare n8n-nodes-tesseractjs node, everything works just fine.

[jreyesr]

Hello @jussihi, and thanks for the info. Could you perhaps also test if running the nodes in reverse also breaks? That is, you've ran the Extract from PDF node and then the Tesseract node breaks. What happens if you run the Tesseract node first? Does the Extract from PDF node now fail, with the same error, except that the Worker and API versions that appear in the error message are switched around? Also, once one of the nodes starts failing, does it keep failing if you try to rerun the workflow? Can you fix it by restarting N8N?

[jussihi]

@jreyesr Yes, if I run them the other way around, the error messages' versions are shown vice versa (as expected):
The API version "5.3.31" does not match the Worker version "5.4.149".

After this, none of the "Extract from PDF" nodes work in any of my workflows, so this "poisons" my whole n8n environment, not just one workflow. It "resets" by restarting n8n.

So in short: After restart, whichever runs first in any workflow (Extract from PDF or your community node) will then work in all workflows, and the other one will fail in all workflows.

[jreyesr]

Got it, thanks for the confirmation. That matches what I saw, I'll have to see what can be done to fix it