Quick reference

• Maintained by: the Docker Community

• Where to get help: the Docker Community Forums, the Docker Community Slack, or Stack Overflow

Supported tags and respective Dockerfile links

(See "What's the difference between 'Shared' and 'Simple' tags?" in the FAQ.)

Simple Tags

• 1.15beta1-buster, 1.15-rc-buster, rc-buster
• 1.15beta1-alpine3.12, 1.15-rc-alpine3.12, rc-alpine3.12, 1.15beta1-alpine, 1.15-rc-alpine, rc-alpine
• 1.15beta1-windowsservercore-ltsc2016, 1.15-rc-windowsservercore-ltsc2016, rc-windowsservercore-ltsc2016
• 1.15beta1-windowsservercore-1809, 1.15-rc-windowsservercore-1809, rc-windowsservercore-1809
• 1.15beta1-nanoserver-1809, 1.15-rc-nanoserver-1809, rc-nanoserver-1809
• 1.14.4-buster, 1.14-buster, 1-buster, buster
• 1.14.4-stretch, 1.14-stretch, 1-stretch, stretch
• 1.14.4-alpine3.12, 1.14-alpine3.12, 1-alpine3.12, alpine3.12, 1.14.4-alpine, 1.14-alpine, 1-alpine, alpine
• 1.14.4-alpine3.11, 1.14-alpine3.11, 1-alpine3.11, alpine3.11
• 1.14.4-windowsservercore-ltsc2016, 1.14-windowsservercore-ltsc2016, 1-windowsservercore-ltsc2016, windowsservercore-ltsc2016
• 1.14.4-windowsservercore-1809, 1.14-windowsservercore-1809, 1-windowsservercore-1809, windowsservercore-1809
• 1.14.4-nanoserver-1809, 1.14-nanoserver-1809, 1-nanoserver-1809, nanoserver-1809
• 1.13.12-buster, 1.13-buster
• 1.13.12-stretch, 1.13-stretch
• 1.13.12-alpine3.12, 1.13-alpine3.12, 1.13.12-alpine, 1.13-alpine
• 1.13.12-alpine3.11, 1.13-alpine3.11
• 1.13.12-windowsservercore-ltsc2016, 1.13-windowsservercore-ltsc2016
• 1.13.12-windowsservercore-1809, 1.13-windowsservercore-1809
• 1.13.12-nanoserver-1809, 1.13-nanoserver-1809

Shared Tags

• 1.15beta1, 1.15-rc, rc:
  • 1.15beta1-buster
  • 1.15beta1-windowsservercore-ltsc2016
  • 1.15beta1-windowsservercore-1809
• 1.15beta1-windowsservercore, 1.15-rc-windowsservercore, rc-windowsservercore:
  • 1.15beta1-windowsservercore-ltsc2016
  • 1.15beta1-windowsservercore-1809
• 1.15beta1-nanoserver, 1.15-rc-nanoserver, rc-nanoserver:
  • 1.15beta1-nanoserver-1809
• 1.14.4, 1.14, 1, latest:
  • 1.14.4-buster
  • 1.14.4-windowsservercore-ltsc2016
  • 1.14.4-windowsservercore-1809
• 1.14.4-windowsservercore, 1.14-windowsservercore, 1-windowsservercore, windowsservercore:
  • 1.14.4-windowsservercore-ltsc2016
  • 1.14.4-windowsservercore-1809
• 1.14.4-nanoserver, 1.14-nanoserver, 1-nanoserver, nanoserver:
  • 1.14.4-nanoserver-1809
• 1.13.12, 1.13:
  • 1.13.12-buster
  • 1.13.12-windowsservercore-ltsc2016
  • 1.13.12-windowsservercore-1809
• 1.13.12-windowsservercore, 1.13-windowsservercore:
  • 1.13.12-windowsservercore-ltsc2016
  • 1.13.12-windowsservercore-1809
• 1.13.12-nanoserver, 1.13-nanoserver:
  • 1.13.12-nanoserver-1809

Quick reference (cont.)

• Where to file issues: https://github.com/docker-library/golang/issues

• Supported architectures: (more info) amd64, arm32v5, arm32v6, arm32v7, arm64v8, i386, mips64le, ppc64le, s390x, windows-amd64

• Published image artifact details: repo-info repo's repos/golang/ directory (history) (image metadata, transfer size, etc)

• Image updates: official-images PRs with label library/golang
  official-images repo's library/golang file (history)

• Source of this description: docs repo's golang/ directory (history)

