That’s exactly the reason why I push all my builds to CI from day 1. Usually the free plans are enough for my private stuff and for non private stuff a few bucks a month should be doable. No need to worry about where and how I do my edits, could even be the built in editor of the service hosting the repo for what it’s worth. I totally see that being a bit more work upfront, but it’s documented in code and rather flexible.
LostKobrakai
cjbottaro
Not only slow, but I’ve never got it to actually work for me. It always ends up crashing for some reason.
I’m in the camp of just letting your CI build the images (we use GitHub Actions).
Kind of an aside, but related… BuildKit lets you make multiarch images pretty easily, using a Kubernetes cluster to farm out the build jobs to machines of different architectures. My M1 is so fast though, that I like to do the ARM build locally though. I have a little bash script to help with this.
Build ARM locally, then use a BuildKit Kubernetes builder to build AMD64 and mash them together in to a multiarch image:
# mbuild <dir> <repo> <tag>
# mbuild elixir $AW_REGISTRY/1.14.0-erlang-25.0.4-alpine-3.16.1 latest
set -e
TAG=${3:-latest}
docker build $1 -t $2:arm64
docker push $2:arm64
docker buildx build $1 \
--push \
--platform linux/amd64 \
-t $2:amd64 \
--builder aw-amd64-builder-
docker manifest create $2:$TAG \
--amend $2:amd64 \
--amend $2:arm64
docker manifest push --purge $2:$TAG
1
Nicd
Thanks everyone for the answers, I hope they are also useful for any future readers that might find this thread. 
I ended up building the release in GitLab CI which was surprisingly painless. I haven’t tested deploying the artifact yet, though, but it looks sensible enough when extracted. 
2
Nicd
Oh, and here’s the configuration I ended up with (permalinked to the current version, so maybe check if it has changed if you come from the future): .gitlab-ci.yml · e037b3c8245f2db487a13539062de726749b6156 · CodeStats / code-stats · GitLab
Let me know if you think I could do something better!
2
s6o
Very very slow 
I’m in a similar situation, my cloud infra is x86_64 (Ubuntu) and cannot just build on my M1 mac mini. So I also tried UTM on M1 with x86 emulation … its was pretty much unusable for builds.
So I run my builds on my 2015 intel MBP, which runs UTM (virtualization) for the same architecture. The UTM instance is running Lubuntu and my builds are way faster than on M1
1
jbriggs
I build releases for ARM systems on an x86 build server.
I take the files for the ARM system’s ERTS, place them on the build server and then reference them in the release I am building.
Here is a snippet from the mix.exs, “releases” section:
releases: [
sra_rps: [
overwrite: true,
include_executables_for: [:unix],
# Keep the docs
strip_beams: [keep: ["Docs", "Dbgi"]],
# Path to the ERTS copied from ~/.asdf/installs/erlang/24.2.1
include_erts: "/usr/local/share/erlang_rps/erts-12.2.1",
...
The only provisio is that building any NIFs or port programs becomes much more complicated. The only port programs I have are very stable, never needing changes, so I include compiled versions as binaries in priv.
3
derpycoder
I was reading how others are doing it, and here’s what I gathered.
- We can use GitHub Action-like services.
- We can build directly on the server and replace the instance.
- Blue/Green deployment using 2 VPS. (Spin up a new VPS, that is identical to the running VPS, and deploy in that VPS like it’s staging, then replace the running VPS with the newly spawned one or move the artifact across. (Shutdown the VPS we are not using))
- Blue/Green deployment, but using tools like Packer & Terraform.
We can use tools like SCP, S3, CROC to move our build artifacts across servers.
P.S. Still learning by experimenting with all the ways to do it.
1
derek-zhou
I always have a pc at home, powered-on, reversed ssh tunneled to one of my VPS. So I do not use my MacBook to build the release, even mine is x86.
2
michallepicki
I succeeded recently in building a release on a Apple Silicon Mac inside a UTM emulated x64 system (I used Ubuntu Server, to not waste cycles for a GUI when emulation is so slow). But for this particular service we don’t care about performance, so it was more convenient to use Docker with Erlang built from source with the JIT disabled. The asdf / kerl flag I used in my Dockerfile was:
ENV KERL_CONFIGURE_OPTIONS "--disable-jit"
This allows to avoid the qemu Erlang JIT issue.
1
michallepicki
Looks like there’s a better way. This didn’t work for me on Erlang/OTP 25.1.1 but seems to have worked on 25.3.2.2
0