kool: a Docker and Kubernetes CLI that hides the ceremony

A layer over Compose and Kubernetes, not a replacement

The README describes kool as a CLI tool that brings the complexities of modern software development environments down to earth, making those environments lightweight, fast and reproducible. It reduces the complexity and learning curve of Docker containers for local environments and offers a simplified interface for using Kubernetes to deploy staging and production environments to the cloud. That sentence is the whole design brief, and it explains both the appeal and the limit. kool is not a container runtime and it does not replace Compose V2 or kubectl. It sits on top of them, wrapping the commands a developer types several times a day and the ones a team has to agree on across a project. The claim of no loss of control is important, because the target user is explicitly described as someone who wants the convenience of containers without giving up the ability to drop down to the underlying tooling when something breaks. The primary language is Go, the licence is MIT, and the project describes itself as suitable for solo developers and teams of all sizes.

Installing the CLI, and the WSL requirement on Windows

Docker is the prerequisite. The README says kool is powered by Docker and that you first need to install Docker and the kool CLI, and it makes a specific point about versions: make sure you are running the latest version of Docker and that you have Compose V2 available through docker compose, with a link to the official documentation for installing the Compose plugin. On Linux and macOS, installation is a single shell command that downloads the latest kool binary from the GitHub releases and saves it in /usr/local/bin:

curl -fsSL https://kool.dev/install | bash

On Windows the README is unambiguous. You must run kool on Windows via WSL, the Windows Subsystem for Linux, and once you have a WSL environment properly set up with Docker available in it, you install the CLI the same way as on Linux or macOS. That is a real constraint rather than a preference, and it means a Windows-only machine cannot use kool natively. The project also publishes a container image for CI. The README says that for CI/CD use cases, most commonly GitLab CI with a docker:dind service, a pre-built image at kooldev/kool bundles kool together with docker, docker compose, git and bash, and the CI Integration guide covers the DinD sidecar pattern with example .gitlab-ci.yml and GitHub Actions configs. That guide also flags a known security caveat about CVEs inherited from the upstream docker:X-cli base image, which is the kind of note that saves you an afternoon.

Presets are the reason a new project starts fast

Getting started is described as easy, with the documentation pointing at a generic PHP web app, but the part that will save you an afternoon is the presets. Kool Presets are pre-shaped starting points for popular frameworks and stacks, and the README lists them by category. For Node there are NestJS, AdonisJs and Express.js. For PHP there are Laravel, Laravel Octane, Symfony and CodeIgniter. For Javascript there are Next.js and NuxtJS. The Others category holds Hugo and WordPress. Each preset is a document in the repository under docs/03-Presets, and the repository layout confirms the mechanism: a presets directory holds the definitions, with a templates directory and a recipes directory alongside. The one item worth calling out separately is the monorepo preset, because the README identifies mixing frameworks for a frontend and a backend API as a common challenge and says working with containers and having both run and communicate properly can be a huge differential for development experience and productivity. The monorepo NestJS with Next.js preset uses TypeScript on both the frontend and the backend, and the README asks for a GitHub issue or a pull request when your favourite framework is missing.

The kool.yml file is where your project actually lives

Underneath the presets and the CLI, the contract with your project is a single file, and the repository root makes it visible: there is a kool.yml at the top level next to the Go sources, an .env.dist for environment defaults, a Dockerfile, and directories for commands, core, services, skills and templates. The idea is that the shared infrastructure of a project, the databases and caches that every service needs, is defined once in kool.yml and then the CLI derives the compose services from it. The services directory is what the presets populate, and the recipes directory holds the runnable pieces. For a team, this is the part that changes how onboarding works: a new developer clones the repository, installs kool, and the same service set comes up, without anyone memorising the right compose flags or the right order to start things in. The trade-off is that the compose file is no longer the source of truth you can read top to bottom, and when something misbehaves you need to know that kool is generating it rather than editing it by hand.

Workspaces that need a build nobody has released yet

The most interesting feature in the README is also the least finished. The section on Git worktrees and Rift workspaces describes running selected app services separately in each workspace while sharing the infrastructure you choose, with hostname-based routing and Vite HMR through Kool's managed proxy. The mechanism is understandable from the repository layout alone: a kool.yml in each worktree, plus a services and templates layer, gives each checkout its own service set while pointing at a shared stack. The catch is stated in the same paragraph. This feature requires a Kool build containing workspace support, and the README points to the example repository's prerequisites while it is unreleased. So the feature is documented ahead of its availability, which is a reasonable thing for a project to do but a trap for a reader who only reads the documentation. The separate example repository, kool-worktree-example, is where the actual setup lives. A team evaluating kool for parallel feature work on the same codebase should look at that example and confirm which build they are getting, because a released binary without workspace support will simply lack the feature.

Where kool stops being the right answer

The honest limits follow from the design. kool adds a layer, and layers have failure modes of their own. When a compose file misbehaves, the developer has to understand both kool and Compose to work out which one is at fault, and a team that has already invested in learning Compose well may gain little. The Windows story is a hard stop without WSL, which rules kool out for a segment of developers outright. The CI image is documented as bundling a docker base image with known inherited CVEs, which is a supply chain decision rather than a bug. And the Cloud side of the story points to a hosted service, Kool.dev Cloud, for deploying and sharing work, so the tool and the commercial product are related but separable, and nothing in the repository requires you to use the hosted side. If your project is not going to run in containers locally and land in Kubernetes in production, kool is a layer in front of two things you are not otherwise using.

Release pace, dependencies and what the tree contains

The project is moving quickly. The releases are 3.7.0 on 2026-10-09, 3.6.0 on 2026-02-06 and 3.5.3 on 2025-12-28, and the last push to the repository was on 2026-10-19, so the source tree is ahead of the newest tag. The module file pins go 1.25.0, matching the golang:1.25 base image in the Dockerfile, and the dependency list reads like a CLI project: cobra for commands, spf13/viper for configuration, survey for interactive prompts, gookit/color and fatih/color for terminal output, jedib0t/go-pretty for tables, and rhysd/go-github-selfupdate for the self-update mechanism, which explains how a user gets new versions without reinstalling. There is also compose-spec/compose-go, the Go implementation of the Compose specification, which is what lets kool validate and work with compose files rather than shelling out to text processing. The build container itself is minimal, a golang builder producing a static binary copied into a docker:29-cli base with git and bash added and DOCKER_HOST pointing at a docker service, so kool can drive a Docker daemon from inside a container.

Editorial conclusion

kool suits a team that has decided to work in containers locally and in Kubernetes in production and wants one vocabulary for both, and it suits a developer starting a project on Laravel or NestJS who would rather not hand-write a compose file. It is the wrong tool if you need to stay out of the Docker abstraction, since kool is explicitly a layer over Compose and Kubernetes rather than a replacement, and it is the wrong tool on Windows without WSL, which the README states is mandatory. Verify first that Docker Compose V2 is present, since the README calls it out as a requirement, and check the kool.yml file in your project before you adopt it, because that file is where the shared services and scripts for your stack are defined and it is the thing you will be editing rather than a raw compose file.

Frequently asked questions

Official sources

1. kool-dev/kool on GitHub
2. License: MIT
3. Project website
4. README
5. Releases