Is there a way to protect, somehow, the source code of a Phoenix web app?

Let’s say, there’s a server I have access to and which belongs to a customer. I’ve set up and launched a Phoenix app on it.

Because of our agreement with a customer, I’m not obliged to provide the source code of an app. The only thing I have to do is to lauch it end ensure that it works. Besides, I have a reason to try to protect the source code.

Question: how could I a) protect, or b) make it more difficult to get access to

the source code of said application?

More concretely:
1.1) Is there a way to distribute an app in the compiled form only?

I know how to build a release manually, and I’ve done it. However, there’re so many files there in it, and I don’t know which ones are essential for an app to run, and which aren’t.

1.2) Is there a way to also obfuscate the source code? Whether it be before, during or after compilation.

I’m aware that the maximum I could do is to make it more difficult to access the source code, or understand it. rather than protect it completely. And this is fine.

P.S. My local OS-es and the one on a server are identical. Therefore, I can compile a release locally. And I can set up all the env. locally as well.

There are tools to decompile the beam files. There are several threads around asking this same question which you might want to check out. Short answer is: no.

Could you restrict access to the location of the files somehow?

1 Like

There are tools to decompile the beam files

That’s fine because a compiled version only on customer’s server will always be better than source code anyway. A customer may not be that tech-savvy to decompile it.

So – is it possible to have a compiled version only on a server to run an app?

How? A server belongs to a customer.

I thought you might be managing it for them.

In some cases I could, but I wouldn’t rely on it.

Technical solutions can only put minor obstacles in the way. The correct tool for this is called “contract law”, and it doesn’t involve any software changes.

If you’re still interested in putting the obstacles in, it would be useful to think through exactly what you’re aiming to prevent. For instance, just writing really poorly-structured code with confusing function names would prevent anybody from understanding but that probably isn’t what you want :stuck_out_tongue:


When you build a release (e.g. using mix release) it won’t include source-code.


If I understand you correctly you don’t want a perfect solution, but just something that makes your source code opaque to someone with no technical background.

Maybe the following project will interrest you then.

1 Like

Using Burrito could be an obstacle. It will appear as an executable that will self extract. Bakeware has been superceded by Burrito, in a sense

1 Like

Thank you for sharing. :+1:

Burrrito seems also to be more actively maintained.

Alright. now it’s become clear

Yes. Now, more concreately still:

  • without sacrificing performance
  • a solution must not be paid, nor difficult to use, nor difficult to set up

Bakeware, for instance, will make an application less performant, won’t it?

Isn’t there a library out there that obfuscates Elixir code? The way the libraries do it with JavaScript code.

I remember when I was searching for a code obfuscation solution for Adobe flash byte code.

I couldn’t find one for Elixir.

ActionScript Obfuscator and Flash Protection

These tools are usually what will cost you performance.

Technical solutions can only put minor obstacles in the way. The correct tool for this is called “contract law”, and it doesn’t involve any software changes.

Anecdotally (I don’t have a source to back this up, I just heard it from an old coworker), Github’s on-prem enterprise employs this solution. They strcitly monitor ssh access to the box that runs GHE, and you’ll get an angry phone call wanting to know why you SSH’d in if you do so for an unknown reason. Their stuff is all Ruby, so I have to imagine the same reasoning is at play here.

Some posts have been removed.

@tirana, please be considerate towards those taking time out of their busy day to contribute to a thread you’ve posted. If somebody replies with something that wasn’t quite what you were looking for you can just ignore it - it’s quite possible that that same piece of information might help someone else reading the thread in future. Please keep in mind we are a nice friendly community here :smiley:


This leads me to think Elixir is your first compiled language. Use a release, and there will be no source code, just .beam files. Yes, they’re vulnerable to disassembly, but it is some sort of barrier.


To add to the comment from @gregvaughn

A release doesn’t have source code. mix release compiles the code and transfers it to the release folder. Pretty much all the files bundled into the release folder are required for it to run. The release task goes to some effort to remove unnecessary stuff. From the docs on “why releases?” (mix release — Mix v1.14.2):

Self-contained. A release does not require the source code to be included in your production artifacts. All of the code is precompiled and packaged. Releases do not even require Erlang or Elixir in your servers, as it includes the Erlang VM and its runtime by default. Furthermore, both Erlang and Elixir standard libraries are stripped to bring only the parts you are actually using.

The main downsides of building and shipping releases that I’ve experienced are:

  1. You have to build on the same architecture that you are distributing to.
  2. If the contents of runtime.exs are different for each installation (highly likely) you need to remember to apply them again after each update, or (better) use environment variables for the settings.
  3. The compiled code can be decompiled, but this requires some know-how and effort.

Just to pile on.

1.1) mix release does that. Note that bundled in a release is the VM itself (:include_erts option defaults to true), this is probably contributing to the ‘so many files’ you see. As mentioned above there should be no source/docs in there, but I’m not an expert on releases.

1.2) I’m not aware of any Elixir obfuscation software, but at a minimum debugging symbols are already stripped from the release (:strip_beams option defaults to true) which may help make decompiled code less readable.

As mentioned above, if you packaged up a release in bakeware/burrito, that would increase the barrier… but if the customer is going to go as far as understanding decompiled BEAM, then something equivalent to an app.tar.gz isn’t going to provide much challenge.

1 Like

Hey guys,

Is Firefly from Dockyard going to help?

Firefly (formerly known as Lumen), gives developers an alternative compiler to the BEAM. It allows developers to capitalize on Elixir’s inherent distributed systems capabilities and offers new levels of efficiency and speed for compiling Elixir applications.

1 Like