No internet connection
  1. Home
  2. Support

Talkyard on ARM64?

By Noah Langenwalter @NoahLangenwalter
    2026-06-17 07:21:31.387Z

    I think I goofed. I'm experimenting with my first VPS and thought it would be fun to try arm64. I found out the hard way that the docker images are built for linux/amd64. Is anyone running Talkyard on ARM? If so, can you point me to any guides? I'm guessing I could try building my own images...

    Thanks!

    • 4 replies
    1. I've never built Talkyard for ARM. I'd guess it'd be annoyingly much work to get it working.

      Did you install v0 or v1? I'm just going to try out the restore-backup instructions for v1 thereafter v1 will get released

      If you installed v0, you'd save time if you install v1 from scratch anyway (on amd64 then), rather than upgrading from v0 to v1

      1. NNoah Langenwalter @NoahLangenwalter
          2026-06-19 22:48:57.040Z

          Thanks for the reply!

          Yes, I installed v1. I'll switch over to an amd64 server for now and try again.

          1. What happened? Did it work for you on amd64

            (Just started testing the backup & restore scripts, found a pretty harmless bug)

        • @IvanTheGeek
            2026-07-20 02:51:50.213Z

            Some follow-up on this: I got curious and had a serious go at ARM64/aarch64 recently.

            @KajMagnus — you guessed it'd be annoyingly much work. Happily, it turned
            out not to be, and the main reason is that the Talkyard code needed zero
            changes
            . It's a packaging job, not a porting job: the only
            architecture-specific thing in the whole tree is the ElasticSearch base
            image tag (9.3.1-amd64); every other base (Temurin, rust, alpine,
            postgres, redis, node, golang), OpenResty/LuaJIT, and even the jffi native
            lib that libsodium/PASETO goes through already supports arm64. The published
            Docker Hub images are amd64-only though, so running on ARM means building
            images yourself.

            The building is where my own (entirely unofficial, unsanctioned-by-upstream)
            fork tooling comes in: I extended the Docker-only build wrapper I've been
            using with an --arch arm64 mode — sbt and gulp still run native since
            their outputs are arch-independent, and only the image assembly targets
            arm64 via qemu/binfmt. A full stack built that way is running behind a
            reverse proxy right now, all containers reporting aarch64, and my CI
            rebuilds + boot-smokes the images nightly. You can poke at it yourself:
            https://arm64.talkyard.dev.ivanthegeek.com — with the disclaimers
            that it's noticeably slow (qemu emulation on an already-busy dev VPS, not
            real ARM hardware) and I make no promises about how long I'll keep it up;
            it's an experiment, not a service.

            @NoahLangenwalter — if you still have that arm64 VM (or a Pi): I wrote up a
            step-by-step install with the ARM-specific gotchas, and the images are
            anonymously pullable from my registry:
            https://github.com/IvanTheGeek/talkyard/blob/docker-only-build/docs/arm64-install.md
            (or the same doc on my Forgejo: https://forgejo.ivanthegeek.com/ivan/talkyard/src/branch/docker-only-build/docs/arm64-install.md )
            Fair warning: experimental, community-built, keep backups.

            Discussion lives on my own forum (which runs Talkyard, naturally) — the
            HOWTO thread for questions/reports:
            https://forum.ivanthegeek.com/-209/howto-run-talkyard-on-arm64-raspberry-pi-apple-silicon-experimental-images
            and the original "how hard would it be?" audit that kicked this off:
            https://forum.ivanthegeek.com/-208/how-hard-would-it-be-to-build-and-run-talkyard-on-arm64-eg-a-raspberry-pi

            To be clear, none of this is blessed by the Talkyard project — it's my
            experiment on unchanged upstream v1 code. But the "how hard is it" question
            now has an empirical answer: one base-image line plus build tooling.

            This post crafted with assistance from Claude AI