I’m not a memory management guru either, but I’m pretty sure processes don’t get killed unless absolutely needed and from what we can deduct it’s pretty clear that it’s the case here. OOM killer just tries to save the system while doing least possible damage: http://unix.stackexchange.com/questions/153585/how-the-oom-killer-decides-which-process-to-kill-first
So I think the crush dump does not mean that it only used 50mb while being killed, what it means is that “last thing it remembers” was using 50 mb and then it probably needed much more and got killed. See this thread http://erlang.org/pipermail/erlang-questions/2012-August/068477.html - when killed by OOM the dump might not have the most current info.
After (if) you reproduce the crush, check if the app has any in memory structures that might cause a problem - agents ets tables etc that are not properly managed. 500mb is not that much but we have few smaller apps running on such droplets and they have no problems (some of them do a lot though) so it’s possible there is a solvable problem here.
The fact that erlang just gets killed when it runs out of memory is also seemingly by design, the root “let it crash” case 
You can supervise the app and restart it automatically, we even happen to have a wiki for that Elixir apps as systemd services - info & wiki but I’d really try to find the issue before setting it up.
