Ask
249
@borrowck_ben ·

builds fine on my m2 and dies with exec format error on the hetzner box, what is the least painful fix

Plain docker build on an Apple Silicon laptop, pushed to a registry, then compose pull on an amd64 vps and the container exits immediately with exec format error. I have seen --platform, buildx and just build on the server all suggested and they clearly have wildly different costs. Deploys happen maybe twice a week and always from the laptop. Which of these do people actually live with long term?

8 answers Share
Report

Answering anonymously — a moderator will review it first.

  • @rackmount_rina · 5d ago · 3 replies

    Short term fix is one flag: docker build --platform linux/amd64 on the laptop. It works, it produces the right image, and it is slow, because your Mac is emulating amd64 through QEMU for every instruction of the build. For a small Node or Go image that might mean a build going from one minute to five, and for anything that compiles native extensions it can be much worse than that. If you can live with five minutes twice a week, this is the correct answer and you should stop reading. If you cannot, the real answer is to stop building on the laptop at all.

    198
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
    • @borrowck_ben · 5d ago

      It is a node app with a couple of native deps so I suspect it is the much worse case. Timing it now.

      46
      Share
      Reply

      Answering anonymously — a moderator will review it first.

      Report
    • @rackmount_rina · 5d ago

      Native modules under QEMU are where this gets painful. If it is over ten minutes, go straight to CI and skip the middle option.

      52
      Share
      Reply

      Answering anonymously — a moderator will review it first.

      Report
  • @uptime_hoarder · 6d ago · 2 replies

    Build in CI on an amd64 runner and this problem disappears permanently rather than being managed. Push to a branch, the runner builds natively at full speed, pushes to your registry, and the vps pulls. It also gets the build off your laptop entirely so deploys work from a phone or a train, and you get a record of what was built and when. Most hosted CI has free minutes that comfortably cover twice weekly builds for one small service. The laptop build is the thing causing the problem and every other answer is working around it.

    176
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
    • @yaml_yusuf · 4d ago

      This is what I settled on too. The unexpected benefit was that deploys stopped depending on whatever half installed state my laptop was in.

      43
      Share
      Reply

      Answering anonymously — a moderator will review it first.

      Report
  • @cookie_domain_al · 4d ago

    If you want to keep building locally, use buildx with a builder that can emit both architectures and push a manifest list, so the registry holds one tag pointing at an arm64 image and an amd64 image. Then your Mac pulls arm64 for local runs and the vps pulls amd64 automatically and nobody has to remember a flag. That is the properly engineered version and it is worth doing if you also run the image locally. It does not make the emulation faster, it just means you get both artefacts out of the same build for the price of the slow one.

    143
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
  • @attic_server · 3d ago

    I did the build on the server route because it seemed simplest and it worked for about six weeks. Then the app grew, the build started needing more than the 2GB the box had, and the OOM killer took out Postgres in the middle of a build one evening. Building on the machine that is also serving traffic is the kind of decision that is fine until it is very much not fine, and you find out at the worst moment.

    128
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
  • @sql_window_fn · 2h ago

    docker image inspect and look at Architecture before you deploy anything. Two seconds, and it turns this whole class of problem into a check rather than an incident.

    1
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report