Options for Building Erlang/OTP for a Phoenix application

When building Erlang/OTP (using asdf/kerl) for production server serving a (presumably typical setup of a) Phoenix application, what KERL_CONFIGURE_OPTIONS would you suggest to use from the list of available ones?

Application is a typical web application with PostgreSQL as data source.

I’d take --without-wx --without-javac are rather safe in such case? Anything else can be skipped?

1 Like

Nobody? Nothing? How do you guys install prod environment? Always precompiled image? Or?

I use releases for all of my deploys. I don’t see any reasons not to embed the runtime together with all your compiled codebase.

The only case where I use a locally installed elixir+erlang is for CI, in my case docker images from hexpm or docker hub.

I use releases too, but to embed the runtime I need to have it first. So I use docker “builder” image, which gets Erlang/Elixir compiled and then this builds the “runner” image, using its runtime. So the question is about where / how to get the slimmest runtime for embedding into production image

The release does trim down the „runtime“ already. Only erts and otp applications your project depends on will be added. No need to optimize your kerl options.


OP probably means certain options that maybe reduce memory allocation latency or other some such that might be more relevant in containerized conditions, maybe. They are runtime flags, not compile-time, but still.

I admit ignorance on the topic however. I’ve seen posts from core Erlang contributors here on this forum and they can likely be dug up, but even they were not comprehensive.

Do you mean there are no differences between Erlang/OTP compiled with everything enabled but then “trimmed” down by releases and one compiled with minimal set of options required for the phx application in question? While that in itself would be great,

  • I saw final image sizes differ when using different build options. Need to double-check if I am not imagining things now but am like 90%+ sure
  • The build/install time reduction may also be worth a bit of trouble. True that doesn’t have to be done every time, but still