How to protect Python source code while respecting client-side data privacy concerns?

Hi all,

I’m working on a Python-based application where the business logic (such as custom rules, formulas, or AI predictions) is sensitive and I don’t want to expose it to end users.

One popular solution is to keep the logic on a server and expose it via an API, which works great for code protection. However, my client has a strict requirement that no data should be sent to external servers for data privacy reasons.

So I’m looking for a way to protect my Python source code while still allowing it to run completely on the client side. I’m aware that:

  • .pyc files can be decompiled.
  • Tools like pyarmor, cython, or nuitka offer obfuscation and compilation.
  • Docker containers or virtual machines can isolate the environment.
  • Writing critical logic in C/C++ extensions is another option.

My goals are:

  1. Prevent the client (or others) from easily viewing or copying my core logic.
  2. Avoid unnecessary complexity in deployment if possible.

:magnifying_glass_tilted_left: What I’m asking:

  • What are the best practices for this kind of scenario?
  • Has anyone dealt with code protection + offline usage before?
  • Is Nuitka or Cython strong enough to deter reverse engineering in practical terms?
  • Are there better or emerging methods in 2025 to achieve this?

Any guidance, suggestions, or real-world experience would be super helpful.

Then, sorry, you don’t have an option. If the code runs on the client’s computer, it IS accessible to them, and fundamentally there is nothing you can do to prevent them from reading it.

You might be able to make it harder for them to understand the code, but they will always be able to read it, and run it.

They can definitely copy the logic, no matter what you do to try to obscure it.

The ONLY way to stop people from reading your code is to not give it to them - which means running it on your own server. Your best bet will be to figure out some way of sending just some of their data to your server - or abandon the idea of keeping your business logic private. The two goals are at odds with each other.

3 Likes

In my experience being on the reverse-engineering end of proprietary software over the years, you’re tilting at windmills by trying to apply technical solutions to legal problems. Save yourself the hassle and don’t bother, just code the application in the most expedient means possible for ease of development and maintenance as, well as performance and usability. Then take the time and money you saved doing that to pay a lawyer to write up some legally-binding contracts that your customer is willing to agree to.

There is really no technical way to protect software that you put in the hands of someone else against being reverse-engineered, but there are accepted legal/contractual ways to do so which are commonly practiced by basically all commercial software companies.

6 Likes

Can you provide, or can they give you, an “internal” server, and white list a static IP address of yours or give you a VPN to the interior? And set up that server such that only you can access it over SSH, but from which you can provide your REST API?

Otherwise if the customer requires it to be written in Python, their requirements are almost contradictory, and I would just price in the cost of giving them visibility to the code I was writing for them.

I do find it quite strange, the idea of being paid to write code, that the person that pays me doesn’t then own.

On the other hand, if the decision to use Python is yours, perhaps that’s not the best tool for this particular job. Many other options are available, e.g. traditional compiled languages. Take the opportunity to broaden your horizons and learn something else?

Only production-ready code should be shared. If someone wants to reverse-engineer code or an executable, they can. It’s always been possible, and today, the process can be fully automated. Since the code will be shared among multiple individuals, it makes sense to host it in a public repository.