DEV Community

Cover image for Use Kool to Dockerize Your Local Development Environment the Right Way
Fabrício José Souza for

Posted on • Updated on • Originally published at

Use Kool to Dockerize Your Local Development Environment the Right Way

Using Docker containers in local development environments has become commonplace for web development. And yet, when you get down to it, using Docker locally is still a challenge, oftentimes resulting in a frustrating developer experience and plenty of headaches. So, what is the right way to use containers for local development? We believe the answer is a new open source project called Kool.

Kool helps you develop cloud native applications in a better and more efficient way by removing barriers and allowing developers and DevOps engineers to focus on what matters most.

The Real-World Learning Curve

In the past few years, Docker has taken the software development world by storm. Its powerful interface for building, deploying and running containers has led to its widespread adoption by teams and companies of all sizes. By containerizing your web applications, you can more easily work across different tech stacks, switch between different applications and microservices, and standardize and scale your environments. You no longer waste precious time debugging and fixing issues with version mismatches, concurrently running applications, dependency conflicts, poor resource control, etc.

However, while Docker has a straightforward "getting started" experience, developing real-world applications on containers is a lot easier said than done. You quickly start climbing a steep learning curve when your requirements evolve and you're forced to master Docker's nuances, its more advanced configurations, and the working internals of its containers in order to apply its features to more complex environments.

For example, mastering when to use the -t or -T flags for docker run and docker exec, resolving issues with permissions on mapped volumes, and even deeper issues like having your Docker network suddenly lose external packages because it has a different MTU value than the underlying host network. If you've faced these issues before, I feel for you. If not, count yourself lucky!

While Docker provides teams with a lot of power, this power does not come cheap. As you climb the Docker learning curve, you often have no choice but to use trial and error to find acceptable solutions to problems you encounter along the way. Since Docker expertise can vary greatly across the team, it is common to find knowledge siloed with senior members of the team, and developers applying different solutions to the same problem. Additional hidden costs include senior engineers pulled away from their work to help others with technical issues, time spent reconciling conflicting opinions and workarounds, and the frustration of disrupted workflows causing low morale. Consequently, it becomes difficult for your project to sustain its high velocity, and stay on schedule and on budget.

A Better Way with Kool

Kool (kool-dev/kool) offers a better way to use Docker locally. Kool provides a suite of open source tools that deliver a better developer experience (DX) and help you avoid the pitfalls described earlier by making sure you follow best practices and use Docker in a standardized way across your projects and teams. From local development environments running on Docker to staging and production environments running in the cloud on Kubernetes, Kool makes it easier to containerize your web apps.

Kool CLI

The kool CLI provides a simple, intuitive interface for managing Docker and Docker Compose containers. It simplifies the way you use Docker in your local environment by removing the Docker "speed bumps" that slow you down, greatly reducing the learning curve and error-prone area, and helping teams leverage containers at a lower cost of entry.

Kool CLI comes with a single-line installer, a self-update command to easily upgrade to new releases, an intuitive command interface with a complete command reference, and solid documentation. By using the kool CLI instead of docker directly, you can stop learning new flags each day and stay focused on writing code!

Kool Presets

Kool Presets provide pre-built development environments with sane defaults out of the box for quickly setting up projects using popular frameworks and tech stacks, such as Laravel, Symfony, Node.js, AdonisJs, Next.js (and more). Presets auto-generate a customized docker-compose.yml file, as well as a kool.yml configuration file in which you can easily store common single-line and multi-line scripts that you execute using the kool run command. This helps keep your development workflow open and shared across the entire team. Learn more about how it works.

Kool Docker Images

When you start developing in containers, you suddenly realize official Docker images are built for deployment, and are not well-suited for the special nuances of local development. One of the most common and recurring problems we see are permission issues with mapped volumes, due to host users being different from container users. Kool fixes this problem, and many others, by creating custom Docker images optimized for local development environments.

A few of the optimizations included in Kool Docker images:

  • UID mapping to host user to solve permission issues
  • Alpine base images to remain small and up-to-date
  • Configured with sane defaults (for development as well as production)
  • Environment variables to easily update the most common settings
  • Battle-tested - we've been using these images in production for quite a long time now!

