Skip to content


By default, tuxmake will use any toolchains that you have installed on your system. i.e., if you specify --toolchain and --target-arch, the appropriate (cross) compilers must be available locally in your $PATH.

Alternatively, tuxmake supports the concept of runtimes. You can think of runtimes as both an underlying backend to run the actual build commands, as well as a provider of toolchains. For example, the docker runtime will run your builds in docker containers, using toolchain container images provided by the tuxmake maintainers. When running a build, the tuxmake docker runtime will download the container image that provides the selected (cross) toolchain to build for the selected target architecture.

The following runtimes are available:


The default runtime. Assumes you have any necessary toolchain installed on your system. If you request a build that requires a (cross) toolchain you don't have installed locally, the build will just fail.


The docker runtime. Runs builds in docker containers, using images provided by the tuxmake maintainers (or the image informed via -i/--image). Will hit the network every time, looking for updated images.

If you want more details on the contents of the images provided by the TuxMake team, and how they are generated, see the corresponding README file in the TuxMake repository.

If you want to provide your own images, take into consideration that:

  • Every tool needed for the build must be included in the image. This includes, but may not be limited to compilers, assemblers/linkers, file compressors (gz, xz, tar etc), compiler wrappers (ccache), make, u-boot-tools.
  • If you only want to provide a custom toolchain, TuxMake provides base images that already contain the base tools and can be reused. Look for tuxmake/base-* on Dockerhub.

By default, the docker runtime will determine which image to use for your build based on the selection of target architecture and toolchain that you picked. You can override the image to use, the registry to get images from, or which image tags to use via environment variables. See the "ENVIRONMENT VARIABLES" section in the command line documentation.

The docker runtime, and all other container runtimes, will expose the source directory inside the container overlaid by a copy-on-write filesystem. Therefore, writes to the source directory will not affect the real source directory.


The same as docker, but will only use images that you already have locally, and fail if you try to use a arch/toolchain combination for which you don't already have an image.


The podman runtime works exactly like the docker runtime, but calling podman instead of docker.


The same as docker-local, but using podman.