Why and what env_vars to set while creating a mix release?

I am trying to create a mix release of a Phoenix project on my dev machine with plan to somehow send it to my prod VPS. According the the documentation, one of the steps is to set the DATABASE_URL env var.

$ export DATABASE_URL=ecto://USER:PASS@HOST/database

What Database should I give here? myapp_dev or myapp_prod ? I only have myapp_dev on my dev machine.

Set it to the database you want to connect to.

Its probably your development DB locally and your production DB on the production machine. But how exactly you want to deal with things is mostly up to you.

I am already connected to the dev db on dev machine. There is no point running the release on dev. i am just creating the release so that I can send it to prod laterand then hopefully the release can talk to prod DB that I have already created there. So does that mean I should put prod db in the Database url ?

The environment variable as used there is your configuration, so of course you need to set it to whatever you want your release to connect to.

When you say “there” do you mean dev or prod machine ? I dont have any env on dev because well It is dev - everything hard coded. I only have env vars on prod machine. Sorry about my lack of understanding. Deployment of phoenix is way harder than RoR.

I’ve not fully read that guide, but I’d expect database to be runtime or boot time configuration, therefore I’d set it on the prod.

But its easy to find out… Look at your config files. If the env var is read from in config/release.exs, you have to set it on the prod before starting the release. If its in config/{config,prod}.exs then it is a build time configuration and you need to set it when compiling the release.

The problem with the latter set up is, that you need to rebuild and redeploy your application when the DB changes.


Also I do consider deployment on ruby much harder, as it often requires to install a lot of dependencies globally and even worse, development versions of libraries and a compiler in the production machine, as gems with native extensions might need compilation on installation.

2 Likes

I have my DB credentials hard coded in config/dev.exs to conect to dev DB. Are you suggesting to create config/release.exs and put the DATABASE_URL to read env vars in prod machine ?

It should be configured that way by default.

Sorry can you elaborate - What should be configured what way ?

We are talking about production configuration, so config/dev.exs is not relevant here. But as I said, config/prod.exs is relevant for your production build.

Also if you ask me I’d not use the system environment at all to configure, but a configuration file that I read from during application boot, using config providers.

I couldnt understand your 2nd statement. Do you mean you dont like to use env vars and instead you hard code your secrets in a configuration file in prod ? What is a config provider ?

A configuration provider is a module that implements a behavior.

Functions in that module are called during application boot. They can run arbitrary code to inject into the application environment.

I tend to read from a JSON file, though I’d like to transition to dhall, though I need a proper Dhall evaluator written in elixir first :smiley:.

In general I try to avoid config/* for prod, as the system has its flaws, and is used “wrong” by some libraries and tools.

For production I try to keep it clean from all runtime configuration and only put compiletime configuration there, which I’d prefer to not have it at all…

Also config providers even enable you to get credentials for the DB or other auxiliaries via vault or similar services, and you can do it in elixir, without having to retrieve it via external means and inject it in the system environment.

I recommend you to read this doc https://hexdocs.pm/phoenix/releases.html
It’s very helpful to understand how to build phoenix with mix release.

Let me know if it’s helped you.

this is the documentation I have linked my post. This is the documentation where they are setting the env vars. DATABASE_URL. and coming back to square one I had asked if I should set my dev db or prod db

Sorry :sweat_smile:.
The simple answer is you should use your prod db.

Sorry I am not as advanced yet to be able to understand your response, but can’t thank you enough for your patience :slight_smile:

There you go, thanks :smiley:

1 Like

Hehe.
A longer answer is,
If you build that release to use on production then you should put your prod db. Else if it’s only for testing or something like that you should put your dev db or staging db or something else.

Yes of course, releases are build to be used only on production right ? Why would people run the release on dev when they can do mix phx.server ?

Probably not on dev, but on a kind of staging, which again might be the same physical machine as dev, or prod, or something else…

1 Like