Can you use nerves to deploy a cloud-based server?

Tags: #<Tag:0x00007f49400dc268>


So from watching all the #elixirconf2017 videos I’ve gotten very interested in playing with Nerves but haven’t had an opportunity yet. But a user on reddit mentioned that Nerves supports x86_64 machines now and was wondering if it would be possible to use Nerves to deploy to a cloud-based server:

I think the idea is really tantalizing, does anyone have an idea as to the feasibility? I’m sure it would work on a co-located server but something like AWS probably wouldn’t support it.


I played around with deploying Nerves “firmware” to the cloud a while back. My notes are here: I originally looked at deploying to AWS, and it seemed feasible but I got a little lost in Amazon terminology. Getting something to work on Vultr was easy so I went there instead.

Some takeaways from doing this were:

  1. It’s definitely possible.
  2. Server hardware and networking are simpler than what we have to deal with in the embedded use cases, so there are opportunities to streamline the tooling and base libraries for ease-of-use.
  3. Bootstrapping servers to work with Nerves needs work. For Vultr, I have an iPXE script to load the first image, but it’s really tedious to use. From there on, you can update it via nerves_firmware_ssh which is easier.
  4. I don’t know enough about server deployment and operations to know what should be in the base Nerves image and what all is expected in the tooling. For example, it’s possible to put Postgres in the base image (per the reddit post), but I’m not sure that’s desirable. It seems easier (to me) to have a dedicated server for the database rather than combining it.

Anyway, Nerves in the cloud hasn’t been a focus for me, but if others want to pursue it, I certainly would help on low level details.



Could you deploy it on top of a FROM scratch docker container?

Asking for a friend.


A friend told me that it’s possible with enough hackery. The main issue had something to do with getting erlinit to play nicely with Docker. Unfortunately, they did this a while ago and didn’t remember any more details.

If you’re looking into this, erlinit is a minimal init process for Nerves devices. A few minimal init projects exist for Docker like dumb-init and tini, so there may be a hint in one of them. If you or anyone finds out what’s needed, please file an issue on the erlinit Github.


Any update on this topic?

Anyone successfully adapted Nerves to run on bare metal or VPSes?

I’m not sure about the local dev option, but the possibility of provisioning a production server this way would save so much work on so many levels.


I’ve pretty much abandoned this due to lack of interest. My notes for deploying to a Vultr VPS are still around, but I haven’t kept the Nerves system up with the latest Nerves 1.0-rc updates so there might be some small breakages. Don’t let me dissuade you from exploring this route, though. Many aspects of deploying small self-contained “firmware” bundles to servers appeals to me too, but there’s quite a bit of work left to make this usable in a real environment.


@fhunleth If updated and done right, could this be a replacement for using Docker?


I doubt it. Nerves has a very self-contained and static view of the world: the root filesystem is read-only, adding some OS packages can be non-trivial (no apt-get), and Elixir or Erlang control pretty much everything rather than more standard things like systemd and other Linux tooling. If your server doesn’t have many non-Elixir dependencies and you feel that existing tooling is heavy weight, I can see a Nerves approach appealing to you.

Fwiw, I’d also explore modifying Nerves to output a Docker image. Since the image wouldn’t need a Linux kernel or bootloader, it would even be more minimal - containing only the C runtime libraries, ERTS, your beams, and cross-compiled ports&NIFs. However, it would hook into existing infrastructure built around Docker and that seems useful.


Thanks, I had to ask because I’m trying to find a way to avoid using Docker and in some aspects the OTP appears superior for networking.