Two soap box moments to start with.
First off, there are very few cases where the value of IP in a Python node is greater than the cost to obfuscate it. There is a VERY high likelihood that youâll be spending $10 to protect something which is only worth $1 by going down this route. This is doubly true in the age of AI and MCP. The value of the IP is less in the script itself and more in the way you use it, and if you canât figure out how to capitalize on your script better than the firm across the street then there are far better uses of your time than adding protections to your scripts.
Next up, I am NOT a fan of close sourcing, obfusication, or adding access restrictions on things built in / on Dynamo. Dynamo is built on the hard work and efforts of the community here and beyond, time which was given on evenings and weekends in an attempt to better the industry as a whole; we have a moral obligation to help the next generation of users benefit just like we benefitted from those who came before us.
Ok I will now step off the soapbox and provide some answers.
There are lots of options here, but I will outline my two favorite.
First the simplest is to migrate away from a Python to something C# based (zero touch nodes). More robust, faster, and obfuscated code by default. No one can directly see it but it can be decompiled into something which a competent developer can reproduce with some effort. Once people have the nodes theyâll be able to use them though, which makes deployment easy. You also get all the benefits of ZT nodes (tooltips, error handling, user messaging, direct integration with the active dynamo environment, etc.). However those with the modes will be able to use them, so you may have to or want to incorporate an authentication mechanism as well.
The second option is to move the code out of Dynamo and onto a remote location which requires authentication; use a âread textâ node to pull the script contents into a string in the Dynamo environment and pass that onto a PythonScriptFromString node. One drawback here is that everyone will be able to read all of your code once they see it, so it isnât obfuscated just access restricted. If I can see the document you have the code in I can use it and read it. Maintaining that secure server is the hard part. Infosec policies and changes often blocks stuff like this after it is put in place, and as soon as someone âoutside the officeâ has to see stuff it wonât run at all; and internet hiccups of VPN make that a nightmare. One partial read of the data might cause your model to corrupt too.
The key thing here is that the obfuscation method increases maintenance costs from near zero to potentially staggering amounts, add a lot of technical debt which will need to be managed, and can reduce reliability and therefore value. Proceed with caution, and know that admitting âwe shouldnât do thisâ isnât a sign of failure but that you need to build things a bit differently the next time out.