If you know what you're doing, you can use kool with any Docker image. You are not required to use Kool-optimized images.

Kool Cloud (Coming Soon)

Kool CLI integrates seamlessly with Kool Cloud. Based on the same Docker configuration you already use locally, you can very easily and quickly create staging environments in the cloud, straight from your local environment. Using a set of kool deploy commands, you can push your local project repository to the Kool Cloud, where it's automatically deployed on containers running on a shared Kubernetes infrastructure. Your local environment and cloud environments have never been so close to each other!

Kool Cloud is currently being tested in a closed alpha, but will soon be opened as a public beta. If you would like early access, please create a free account.

Flexible and Extensible

If you know your way around Docker, you can use Kool and remain totally in charge of your Docker configuration. Kool guarantees no vendor lock-in and no loss of control, which means you can fully customize and extend your more specialized Docker environments. You'll never feel as if your hands are tied. On the contrary, using Kool will actually free your hands, and let you focus on more valuable work instead of spending time tweaking your development environment.

Open Source

Kool is open source and totally free to use. Feel free to contribute, help us with testing, and/or suggest new ways to make Kool better.

If you like what we're doing, show your support for this new open source project by starring us on GitHub!


Kool is sponsored and maintained by Firework Web, a software development agency located in Brazil. Over many years, having worked on hundreds of web projects with dozens of teams, Firework developed a ton of expertise using Docker and other development tools, and figured out the right way to set up and manage local Docker environments. Based on this experience, the Kool project was born. And now Firework is ready to share it with all of you.

Give It a Try

Kool is a great new development tool that will help you use Docker containers in your local environment the right way. You'll get all the benefits of containerizing your web apps, without the hassles. If you haven't already, give Kool a try.

Not Using Docker for Development?

If you're not yet using Docker in your development environment, here's a great post that gives you a number of reasons why you should make the switch.

GitHub logo kool-dev / kool

From local development to the cloud: development workflow made easy.

kool - cloud native dev tool

Go Report Card codecov Docker Hub Golang CI Lint Maintainability Join Slack Kool community

About kool

Kool is a CLI tool that brings the complexities of modern software development environments down to earth - making these environments lightweight, fast and reproducible. It reduces the complexity and learning curve of Docker and Docker Compose for local environments, and offers a simplified interface for using Kubernetes to deploy staging and production environments to the cloud.

Kool gets your local development environment up and running easily and quickly, so you have more time to build a great application. When the time is right, you can then use Kool Cloud to deploy and share your work with the world!

Kool is suitable for solo developers and teams of all sizes. It provides a hassle-free way to handle the Docker basics and immediately start using containers for development, while simultaneously guaranteeing no loss of control over more specialized Docker environments.

Learn more at


Requirements: Kool is…

Top comments (13)

stefannastic profile image
Stefan Nastic • Edited

Recently, I also decided to set up dev containers for an open source project I lead. In my opinion things are still a little rough around the edges, but definitely worth investing time into it.
You can check out some of my lessons learned here

fabriciojs profile image
Fabrício José Souza

Nice article, thanks for sharing! Indeed things are not as smooth when it comes down to efficiently using Docker containers as development environments... that is precisly our motivation!

fabriciojs profile image
Fabrício José Souza

Using Docker is awesome, but we felt there's a gap of knowledge on how to use it for local development envs in an efficient manner - several common and recurring problems people face - which should benefit from this abstraction layer that Kool stands to be. Stefan Nastic's comment and article refers exactly to that (in a comment above).

I use to say that Docker is a tool for managing containers... and Kool is a tool to help you manage Docker containers for development environments! Basically helping you look at it more from an application development standpoint, than simply learning and mastering containers, the technology itselt. This should help bring even more people to adopt and leverage it rather sooner than if they didn't have this abstraction layer.

However, I totally get your feeling when faced with such abstraction to something you probably already knows proficiently... and one of the main values we defend is to balance abstraction to ease in adoption of any team and team member with less/no experience with Docker... while maintening everything excplitly and open source there, right in your project, ready for tweaking/customization by the DevOps/Docker experts in the team! We hope we can make senior DevOps to see that... what do you think about this point of view?

