Setting the elixir node cookie value with `RELEASE_COOKIE` instead of with a mix release profile option.

I’m a bit confused about the suggested way to set the elixir cookie value. The documentation suggests setting the cookie value with a mix release option. But that seems a bit strange to me, because when you want multiple environments, now you have to juggle multiple release profiles too (which has an impact on your Dockerfile, because now you have to pass in a RELEASE_NAME to mix release, and your release scripts are named after that RELEASE_NAME variable).

I found it much easier to just set the RELEASE_COOKIE variable (either as a secret, or as a regular environment variable in fly.toml), which is available anyway at runtime. As documented in the mix release docs about the :cookie option, it takes precedence over the value in releases/COOKIE (which will have a random value, but that’s ok, if you set the RELEASE_COOKIE env variable).

Am I overlooking something here?

Hi @linusdm,

Setting the cookie using an ENV is fine. When you say, “because when you want multiple environments”, I assume you are referring to environments like staging and production?

If so, we recommend using a separate Fly Organization for the production and staging. Why? An organization also creates a fully isolated IPv6 network. This absolutely prevents a staging build from running a migration on your production database that breaks your production system.

However, if using an ENV for setting the cookie works for you and your team/project, that’s fine.

1 Like

Hey @Mark!

Thanks for clarifying. I still think the documentation page about “the cookie situation” is needlessly complex. Here it says:

The easiest solution here is to specify the value to use for our cookie. One that we will know outside of the build and that won’t keep changing on us.

Which is ok. But then the document suggests changing the release options, which works, but it’s not the easiest solution, I think. The easiest solution is just throwing in the RELEASE_COOKIE env, and it’s done.

You’re absolutely right that a separation on the network level would have been a better option, in my case (indeed, separating production and staging). I’m gonna take that knowledge with me the next time I set up such environments. Thanks for taking the time!

1 Like

Thanks for sharing that insight. Yes, the docs could be simplified. :slight_smile:

1 Like


Thanks for the tip and pointing out the resource! I updated the docs with the simpler approach. I tested it and verified it worked as expected. :+1:


That’s awesome! Thank you.

1 Like