I deploy anything on “bare metal”, Elixir included, mainly via Ansible. Erlang and Elixir are, thanks to releases, one of the most painless things to ship to a server to me. To be fair, I am used to Python, and Python’s packaging story is, well, let’s say BEAM land is a nice place to be.
I wrote a blog post about it a while ago about deploying Elixir releases with Ansible, and the setup takes great care to follow Ansible best practices, like not reporting “xxx changed” when nothing did. I’ve been using it for years, and except for moving to Debian stable repos from ESL and some minor changes I did to it recently to make it work with hot upgrades via the excellent castle it is still unchanged, and works perfectly. Since I don’t want to just blogspam, here is my previous deployment that will:
- set up the postgresql database and database user for the app
- set up a deployment directory (it then keeps the previous 5 releases around via
deploy_helper, note that actually just making a new release for every commit is a lot more efficient than you think! check this commit for what I changed) - check out the git release, download prod dependencies, assemble a release, run migrations
- make the new release the “current” one (started by systemd)
- template service and systemd config
- start and enable the service (and restart if something changed).
Since you mentioned no PostgreSQL, you can pretty much just delete the postgres lines. Configuring haproxy is straightforward with Ansible - make a role with two tasks, one to install it, one to template some configuration, if the config changed, make your service manager reload it.
I have no intention of making a Google size company or running micro services with dozen services.
Just one server, and will do it manually if I have to.
I won’t touch Docker or Cloud ever again.
You do not need Docker or Cloud for running a company with dozens of services. I’ve worked at a place that had 3 digits of (mostly bare metal) servers on prem, mostly without Docker, deployed (mostly) via questionable shell scripts.
I am not a fan of the Cloud or Docker either, and love having a standard bare metal server to do what I want with. But I do not think it is right to say that they have no place or they will ruin your company due to costs / complexity / … . Each technology has its uses. I don’t think shell scripts are a good way to deploy software to 5000 hosts. I don’t think Kubernetes is a good way to deploy software to 5 hosts. But if it works for people, by all means, go for it. I’m happy with my setup 
About blue-green deploys - the simplest thing I can suggest: make a systemd template unit (myapp@.service instead of myapp.service) that takes the port somewhere on the command line or in the environment variables - then use the part after the @ to specify it: systemctl enable --now myapp@400{1,2}.service with Environment=PORT=%i will expand to one instance with PORT=4001 and another with PORT=4002. Or use hot code upgrade, if you want to go real fancy. I’m sure you can work with that.
Keep us posted what you end up with
