Hello everybody and thanks for your work!
Apologies if this topic exists, I did my best to search but couldn’t find it.
I have some code in a Gitea repository which I would like to execute as part of my n8n workflow (self-hosted in a docker container). Right now I am using a git pull node and an execute_command node to run the script on the machine. The scripts mainly reference a software API and manipulate files.
Is this the ideal way to do it? I also use code nodes for other things, but some things I really need to write and debug in my IDE…
Thank you!
إعجاب واحد (1)
The git pull + Execute Command pattern you’re using is actually a solid approach for self-hosted Docker setups - it keeps your scripts version-controlled and separate from n8n’s core. One thing worth thinking about: if your scripts need to run in a specific environment (different Python version, packages installed, etc.), you might want to consider calling the script via a small HTTP wrapper or a separate container rather than running it directly inside the n8n container. That way you’re not polluting n8n’s runtime environment and your scripts stay independently testable from your IDE without touching n8n at all.
إعجاب واحد (1)
Yeah that setup can work, but I’d be careful about doing git pull as part of every workflow run. I’d probably update the repo separately, then have n8n run a fixed script path with Execute Command, like /scripts/my-task.py .
If the script needs special packages, put those in the Docker image/container instead of installing them during the workflow run. That keeps n8n as the orchestrator instead of making the workflow manage its own code updates.
إعجاب واحد (1)
Thanks to you both for your input!
I have two follow-up questions:
@nguyenthieutoan : my Python runner is set up in a sidecar container to the one that hosts n8n. Is that a good place to run the scripts or is would that also be considered as polluting the n8n environment?
@OMGItsDerek : what would be the risk of pulling a repository as part of every workflow run?
Thanks again, looking forward to hearing your thoughts!
Yeah, the biggest issue with doing a git pull on every workflow run is that things can become unpredictable really fast. One run might execute slightly different code than the previous one without you realizing it. You can also run into random failures if Git/Gitea or the network is temporarily unavailable.
Another thing I’d watch out for is concurrency. If two workflow executions happen at the same time and both try to pull/update the same repo, weird issues can happen depending on how the files are being used.
It also makes debugging harder because when something breaks, you now have to ask “was it the workflow itself, or did the code change between runs?”
That’s why I’d usually keep deployment separate from execution. I’d let n8n just run a fixed script path, and update the repo independently. If you do want automatic updates, I’d at least log the commit SHA for each run and make sure only one pull can happen at a time.
إعجاب واحد (1)
هذه نقاط رائعة حقاً، شكراً لك!
تم أيضاً التوصية لي بدمج Github Actions. هل لدى أحد منكم خبرة مع ذلك؟
على أي حال، سأجرب بعض الأشياء وسأخبركم بما سنفعله في النهاية.
إعداد السيارة المصاحبة (sidecar) مثالي فعلاً لهذه الحالة - إنه بالضبط الفصل الذي كنت أشير إليه. حاوية n8n الخاصة بك تتولى التنسيق، وحاوية Python الخاصة بك تتولى التنفيذ، ولا توجد أي تسرب وقت تشغيل بين الاثنين. تستدعي السيارة المصاحبة عبر HTTP أو Execute Command (إذا كانتا على نفس شبكة Docker)، وكل جانب يبقى قابلاً للاختبار بشكل مستقل. بخصوص تكامل GitHub Actions، هذا يعمل أيضاً لكنه أكثر ملاءمة لخطوط الأنابيب CI/CD بدلاً من تنفيذ البرنامج النصي عند الطلب داخل سير العمل.
إعجابَين (2)