• CI Integration
  • When to use the image
  • What's in the image
  • GitLab CI example
  • GitHub Actions example
  • Known security caveat

¶CI Integration

Beyond local development, kool can also run inside CI/CD pipelines. A pre-built Docker image is published to Docker Hub as kooldev/kool for exactly this purpose — it bundles the kool CLI together with docker, docker compose, git, and bash, pre-configured to talk to a Docker-in-Docker sidecar.

This image is intended for CI pipelines that need kool alongside a Docker daemon. For local development, install the native binary as described in the Installation guide.

¶When to use the image

The kooldev/kool image is primarily used with GitLab CI, where the services: + docker:dind pattern pairs naturally with kool's requirement for a working docker and docker compose. It also works with GitHub Actions, Drone, Bitbucket Pipelines, and any other CI runner that supports linking a Docker daemon service container.

If your CI runner already has Docker available on the host (e.g. GitHub Actions' default ubuntu-latest runner), installing kool via curl | bash at the top of the job is often simpler than running it through the image.

¶What's in the image

• kool CLI — built with Go 1.25, statically linked
• docker CLI
• docker compose plugin (Compose V2)
• git and bash
• ENV DOCKER_HOST=tcp://docker:2375 — defaults the Docker CLI to a sidecar service reachable at the hostname docker

Published tags track kool releases, e.g. kooldev/kool:3.2.0 pins to a specific release and kooldev/kool:3 tracks the current major line. Pin a specific version in CI for reproducibility.

¶GitLab CI example

test: image: kooldev/kool:3 services: - name: docker:dind alias: docker variables: DOCKER_TLS_CERTDIR: "" DOCKER_HOST: tcp://docker:2375 script: - kool run test

The alias: docker is important — the kooldev/kool image defaults DOCKER_HOST to tcp://docker:2375, so the DinD sidecar must be reachable at the hostname docker.

¶GitHub Actions example

GitHub Actions runners already have Docker available, so you can usually skip the image and install kool natively:

jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Install kool run: curl -fsSL https://kool.dev/install | bash - run: kool run test

If you prefer a consistent, pinned kool version via container:, the pattern below mirrors the GitLab setup:

jobs: test: runs-on: ubuntu-latest container: image: kooldev/kool:3 services: docker: image: docker:dind options: --privileged env: DOCKER_TLS_CERTDIR: "" env: DOCKER_HOST: tcp://docker:2375 steps: - uses: actions/checkout@v4 - run: kool run test

¶Known security caveat

The kooldev/kool image is built FROM docker:29-cli, which bundles docker-compose and docker-buildx CLI plugins as pre-built Go binaries that we inherit as-is. At any given time those plugins may have been compiled with a Go toolchain that has since received CVE advisories, and a scanner will report them against our image. Such findings clear on their own once the upstream docker-library/docker image is rebuilt with a newer Go toolchain — there is no action we can take on our side beyond following the base image.

Those advisories are in the Go standard library of Docker's own plugin binaries, not in kool. Anything in kool's own code or dependencies we fix rather than suppress. For security-sensitive pipelines, consider either:

• Installing kool as a native binary on the runner (curl -fsSL https://kool.dev/install | bash) instead of using the image, which avoids the upstream plugin surface entirely,
• Pinning a specific kooldev/kool:VERSION tag and re-scanning when you adopt a new version.

If you find a security issue in kool itself, please follow the Security instructions in the main README.