How are you doing production deployments?

The way we do it at my job is create a release (via exrm), we have a special config build on the build server that connects to the prod database, backs it up, migrates it up, then copies the release over and applies it (ordering is a bit different), and we only have one server for web hosting, if it goes down we have bigger issues here anyway so we would not care (even then we would not care that much except during certain times of the year).

Only rolled back once, it was manually done.

I haven’t deployed any Elixir apps myself yet but there are a couple of stickies in this section that might be of help:

And this is a popular thread about where to deploy:

We use distillery to create a basic release, from that we build an RPM and push it to a repo. For everything else we use ansible to manage - that includes configs, migrations etc. The group_vars / host_vars functionality of ansible is perfect for deployment to multiple servers and environments.

Rollbacks are also handled with ansible, by specifying a version number as a variable.

I just finished setting up my first production Elixir deploy so I thought I’d share my approach in case it’s helpful to other beginners, especially those coming from the Ruby world, where there is a widely dominant pattern developed in Capistrano, Mina etc.

Basically I wanted something similarly simple, but more flexible. For context, this is not a mission critical application so I had some room to experiment. I knew I wanted to go with ansible, but mainly because I already had experience with it and I’ve been satisfied. I haven’t properly compared it to other tools though. But its deploy_helper module made it really easy! The result was an extremely small playbook:

Some notes:

• Requires user with sudo access
• Uses somewhat awkward script for env management, but I wanted to keep my production env vars in a separate file and this seemed like the easiest way
• Erlang/Elixir managed with asdf. There were some minor gotchas around setting the PATH properly so these settings were respected by the ansible session
• Requires a migrate task to use with bin/my_app eval as described here
• Uses systemd to manage app process

Overall it is not the robust approach and I’m sure I’ll be making improvements. It doesn’t handle server provisioning or separate build environments or anything like that, but it seems to work well as a starting point if you just want to get your app deployed in production to linode etc instance.

This is super useful, thank you! I use Ansible on pretty much a daily basis and I didn’t know about deploy_helper before.

I found that building a release in new_release_path during each deploy takes quite some time though, so I switched to cloning into shared_path, building the release there, then copying the release (from _build/prod/rel) into new_release_path. I’m also lazy so I just run mix ecto.migrate --all instead of a custom release task.