Public Repository

Last pushed: a month ago
Short Description
Haskell is an advanced purely-functional programming language.
Full Description

Supported tags and respective Dockerfile links

(amd64/haskell build job)

Quick reference

What is Haskell?

Haskell is a lazy, functional, statically-typed programming language with advanced type system features such as higher-rank, higher-kinded parametric polymorphism, monadic effects, generalized algebraic data types (GADTs), flexible type classes, associated type families, and more.

Haskell's ghc is a portable, optimizing compiler with a foreign-function interface (FFI), an LLVM backend, and sophisticated runtime support for concurrency, explicit/implicit parallelism, runtime profiling, etc. Other Haskell tools like criterion, quickcheck, hpc, and haddock provide advanced benchmarking, property-based testing, code coverage, and documentation generation.

A large number of production-quality Haskell libraries are available from Hackage in the form of Cabal packages. The traditional cabal tool, or the more recent stack tool (available in 7.10.3+) can be used to streamline working with Cabal packages. The key differences are summarized here. New users are encouraged to start with stack.

About this image

This image ships a minimal Haskell toolchain (ghc and cabal-install) from the upstream Debian repository as well as the Stack tool (

Note: The GHC developers do not support legacy release branches (i.e. 7.8.x). While older GHC release tags are available in this DockerHub repository, only the two most recent minor releases will receive updates or be shown in the "Supported tags ..." section at the top of this page.

How to use this image

Start an interactive interpreter session with ghci:

$ docker run -it --rm amd64/haskell:8
GHCi, version 8.4.3:  :? for help

Dockerize an application from Hackage with a Dockerfile:

FROM amd64/haskell:8
RUN stack install pandoc pandoc-citeproc
ENTRYPOINT ["pandoc"]

Alternatively, using cabal:

FROM amd64/haskell:8
RUN cabal update && cabal install pandoc pandoc-citeproc
ENTRYPOINT ["pandoc"]

Iteratively develop a Haskell application with a Dockerfile utilizing the build cache:

FROM amd64/haskell:7.10

WORKDIR /opt/server

RUN cabal update

# Add just the .cabal file to capture dependencies
COPY ./snap-example.cabal /opt/server/snap-example.cabal

# Docker will cache this command as a layer, freeing us up to
# modify source code without re-installing dependencies
# (unless the .cabal file changes!)
RUN cabal install --only-dependencies -j4

# Add and Install Application Code
COPY . /opt/server
RUN cabal install

CMD ["snap-example"]


See the application snippet above in more detail in the example snap application.

Considerations for happy, alex, etc

Some packages that also act as build dependencies, such as happy and alex, are no longer included in this image (as of amd64/haskell:8.2.2 & amd64/haskell:8.4.3). There is a bootstrapping problem where one or more of these tools may be assumed to be available. If you run in to an error about missing dependencies that are not explicitly called out in a Cabal package, you will need to explicitly mark them for installation.

Considerations for Stack

The Stack tool is primarily designed to run directly on the host and comes with many advanced features such as GHC bootstrapping and Docker integration. Within the context of a container image, some of these features clash with the Docker abstraction and should be avoided. Another common scenario that can be confusing is the default Stackage snapshot.

A Stackage snapshot is a collection of Haskell packages pinned to specific versions for compatibility with a particular GHC release. When you ask Stack to resolve dependencies it refers to a particular snapshot via the resolver value. While you should be specifying a resolver explicitly in your projects, it is possible to run with the auto-generated default. That default is determined by the value obtained from the upstream Stackage server at the time it was requested, and points to the latest "LTS" snapshot. If the snapshot refers to a different version of GHC than is provided in the Docker image, you may see a message like the following:

Step 2/3 : RUN stack install pandoc
 ---> Running in e20466d52060
Writing implicit global project config file to: /root/.stack/global-project/stack.yaml
Note: You can change the snapshot via the resolver field there.
Using latest snapshot resolver: lts-11.11
Downloading lts-11.11 build plan ...
Downloaded lts-11.11 build plan.
Compiler version mismatched, found ghc-8.4.3 (x86_64), but expected minor version match with ghc-8.2.2 (x86_64) (based on resolver setting in /root/.stack/global-project/stack.yaml).
To install the correct GHC into /root/.stack/programs/x86_64-linux/, try running "stack setup" or use the "--install-ghc" flag.

In this case, the GHC release in the amd64/haskell Docker image got ahead of the default Stack resolver expected version of GHC. As the output suggests, manually setting the resolver (typically via stack.yml) is the recommended approach.

Step 2/3 : RUN stack install --resolver ghc-8.4.3 pandoc
 ---> Running in 0bd7f1fcc8b2
Writing implicit global project config file to: /root/.stack/global-project/stack.yaml
Note: You can change the snapshot via the resolver field there.
Using resolver: ghc-8.4.3 specified on command line
Updating package index Hackage (mirrored at ...
Selected mirror

The alternative to use --install-ghc doesn't make sense in a Docker image context, and in fact the global install-ghc flag has been set to false (as of amd64/haskell:8.2.2 & amd64/haskell:8.4.3) to avoid the default behavior of bootstrapping a new GHC in the container.


This image is licensed under the MIT License (LICENSE) and includes software licensed under BSD licenses: Glasgow Haskell Compiler License, Stack License.

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 haskell/ 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.

Docker Pull Command