# \[pre-alpha\] Running python within Node-RED simply (or even Rust)

**URL:** <https://discourse.nodered.org/t/pre-alpha-running-python-within-node-red-simply-or-even-rust/102112>\
**Category:** Share Your Nodes\
**Tags:** python\
**Created:** [9 November 2026 14:31 UTC](https://discourse.nodered.org/t/pre-alpha-running-python-within-node-red-simply-or-even-rust/102112 "2026-11-09T14:31:54Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![hyamanieu](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/hyamanieu/32/65018_2.png) [@hyamanieu](https://discourse.nodered.org/u/hyamanieu)\
**Post date:** [9 November 2026 14:31 UTC](https://discourse.nodered.org/t/pre-alpha-running-python-within-node-red-simply-or-even-rust/102112/1 "2026-11-09T14:31:54Z")

</div>

Hello all,

I took the time to finally develop a set of nodes to execute **Python** in a way that should be "simple" for automation techs, but also their IT teams who set up Node-RED or FlowFuse.

==\> [GitHub - hyamanieu/node-red-python-tasks: A simple way to include python into your pipelines and Node-RED flows, even when executing in the cloud or using external workers. · GitHub](https://github.com/hyamanieu/node-red-python-tasks)

The idea is that by simply installing this package, it automatically adds a **Python** workspace manager called [pixi](https://pixi.prefix.dev/) on the Node-RED host machine. Then **Python** environments (or _workspaces_ in pixi lingo) are installed or updated on the fly from within Node-RED. It should not be necessary to execute any command from the host terminal to set it up: it should be installable from the palette manager.

In later phases of the roadmap, executing code on remote machines is planned. I believe it should be as simple. The philosophy is simple:

- an automation tech should not have to learn DevOps skills
- they should be able to execute code in most languages without slowing down production
- their scripts should be able to receive and send payloads to a running Node-RED instance

I have asked around me and I know some automation programmers struggle with the `exec` node, notably because they need to add **Python** to their host machine. Then they only execute batch tasks once in a while. Running many tasks within seconds is still a problem. It shouldn't be anymore with this package.

By automation programmers I really mean people who focus on PLC programming and sprinkle their work with some **Python** / **.NET** scripts, not **Python** DevOps. With the diversity of machine learning libraries, documentation, and LLMs, it has become realistic for most of them to add online data inference within their Node-RED flows.

I have two questions for the community:

- Is it useful, and should it be published to npm?
- If yes, would there be an interest in adding **Rust** on the [roadmap](https://github.com/hyamanieu/node-red-python-tasks/blob/main/ROADMAP.md)? As it uses pixi in the background, [executing Rust code is possible](https://pixi.prefix.dev/latest/tutorials/rust/), and it seems this programming language is also gaining momentum within the PLC programming world.

I am open to any critique/question/feedback. Or contrib 😁

_Note:_ the repo was mostly "vibe coded", but everything has been thoroughly and humanly tested and corrected (by me).

---

<div class="post-metadata">

**Author:** ![krambriw](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/krambriw/32/5429_2.png) [@krambriw](https://discourse.nodered.org/u/krambriw)\
**Post date:** [9 November 2026 14:52 UTC](https://discourse.nodered.org/t/pre-alpha-running-python-within-node-red-simply-or-even-rust/102112/2 "2026-11-09T14:52:01Z")

</div>

> [@hyamanieu](#):
>
> - Is it useful

I'm not so sure. Full respect what you have made but for me, running quite a few Python scripts "mqtt-integrated-with-NodeRED" but running fully outside in own processes, the exec-node has satisfied all me needs so far

Does your nodes support Python multithreading as well as multiprocessing?

Kind regards, Walter

---

<div class="post-metadata">

**Author:** ![hyamanieu](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/hyamanieu/32/65018_2.png) [@hyamanieu](https://discourse.nodered.org/u/hyamanieu)\
**Post date:** [9 November 2026 15:16 UTC](https://discourse.nodered.org/t/pre-alpha-running-python-within-node-red-simply-or-even-rust/102112/3 "2026-11-09T15:16:38Z")

</div>

Thanks for responding!

> Does your nodes support Python multithreading as well as multiprocessing?

It's on the roadmap, but it actually already does it when sending to different workspaces.

> mqtt-integrated-with-NodeRED

What do you mean here? You have a link?

---

<div class="post-metadata">

**Author:** ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)\
**Post date:** [9 November 2026 16:04 UTC](https://discourse.nodered.org/t/pre-alpha-running-python-within-node-red-simply-or-even-rust/102112/4 "2026-11-09T16:04:41Z")

</div>

Without wanting to lessen what you've achieved. Just a note of caution from experience in an enterprise setting.

The more levels of execution you have, the harder it is to secure things.

What protections do you put in place to make sure that people can't accidentally or deliberately cause mayhem by executing "random" external code? Or indeed, not so random, especially on a compromised machine or account.

Sadly, this is no longer a theoretical or remote possibility - just ask the organisations across the EU hit by freezer hacks recently.

So anyway, just a friendly warning to anyone going down this route - the implementation might be easy - possibly too easy in fact. The secure architecture is probably not so easy.

---

<div class="post-metadata">

**Author:** ![gregorius](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/gregorius/32/73816_2.png) [@gregorius](https://discourse.nodered.org/u/gregorius)\
**Post date:** [9 November 2026 16:12 UTC](https://discourse.nodered.org/t/pre-alpha-running-python-within-node-red-simply-or-even-rust/102112/5 "2026-11-09T16:12:49Z")

</div>

As the creator of [Erlang-Red](https://github.com/gorenje/erlang-red), I've gone one step further and decided to implement the entire backend in Erlang instead of Javascript. That means the function node over at Erlang-Red is actually Erlang code, no Javascript allowed!

Why do this? Because Erlang is far better suited to the concepts of flow based programming but the Node-RED editor is unbeatable! Erlang also has additional concepts (such as Supervisors and State Machines) that aren't available in JS but that are well suited to a visual approach to programming, so I've created nodes to represent those concepts.

I think there is more to gain in porting the visual approach/experience of Node-RED to Python than to add a python node to Node-RED. As pointed out, I can use an exec node for that or even create a wrapper around it to make it simpler (I did also create a [ExecWithPipe](https://flows.nodered.org/node/@gregoriusrippenstein/node-red-exec-with-pipe) so that I could pipe `msg.payload` to a python process to execute the python code I create in Node-RED - for example).

Also since I want to share flow code across Erlang-Red and Node-RED, i.e. the same flows should ideally be executable in both, I've also created a simpler code sharing setup - [FlowHub Local](https://discourse.nodered.org/t/flowhub-flowhub-local-local-visual-change-management/101811).

But these are all things that I like doing, AI got bored of my ideas and won't help me.

> [@hyamanieu](#):
>
> - Is it useful, and should it be published to npm?

If it's useful for you, then publish it to npm. If not, then leave it. If you're not going to maintain it, then leave it.

If you ask, you'll get (NumberOfPeopleWhoRespond + 1) opinions - just publish it!

> [@hyamanieu](#):
>
> - If yes, would there be an interest in adding **Rust**

There is a [Rust-RED](https://github.com/oldrev/edgelinkd) i.e. a complete implementation of the Node-RED concepts in Rust.

P.S.

oooooo yes:

> [@hyamanieu](#):
>
> Does your nodes support Python multithreading as well as multiprocessing?

That's also why I ported the concept to Erlang - it's amazing multi-processing with thousands/millions of processes. This means that each node becomes it's own process and each message (`msg`) is a true message passed between independent processes. I.e. Instead of using "events", I'm using true messages being passed between processes .... yet the flows look the same!