go-appimage, the AppImage toolchain rewritten in Go

Two tools, one of them a daemon

The repository is an implementation of the AppImage tools written in Go by the inventor of the AppImage format, which is a detail that explains both the design and the tone of the documentation. There are two programs, each with its own README. The first is appimagetool, a tool to deploy dependencies into AppDirs, including things like Qt, Gtk and GStreamer, and to convert AppDirs into AppImages. The second is appimaged, an optional daemon that integrates AppImages into the system, shows their icons and makes them executable. The split reflects the two halves of the format. Building an AppImage is a packaging step that runs on a developer machine or in CI, while integrating one into a desktop is a per-user concern that belongs in the session. The README also notes the download location, with binaries published under the continuous release tag rather than a versioned release, so the tools are consumed as moving targets.

The Go argument, in the author's own list

The README has a section explaining why the implementation is in Go, and the reasons are specific rather than ideological. The first is that Go follows the keep it simple principle, which the author says is in line with what they like. The second is the one with the most practical consequences, that Go compiles code to static binaries by default, so there is no messing around with shared libraries that tend to break on some target systems, with the example given being converting SVG to PNG, and no need to build in Docker containers with ancient systems for compatibility. The third is that Go does not need Makefiles, Autoconf, CMake or Meson, which the author describes as meta work they would rather not spend time on. The fourth is that Go is designed with concurrency and networking in mind, which will come in handy for peer to peer distribution and updating. The fifth reason is the honest one, that Go is something the author wants to learn, and one learns best using a concrete project.

zsync delta updates come out of the build

One of the more useful behaviours is automatic. When appimagetool runs on GitHub Actions, it automatically embeds UpdateInformation into the generated AppImages, and this is what enables delta updates using zsync. The format of the generated field is a pipe separated string.

gh-releases-zsync|<owner>|<repo>|<release>|<filename>.zsync

The example given is the continuous release of this repository, with the owner, the repository, the release name and a zsync filename. In addition, a .zsync file is automatically generated alongside each AppImage and uploaded to the GitHub Release, which is what makes the delta update actually resolvable on the client side. The practical reading is that a project that distributes AppImages through GitHub Releases gets zsync support for free once it builds on GitHub Actions, and a project that distributes elsewhere has to generate that metadata itself.

The dependency list is a map of what the tools touch

The go.mod is worth reading because it describes the whole surface of the two programs. The compression side comes from CalebQ42/squashfs, and the image conversion work from mgord9518/imgconv with srwiley/oksvg and srwiley/rasterx, which is the SVG to PNG path the README mentions as a source of shared library trouble in other implementations. The update machinery uses probonopd/go-zsyncmake, the same author's own zsync writer. On the system integration side there is godbus/dbus/v5, coreos/go-systemd/v22, esiqveland/notify for desktop notifications, fsnotify for file watching and adrg/xdg plus acobaugh/osrelease for the desktop environment discovery that a daemon needs. The release side uses google/go-github, and the release archive work uses gopkg.in/src-d/go-git.v4. There is also a Prometheus client via procfs, an MQTT client through paho.mqtt.golang, and the command line is urfave/cli. The module targets go 1.23, and the project follows the golang-standards project layout convention.

The TODO list is an honest status report

Two entries in the TODO section describe what is not finished, and they are worth reading before anyone adopts the tools for a production pipeline. The first is to get rid of the C code embedded in Go, which means there is still native code inside the binaries, with the usual consequences for cross compilation. The second is to get rid of the external tools from the author's static-tools repository and replace them with native Go, which means some steps in the pipeline still shell out to other binaries. The repository layout shows where the code lives, with src/ holding the two tools, internal/ for the shared internals, data/ for resources, docs/ for the documentation and scripts/ for helper scripts. There are also privkey.asc.enc and pubkey.asc files at the root, which are the signing key material used to sign AppImages, and the encrypted private key is checked in, which is a decision a security reviewer will want to look at. The .idea/ directory suggests the project is developed from IntelliJ.

A continuous tag instead of versioned releases

The release history is short and shaped by the delivery model. The tags include a continuous build dated 2026-09-03, which matches the last push to the default branch on the same day, and then two numbered releases, 832 from 2024-03-25 and 655 from 2022-04-17, so the numbered series stopped more than two years ago. The README tells users to download the binaries from the continuous release tag, and that is also the channel that the UpdateInformation example points at, with the release name written as continuous. So the tools are distributed as a rolling build with the metadata to support delta updates across that rolling build, which is consistent and sensible for a toolchain, but it does mean there is no pinned version to record in a reproducible build. The repository is not archived, the licence is MIT, and the project also carries a GitHub Actions build workflow whose badge is in the header.

Editorial conclusion

go-appimage fits a packager who wants a single static binary to build AppImages instead of a shell script with a pile of native dependencies, and it fits a project that wants zsync delta updates generated as part of the release rather than bolted on afterwards. It does not fit a team that needs the original AppImage tooling behaviour byte for byte, since this is an independent implementation, and it does not suit a build environment that cannot run Linux binaries at build time. Verify three things before you switch: which parts of your pipeline still depend on the original tooling, because the TODO list in the README admits that some C code and some external tools are still in use, and whether the continuous release tag is acceptable to you, since that is where the downloads are published.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. probonopd/go-appimage on GitHub
4. README
5. Releases