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 Like
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 Like
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 Like
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 Like
These are really great points, thank you!
I was also recommended an integration with Github Actions. Does anyone have any experience with that?
Anyways, I’ll try some things out and let you know what we do in the end.
The sidecar setup is actually ideal for this - it’s exactly the separation I was referring to. Your n8n container handles orchestration, your Python container handles execution, and there’s no runtime bleed between the two. You call the sidecar via HTTP or Execute Command (if they’re on the same Docker network), and each side stays independently testable. For GitHub Actions integration, that works too but is better suited for CI/CD pipelines rather than on-demand script execution inside a workflow.
2 Likes