What is Go?

Go (a.k.a., Golang) is a programming language first developed at Google. It is a statically-typed language with syntax loosely derived from C, but with additional features such as garbage collection, type safety, some dynamic-typing capabilities, additional built-in types (e.g., variable-length arrays and key-value maps), and a large standard library.

wikipedia.org/wiki/Go_(programming_language)

How to use this image

Note: /go is world-writable to allow flexibility in the user which runs the container (for example, in a container started with --user 1000:1000, running go get github.com/example/... will succeed). While the 777 directory would be insecure on a regular host setup, there are not typically other processes or users inside the container, so this is equivilant to 700 for Docker usage, but allowing for --user flexibility.

Start a Go instance in your app

The most straightforward way to use this image is to use a Go container as both the build and runtime environment. In your Dockerfile, writing something along the lines of the following will compile and run your project:

FROM golang:1.14

WORKDIR /go/src/app
COPY . .

RUN go get -d -v ./...
RUN go install -v ./...

CMD ["app"]

You can then build and run the Docker image:

$ docker build -t my-golang-app .
$ docker run -it --rm --name my-running-app my-golang-app

Compile your app inside the Docker container

There may be occasions where it is not appropriate to run your app inside a container. To compile, but not run your app inside the Docker instance, you can write something like:

$ docker run --rm -v "$PWD":/usr/src/myapp -w /usr/src/myapp golang:1.14 go build -v

This will add your current directory as a volume to the container, set the working directory to the volume, and run the command go build which will tell go to compile the project in the working directory and output the executable to myapp. Alternatively, if you have a Makefile, you can run the make command inside your container.

$ docker run --rm -v "$PWD":/usr/src/myapp -w /usr/src/myapp golang:1.14 make

Cross-compile your app inside the Docker container

If you need to compile your application for a platform other than linux/amd64 (such as windows/386):

$ docker run --rm -v "$PWD":/usr/src/myapp -w /usr/src/myapp -e GOOS=windows -e GOARCH=386 golang:1.14 go build -v

Alternatively, you can build for multiple platforms at once:

$ docker run --rm -it -v "$PWD":/usr/src/myapp -w /usr/src/myapp golang:1.14 bash
$ for GOOS in darwin linux; do
>   for GOARCH in 386 amd64; do
>     export GOOS GOARCH
>     go build -v -o myapp-$GOOS-$GOARCH
>   done
> done

Image Variants

The golang images come in many flavors, each designed for a specific use case.

golang:<version>

This is the defacto image. If you are unsure about what your needs are, you probably want to use this one. It is designed to be used both as a throw away container (mount your source code and start the container to start your app), as well as the base to build other images off of.

Some of these tags may have names like buster or stretch in them. These are the suite code names for releases of Debian and indicate which release the image is based on. If your image needs to install any additional packages beyond what comes with the image, you'll likely want to specify one of these explicitly to minimize breakage when there are new releases of Debian.

golang:<version>-alpine

This image is based on the popular Alpine Linux project, available in the alpine official image. Alpine Linux is much smaller than most distribution base images (~5MB), and thus leads to much slimmer images in general.

This variant is highly experimental, and not officially supported by the Go project (see golang/go#19938 for details).

The main caveat to note is that it does use musl libc instead of glibc and friends, which can lead to unexpected behavior. See this Hacker News comment thread for more discussion of the issues that might arise and some pro/con comparisons of using Alpine-based images.

To minimize image size, additional related tools (such as git, gcc, or bash) are not included in Alpine-based images. Using this image as a base, add the things you need in your own Dockerfile (see the alpine image description for examples of how to install packages if you are unfamiliar). See also docker-library/golang#250 (comment) for a longer explanation.

golang:<version>-windowsservercore

This image is based on Windows Server Core (microsoft/windowsservercore). As such, it only works in places which that image does, such as Windows 10 Professional/Enterprise (Anniversary Edition) or Windows Server 2016.

For information about how to get Docker running on Windows, please see the relevant "Quick Start" guide provided by Microsoft:

• Windows Server Quick Start
• Windows 10 Quick Start

License

View license information for the software contained in this image.

As with all Docker images, these likely also contain other software which may be under other licenses (such as Bash, etc from the base distribution, along with any direct or indirect dependencies of the primary software being contained).

Some additional license information which was able to be auto-detected might be found in the repo-info repository's golang/ directory.

As for any pre-built image usage, it is the image user's responsibility to ensure that any use of this image complies with any relevant licenses for all software contained within.