{"_id":"55bf8ff483675d17000b9b2e","project":"5589b4b0db0a020d00a75f8a","version":{"_id":"55bf8ff383675d17000b9b2a","__v":1,"project":"5589b4b0db0a020d00a75f8a","createdAt":"2015-08-03T15:59:47.166Z","releaseDate":"2015-08-03T15:59:47.166Z","categories":["55bf8ff483675d17000b9b2b"],"is_deprecated":false,"is_hidden":false,"is_beta":false,"is_stable":true,"codename":"","version_clean":"0.18.0","version":"0.18"},"category":{"_id":"55bf8ff483675d17000b9b2b","pages":["55bf8ff483675d17000b9b2c","55bf8ff483675d17000b9b2d","55bf8ff483675d17000b9b2e","55bf8ff483675d17000b9b2f","55bf8ff483675d17000b9b30","55bf8ff483675d17000b9b31"],"version":"55bf8ff383675d17000b9b2a","__v":1,"project":"5589b4b0db0a020d00a75f8a","sync":{"url":"","isSync":false},"reference":false,"createdAt":"2015-06-23T19:34:09.101Z","from_sync":false,"order":0,"slug":"documentation","title":"Documentation"},"user":"5589b346986b6c0d00f54355","__v":0,"updates":[],"next":{"pages":[],"description":""},"createdAt":"2015-07-05T05:20:53.476Z","link_external":false,"link_url":"","githubsync":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":2,"body":"A quick word of warning: It is currently not supported to perform hot upgrades/downgrades from the `rel` directory. This is because the upgrade/downgrade process deletes files from the release when it is installed, which will cause issues when you are attempting to build a release of the next version of your app. It is important that you do actual deployments of your app outside of the build directory if you plan on using this feature of releases!\n\nFirst lets talk about how you can run your release after executing `mix release`. The following example code is based on the [exrm-test project](https://github.com/bitwalker/exrm-test):\n\n```\n> rel/test/bin/test console\nErlang/OTP 17 [erts-6.0] [source] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:10] [hipe] [kernel-poll:false] [dtrace]\n\nInteractive Elixir (1.0.5) - press Ctrl+C to exit (type h() ENTER for help)\niex(test:::at:::127.0.0.1)1> :gen_server.call(:test, :ping)\n:v1\niex(test@127.0.0.1)2>\n```\n\nAs you can see from the above example, running the `console` command allows you to boot your release with an `iex` console just like if you had run `iex -S mix`. This allows you to quickly test and play around with your running release build!\n\n\n### Deployment\n\nNow that you've generated your first release, it's time to deploy it! Let's walk through a simulated deployment to the `/tmp` directory on your machine:\n\n1. `mix release`\n2. `mkdir -p /tmp/test`\n3. `cp rel/test/releases/0.0.1/test.tar.gz /tmp/`\n4. `cd /tmp/test`\n5. `tar -xf /tmp/test.tar.gz`\n\nNow to start your app:\n\n```\n$ bin/test start\n```\n\nYou can test if your app is alive and running with:\n\n```\n$ bin/test ping\n``` \n\nIf you want to connect a remote shell to your now running app:\n\n```\n$ bin/test remote_console\n```\n\nOk, you should be staring at a standard `iex` prompt, but slightly different, something like:\n\n```\niex(test@localhost)1>\n```\n\nThe prompt shows us that we are currently connected to `test@localhost`, which is the value of `name` in our `vm.args` file. Feel free to ping the app using `:gen_server.call(:test, :ping)` to make sure it works (just to recap, this is based on the example app described above, your own application will not have this function available).\n\nAt this point, you can't just abort from the prompt like usual and make the node shut down (which is what occurs when you are doing this from the `console` command). This would be an obviously bad thing in a production environment. Instead, you can execute `:init.stop` from the `iex` prompt, and this will shut down the node. You will still be connected to the shell, but once you quit the shell, the node is gone.\n\n### Executing code against a running release\n\nIf you want to execute a command against your running node without\nattaching a shell you can do something like the following:\n\n```\n$ bin/test rpc erlang now\n```\n\nor\n\n```\n$ bin/test rpc calendar valid_date \"{2014,3,14}.\"\n```\n\nNotice that the arguments required are in module, function, argument\nformat. The argument parameter will be evaluated as an Erlang term,\nand applied to the module/function. Multiple args should be formatted as\na list, i.e. `[arg1, arg2, arg3].`.","excerpt":"How to deploy your release","slug":"deployment","type":"basic","title":"Deployment"}

Documentation

Deployment

How to deploy your release

A quick word of warning: It is currently not supported to perform hot upgrades/downgrades from the `rel` directory. This is because the upgrade/downgrade process deletes files from the release when it is installed, which will cause issues when you are attempting to build a release of the next version of your app. It is important that you do actual deployments of your app outside of the build directory if you plan on using this feature of releases!
First lets talk about how you can run your release after executing `mix release`. The following example code is based on the [exrm-test project](https://github.com/bitwalker/exrm-test):
```
> rel/test/bin/test console
Erlang/OTP 17 [erts-6.0] [source] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:10] [hipe] [kernel-poll:false] [dtrace]
Interactive Elixir (1.0.5) - press Ctrl+C to exit (type h() ENTER for help)
iex(test@127.0.0.1)1> :gen_server.call(:test, :ping)
:v1
iex(test@127.0.0.1)2>
```
As you can see from the above example, running the `console` command allows you to boot your release with an `iex` console just like if you had run `iex -S mix`. This allows you to quickly test and play around with your running release build!
### Deployment
Now that you've generated your first release, it's time to deploy it! Let's walk through a simulated deployment to the `/tmp` directory on your machine:
1. `mix release`
2. `mkdir -p /tmp/test`
3. `cp rel/test/releases/0.0.1/test.tar.gz /tmp/`
4. `cd /tmp/test`
5. `tar -xf /tmp/test.tar.gz`
Now to start your app:
```
$ bin/test start
```
You can test if your app is alive and running with:
```
$ bin/test ping
```
If you want to connect a remote shell to your now running app:
```
$ bin/test remote_console
```
Ok, you should be staring at a standard `iex` prompt, but slightly different, something like:
```
iex(test@localhost)1>
```
The prompt shows us that we are currently connected to `test@localhost`, which is the value of `name` in our `vm.args` file. Feel free to ping the app using `:gen_server.call(:test, :ping)` to make sure it works (just to recap, this is based on the example app described above, your own application will not have this function available).
At this point, you can't just abort from the prompt like usual and make the node shut down (which is what occurs when you are doing this from the `console` command). This would be an obviously bad thing in a production environment. Instead, you can execute `:init.stop` from the `iex` prompt, and this will shut down the node. You will still be connected to the shell, but once you quit the shell, the node is gone.
### Executing code against a running release
If you want to execute a command against your running node without
attaching a shell you can do something like the following:
```
$ bin/test rpc erlang now
```
or
```
$ bin/test rpc calendar valid_date "{2014,3,14}."
```
Notice that the arguments required are in module, function, argument
format. The argument parameter will be evaluated as an Erlang term,
and applied to the module/function. Multiple args should be formatted as
a list, i.e. `[arg1, arg2, arg3].`.