Not to mention that adopting standards by itself, to have a streamlined DX (developer experience) amongst different apps/frameworks, we believe will save time and help teams be more productive - just like it has helped us for the last couple of years. Less hassle with environments, more time to focus on the app itselt.

zuck profile image
Emanuele Bertoldi

Hey Fabricio, nice work! I've read the documentation but I still miss a point: Kool is designed to provide an easy-to-use dev environment based on Docker, but how does it work for deployment on production? Do i have to rewrite the Dockerfiles / docker-compose for that?

fabriciojs profile image
Fabrício José Souza • Edited

This is indeed something our documentation lacks currently. About production deployment there are couple of ways we can look at it -

  1. We are testing and soon will be made publicly available the kool cloud deploy commands, which basically will look into translating your local docker-compose.yml to a Kubernetes deployment - leveraging our already open source Helm charts. We hope to build some sort of service around it too.

  2. What we have done in the past and we see people doing somewhat often, althoug it's not the optimal usage, is adapting the docker-compose.yml file extending it to production (add restart, change the image to a production optimized one if suitable, and even add resources control/change port mapping accordingly). This solution already helps a lot of folks that will be running the same env they do for development, to production, making easier to manage both at the same time. But there are problems of course, observability/scaling, putting it all togheter still needs manual steps. That is why we will be focusing and releasing the Kubernetes deploy option I mentioned above soon, to be the "go to" solution for deployment.

  3. Other options like AWS ECS, are options we certianly wanna help people with too.

So our goal is, while focusing on the option number 1 to enable the community and companies leverage Kubernetes today, going really "cloud native", we certainly want to document and offer help with the other two options. Our documention is a big Work in Progress and we will soon be covering these options. As well as the Dockerfile creation, which is needed in all of the options above.

The initial good response we are having with this post will make us run faster with all of this. In case someone wanna join and help feel free to join our Slack to discuss/get help or get a PR up on Github!

deranjer profile image

I've recently been using Microsoft's containers for local dev in vscode... How does this compare?

fabriciojs profile image
Fabrício José Souza

Hello @deranjer ! I am not sure I understand exactly what you meant by Microsoft's containers - but I assume you are using Remote Containers on VS Code, on Windows - is that it?

Kool is a set of resources around the CLI tool kool which aims to replace docker/docker-compose CLI usage, to make it easier leveraging them. As for such "resources" I mean helper scripts (on kool.yml), docker-compose.yml preconfigured files and customized Docker images - all tweaked for local development needs.

You can get a better sense on the DX (developer experience) we are looking to offer by checking this Laravel environment read or any other of ours current presets.

deranjer profile image

By Microsoft's containers I mean this:

It is a list of containers that Microsoft provides for Remote Containers with an already setup dev environment based on what language/task you want to do.

Thank you for the Laravel environment read, that does clear it up significantly. Looks like kool allows for a little bit more customization. Currently MS vscode containers already provide a base image that can't be modified and comes with specific version of software already installed. I use bash scripts to modify it as needed for my specific project, but kool would perhaps offer more flexibility.

Thread Thread
bessa3301 profile image

Totally! Kool might allow you to drop the bash scripts and replace it with a more flexible development environment. Join the Kool slack to find out more :)

mycarrysun profile image
Mike Harrison

I checked out the source for the php containers and it addresses a bunch of things I had to workaround. I will definitely be using Kool now!

mrdulin profile image
official_dulin • Edited

Don't build the wheel repeatedly. The wheels are more than enough.

Docker itself is sufficient, additional packaging will only hide too much detail, which is not conducive to developers to understand the nature of the problem, and add additional problems.

In the short term it may improve development, CI/CD efficiency, but in the long term it is not conducive to developer knowledge growth.

Exception: unless it is a more advanced solution with better algorithms that greatly improve performance in terms of time and space.

dbpolito profile image
Daniel Polito

Thanks for your insight, it's indeed a valid point...

But other point is this kind of solution also helps you learning all these, having sane defaults and learning curve, so it's easier for new comers to start using and feeling the benefits of it.

This is kind of the same tradeoff of using frameworks or not, etc.

IMHO you never should fully rely on the tool but also learn from it, how it solves the problems.