Hello Community,
I’m working on a DuckDB + Quack n8n node.
As @duckdb/node-api needs glibc, the docker compose file needs to be adapted
image: docker.n8n.io/n8nio/n8n:latest-debian # ← add :latest-debian
volumes:
- 'n8n-data:/home/node/.n8n'
- './dist:/home/node/.n8n/custom/node_modules/n8n-nodes-duckdb-quack/dist' # ← add this
Just checking here if there is potential side effects doing that ? Is this the correct best-practice ?
Thanks for your help
Stéphane
Welcome @hsteph!
Using docker.n8n.io/n8nio/n8n:latest-debian for glibc-dependent packages is the right approach - this is exactly the pattern for community nodes that need native bindings like DuckDB. No major side effects from switching to the debian image as long as your other env vars stay the same.
One thing to double-check: make sure the N8N_CUSTOM_EXTENSIONS env var points to the same path you’re mounting into the container, or that your custom node ends up in the default custom nodes path. If n8n doesn’t pick it up on startup, check the n8n logs for any module load errors - that’s the fastest way to confirm the node is being discovered correctly.
Thanks for the confirmation !
With :latest-debian, I now have a HTTP ERROR 502
The 502 is now a startup crash, not a proxy issue: n8n is failing because the database schema and the app version don’t match. (this answer is generated by Hostinger’s AI, … not sure this is the problem)
Any idea ?
Well, I have installed the node on a Hostinger/VPS where n8n has been installed via Coolify (no :latest-debian), … and it works !
The node is available. More info here:
Funny timing. I just submitted a feature request for an officially supported duckdb/motherduck set of nodes.
That would be great to have an official version !