DEV Community: kool.dev

Kool's Next Chapter: Closing the Gap Between AI-Generated Code and Production

Fabrício José Souza — Wed, 18 Mar 2026 03:03:53 +0000

Five years ago we wrote about using Docker for local development the right way. A lot has changed since then — except our obsession with developer experience. Today, we're entering a new chapter.

Where It All Started

Back in 2021, Kool was born out of frustration. We were a software house juggling dozens of client projects across different stacks, and Docker — while powerful — kept getting in the way. Permission issues on mapped volumes, MTU mismatches, the -t vs -T flag dance, teammates siloing Docker knowledge... we had seen it all.

So we built Kool: a CLI tool that wrapped Docker and Docker Compose with sane defaults, presets for popular frameworks, and custom images optimized for local development. The goal was simple — remove the friction so developers could focus on code, not infrastructure.

The developer community responded. Our articles on Dev.to reached over 33,000 views. We went from 60 to 600+ GitHub stars. People joined our Slack, opened issues, contributed code. Kool had found its audience.

What Hasn't Changed

Five years later, the problems Kool was built to solve haven't gone away. If anything, they've gotten worse. Docker's ecosystem has grown more complex. Multi-service architectures are the norm. Teams are more distributed. Onboarding new developers onto a project still involves too much "works on my machine" debugging.

The original arguments for Kool remain exactly as strong today:

Docker is a container engine, not a development tool. It was never designed to optimize the local dev experience. Kool bridges that gap with sane defaults and conventions that just work.
Knowledge silos kill velocity. When only senior engineers understand the Docker setup, the whole team slows down. Kool standardizes workflows through kool.yml so every team member runs the same commands.
Permission issues, volume mapping, networking quirks — these haven't been solved by Docker itself. Kool's custom images still handle the headaches that plague raw Docker setups.
No vendor lock-in. Your docker-compose.yml is yours. Kool wraps it, never replaces it. You keep full control.

kool create still spins up a fully configured local environment in minutes. kool run still keeps your workflow scripts shared and versioned. The original value proposition holds stronger than ever — because the fundamental problems haven't changed, and neither has Kool's answer to them.

From Local to Cloud — The Hard Way

In 2023, we wrote about our journey and the natural next step: taking the same Docker Compose setup developers use locally and deploying it to the cloud. In early 2024, we launched Kool Cloud publicly.

We spent nearly two years running and refining the platform with a curated group of early adopters. That deliberate pace taught us what works in production — and what developers actually need when moving containers to the cloud. We iterated on the deploy experience, built out managed MySQL databases, environment management, team collaboration, and a billing model that makes sense for small teams and growing companies alike.

The cloud platform matured. Quietly, intentionally, and with real users validating every decision.

The New Bottleneck

Here's what's different now: AI agents are writing code faster than teams can ship it.

Coding agents — Claude, Copilot, Cursor — are generating features, fixing bugs, and refactoring entire codebases in minutes. The bottleneck is no longer writing code. It's everything that happens after: spinning up a preview environment for PR validation, handing off to QA with a live URL, configuring deploys, provisioning infrastructure, debugging Kubernetes manifests, understanding cloud provider quirks. The same learning curve problem we solved for Docker locally now exists for the entire path from code to production — and it's worse, because the speed gap between code generation and code shipping has never been wider.

Developers still need to feel in control. But the cost of that control should be managed. You shouldn't need to deep-dive into specific DevOps toolchains just to get your app live. Not when AI just wrote it in 30 seconds.

The Reborn Phase

This is where Kool's new chapter begins.

Built for Agents. Easy for Humans.

We're building Kool to be the deployment layer that AI agents interact with natively. Your coding agent already writes your code — now let it deploy too. Deploy your app, provision a database, check logs, roll back — agents can do all of this on their own, autonomously, as part of their workflow.

But here's the thing: the same interface works just as well for you. The Kool CLI was always designed for low learning curve, and that hasn't changed. kool cloud deploy is one command. You don't need to understand Kubernetes, Helm charts, or cloud provider consoles. Whether it's your agent running the command or you typing it yourself, the experience is the same.

Optimized for agents. Accessible to humans. No DevOps degree required for either.

Borrow Our Cloud, or Bring Your Own

Two paths, one experience:

Managed Cloud — Deploy your Docker apps to Kool Cloud in minutes. No Kubernetes knowledge required. No servers to manage. Just kool cloud deploy and your app is live on infrastructure managed by us. Think of it as borrowing a sane, simple cloud management layer so you can focus on your product. You pay a premium for the convenience — and that's a fair trade when you're getting started or want zero ops overhead.
BYOC (Bring Your Own Cloud) — When you want ownership and cost efficiency, bring your own servers. Cherry-pick your VPS provider, choose your architecture (amd64 or arm — yes, Graviton works), right-size your hardware for your workload. Kool installs and manages the entire stack on your servers — same deploy experience, same dashboard, same agent integration. You own the hardware, you control the costs, we provide the intelligence to manage it.

With BYOC, the savings are real. You're not paying managed cloud margins on top of compute you could provision yourself for a fraction of the price. Pick Hetzner, DigitalOcean, AWS, or any provider you like. Run ARM instances where it makes sense. The infrastructure choices are yours — Kool just makes sure deploying to it stays simple.

The transition is seamless. Same CLI. Same dashboard. Same deploy workflow. Same AI agent commands. The only thing that changes is where your containers run — and how much you pay for them.

Start by borrowing. Graduate to owning. No re-platforming required.

What's Ahead

The learning curve argument that made Kool relevant in 2021 is stronger now than ever. Back then, Docker complexity was the bottleneck between an idea and a working local environment. Today, cloud deployment complexity is the bottleneck between AI-generated code and a live product.

We're building toward a future where:

Deploying doesn't break your flow — your AI agent handles it as part of the development cycle
Infrastructure choices don't lock you in — borrow our cloud today, bring your own servers tomorrow
The cost of control stays low — you stay in charge without becoming a DevOps expert

Kool started as a tool to make Docker suck less locally. It's becoming the platform that makes deploying suck less too — with AI agents as the interface and your choice of infrastructure underneath.

We're just getting started on this new chapter. If you've been following Kool's journey since the early days, thank you — the best is ahead. If you're discovering us for the first time, there's never been a better moment to give Kool a try.

Follow our journey:

Try Kool Cloud — deploy your first app for free.
Star us on GitHub — help us grow the community.

The Kool Way to Run Hugo Static Sites on Docker

Daniel Polito — Tue, 27 Jul 2021 16:02:53 +0000

In just 2 simple steps, you can use Kool to start a new Hugo application running in a local Docker development environment.

Kool is a free, open source CLI tool that makes local development with Docker super easy. Kool CLI will level up your development workflow, and help you and your team improve the way you develop and deploy cloud native applications.

Requirements

If you haven't done so already, you first need to install Docker and the Kool CLI.

If you already have kool installed, make sure you're running the latest version with kool self-update.

Step 1 – Create a New Hugo Application

Use the kool create command to create your new Hugo project.

$ kool create hugo my-project

IMPORTANT: if you're on Windows WSL or Linux, you should run sudo kool create hugo my-project as the superuser (via sudo) to avoid permissions issues when creating the project directory and files.

Under the hood, this command will run kool docker klakegg/hugo:ext-alpine new site my-project using the klakegg/hugo Docker image.

Now, move into your new Hugo project:

$ cd my-project

After installing Hugo, kool create automatically runs the kool preset hugo command, which auto-generates the following configuration files and adds them to your project. As your project evolves, you can easily modify and extend these files to suit your needs.

+docker-compose.yml
+kool.yml

Step 2 – Start Your Local Environment

As mentioned above, the kool preset command added a kool.yml file to your project. To help get you started, kool.yml comes prebuilt with an initial set of scripts based on your chosen framework and stack. Since Hugo requires a few extra steps to create a Hello World site, kool.yml includes a special quickstart script to make it super easy.

Think of kool.yml as an easy-to-use task helper. Instead of writing custom shell scripts, add your own scripts to kool.yml (under the scripts key), and run them with kool run SCRIPT (e.g. kool run hugo). You can add your own single line commands (see hugo below), or add a list of commands that will be executed in sequence (see quickstart below).

scripts:
    hugo: kool docker -p 1313:1313 klakegg/hugo:ext-alpine
    dev: kool run hugo server -D

    # remove or modify to suit the needs of your project
    quickstart:
        - kool start
        - git init
        - git submodule add https://github.com/theNewDynamic/gohugo-theme-ananke.git themes/ananke
        - echo theme = \"ananke\" >> config.toml
        - kool run hugo new posts/my-first-post.md
        - kool run dev

    setup:
        - kool start
        - kool run dev

Go ahead and run kool run quickstart to start your Docker environment and initialize your Hugo site.

$ kool run quickstart

As you can see in kool.yml, the quickstart script does the following in sequence: runs the kool start command to spin up your Docker environment; calls git init to create a Git repository; downloads the Ananke theme; uses an echo command to add the theme to your Hugo config file; adds your first post; and then calls kool run dev to build your Hugo site.

That's it!

Once kool run quickstart finishes, you should be able to access your new site at http://localhost and see the "My New Hugo Site" page. Hooray!

Verify your Docker service containers are running using the kool status command.

$ kool status
+---------+---------+------------------------------+--------------+
| SERVICE | RUNNING | PORTS                        | STATE        |
+---------+---------+------------------------------+--------------+
| app     | Running | 0.0.0.0:80->80/tcp, 1313/tcp | Up 2 minutes |
| static  | Running | 80/tcp                       | Up 2 minutes |
+---------+---------+------------------------------+--------------+

Run kool logs app to see the logs from your running app container.

Use kool logs to see the logs from all running containers. Add the -f option after kool logs to follow the logs (i.e. kool logs -f app).

$ kool logs app
Attaching to my-project_app_1
app_1     |   Non-page files   |  0
app_1     |   Static files     |  0
app_1     |   Processed images |  0
app_1     |   Aliases          |  0
app_1     |   Sitemaps         |  1
app_1     |   Cleaned          |  0
app_1     |
app_1     | Built in 1 ms
app_1     | Watching for changes in /app/{archetypes,content,data,layouts,static}
app_1     | Watching for config changes in /app/config.toml
app_1     | Environment: "DEV"
app_1     | Serving pages from memory
app_1     | Running in Fast Render Mode. For full rebuilds on change: hugo server --disableFastRender
app_1     | Web Server is available at http://localhost:80/ (bind address 0.0.0.0)
app_1     | Press Ctrl+C to stop
app_1     |
app_1     | Change of config file detected, rebuilding site.
app_1     | 2021-05-01 20:34:06.306 +0000
app_1     | Rebuilt in 136 ms
app_1     | adding created directory to watchlist /app/content/posts
app_1     |
app_1     | Change detected, rebuilding site.
app_1     | 2021-05-01 20:34:07.305 +0000
app_1     | Source changed "/app/content/posts/my-first-post.md": CREATE
app_1     | Total in 26 ms

When it's time to stop working on the project:

$ kool stop

When you're ready to start coding again:

$ kool start

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

Level Up Your Development Workflow

Once you're up and running with your new Hugo project, you can use the kool CLI to level up your development workflow. Learn more in "How It Works".

Support the Kool Open Source Project

Kool is open source and totally free to use. If you're interested in learning more about the project, please check out kool.dev. If you have questions, need support, or want to get involved, please join our Slack channel.

kool-dev / kool

From local development to the cloud: web apps development with containers made easy.

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 containers 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.dev 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 kool.dev.

Installation

Requirements: Kool is powered by…

View on GitHub

Running NestJS on Docker is Really Easy with Kool

Daniel Polito — Mon, 19 Jul 2021 20:33:49 +0000

In just 3 simple steps, you can use Kool to start a new NestJS application running in a local Docker development environment.

Kool is a free, open source CLI tool that makes local development with Docker super easy. Kool CLI will level up your development workflow, and help you and your team improve the way you develop and deploy cloud native applications.

Requirements

If you haven't done so already, you first need to install Docker and the Kool CLI.

If you already have kool installed, make sure you're running the latest version:

$ kool self-update

Step 1 – Create a New NestJS Application

Use the kool create command to create your new NestJS project.

$ kool create nestjs my-project

Under the hood, this command will run nest new my-project to install NestJS using a customized Kool Docker Image: kooldev/node:14-nest.

Learn more about Kool Docker Images in our article "Use Kool to Dockerize Your Local Development Environment the Right Way".

After installing NestJS, kool create automatically runs the kool preset nestjs command, which helps you set up the initial tech stack for your project using an interactive wizard.

$ Preset nestjs is initializing!

? Which database service do you want to use [Use arrows to move, type to filter]
> MySQL 8.0
  MySQL 5.7
  PostgreSQL 13.0
  none

? Which cache service do you want to use [Use arrows to move, type to filter]
> Redis 6.0
  Memcached 1.6
  none

? Which package manager did you choose during Nest setup [Use arrows to move, type to filter]
> npm
  yarn

$ Preset nestjs initialized!

Now, move into your new NestJS project:

$ cd my-project

The kool preset command auto-generated the following configuration files and added them to your project, which you can easily modify and extend to suit your needs.

+docker-compose.yml
+kool.yml

Step 2 (Optional) – Add Environment Variables

You can skip this step if you did not add a database or cache service to your project via the wizard.

If you added a database and/or cache service, you'll need to add some local environment variables to match the services in your docker-compose.yml file (see below). For example, you'll need to change the hosts from localhost to the appropriate service container name, which are accessible from within Docker.

Create a .env file inside your project's root directory, and add the appropriate environment variables to this file (as provided below) based on the services used in your project.

Learn more about how to configure NestJS.

Database Services

MySQL 5.7 and 8.0

+DB_CONNECTION=mysql
+DB_HOST=database
+DB_DATABASE=<some_database_name>
+DB_USERNAME=<some_username>
+DB_PASSWORD=<some_password>

PostgreSQL 13.0

+DB_CONNECTION=pgsql
+DB_HOST=database
+DB_PORT=5432
+DB_DATABASE=<some_database_name>
+DB_USERNAME=<some_username>
+DB_PASSWORD=<some_password>

Cache Services

Redis

+REDIS_HOST=cache
+REDIS_PORT=6379

Memcached

+MEMCACHED_HOST=cache
+MEMCACHED_PORT=11211

Step 3 – Start Your Local Environment

Now, spin up your local environment for the first time using the setup script in your kool.yml file:

$ kool run setup

npm notice created a lockfile as package-lock.json. You should commit this file.
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@~2.3.1 (node_modules/chokidar/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@2.3.2: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})

audited 879 packages in 32.143s

78 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

Creating network "my-project_kool_local" with the default driver
Creating volume "my-project_database" with default driver
Creating volume "my-project_cache" with default driver
Creating my-project_database_1 ... done
Creating my-project_app_1      ... done
Creating my-project_cache_1    ... done

That's it!

Once kool run setup finishes, you can access your new NestJS app at http://localhost:3000 and see the NestJS "Hello World!" welcome page.

Level Up Your Workflow

Now that you have your new NestJS app up and running, you can use the Kool CLI to start leveling up your development workflow.

Add Scripts to kool.yml

Think of kool.yml as a super easy-to-use task helper. Instead of writing custom shell scripts, you can add your own scripts to kool.yml (under the scripts key), and run them with kool run SCRIPT. You can add single line commands (kool run nest), or add a list of commands that will be executed in sequence (kool run setup). For example, add scripts to run database migrations, reset local environments, run static analysis tools, and so on. Think about how much easier it will be to onboard a teammate or new developer :)

scripts:
  mysql: kool exec -e MYSQL_PWD=$DB_PASSWORD database mysql -u $DB_USERNAME $DB_DATABASE # or psql for PostgreSQL
  nest: kool exec app nest
  npm: kool exec app npm # or yarn
  npx: kool exec app npx

  setup:
    - kool docker kooldev/node:14 npm install # or yarn install
    - kool start

Run Commands

When you need to execute a command inside a running service container, use the kool exec command. Run the following to check the version of Node running in your app container.

$ kool exec app node -v

v14.17.1

Connect to the Database

If you added a database service, start a new SQL client session inside your running database container by executing kool run mysql (MySQL) or kool run psql (PostgreSQL). This runs the mysql or psql script in your kool.yml.

Add Dependencies

As your project evolves, and you add more dependencies to package.json, use the kool restart command to restart your app container and load the new packages.

$ kool restart app

Stopping my-project_app_1 ... done
Going to remove my-project_app_1
Removing my-project_app_1 ... done
Creating my-project_app_1 ... done

View the Logs

View container logs using the kool logs command. Run kool logs to see the logs for all running containers, or kool logs app to specify a service and only see the logs for the app container. Add the -f option after kool logs to follow the logs (i.e. kool logs -f app).

Share Your Work

When you need to quickly share local changes with your team, use the kool share command to share your local environment over the Internet via an HTTP tunnel. Specify your own subdomain using the --subdomain flag.

$ kool share --port=3000

Thank you for using expose.
Local-URL:     app:3000
Dashboard-URL: http://127.0.0.1:4040
Expose-URL:    https://eeskzijcbe.kool.live

Remaining time: 00:59:59
Remaining time: 00:59:58
Remaining time: 00:59:57

Switch Projects

Kool supports any language or framework, so you can standardize the way you work across all your tech stacks. When it's time to stop working on your new NestJS app and switch to a different project, you can easily change local Docker environments by running kool stop on the NestJS project, moving into the other project directory, and running kool start.

$ kool stop
$ cd ~/my-other-project
$ kool start

Pretty kool, right?

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

Dive Deeper

Read the docs for our NestJS Preset to learn more about using Kool with NestJS.
Check out the Kool Presets for other popular frameworks.
Go to kool.dev to learn more about the Kool open source project.

kool-dev / kool

From local development to the cloud: web apps development with containers made easy.

About `kool`

Learn more at kool.dev.

Installation

Requirements: Kool is powered by…

View on GitHub

Use Kool to run Multiple Docker Applications at the same time in your Local Development Environment

Fabrício José Souza — Mon, 12 Jul 2021 14:30:29 +0000

More and more, we find ourselves working with Docker containers in the context of microservice architectures comprising multiple, loosely-coupled applications and services, and/or projects made up of two or more distinct apps running side-by-side talking to each other via APIs. As developers who work on these types of projects know all too well, setting up your local development environment to run multiple Docker applications at the same time can be a real hassle. Developing each app on its own is a breeze using Kool and Docker Compose. However, when you need to run multiple apps at the same time, configuring the routing and intercommunication between different containers can be challenging.

In this tutorial, we'll show you how to set up your local environment to run more than one Docker application at the same time using Kool and a Caddy web server. No doubt, this is just one of several ways to solve for this use case, but we think it's an approach that works really well for most projects.

Requirements

Before you start, if you haven't done so already, you need to install Docker and Kool CLI. It also wouldn't hurt to quickly get up-to-speed with the Kool CLI commands.

kool is a CLI tool that makes local development with Docker super easy. Kool CLI will level up your development workflow, and help you and your team improve the way you develop and deploy cloud native applications. Make sure you're always using the latest version by running kool self-update.

It always starts off simple

You have a single application with its Docker Compose environment. Let's call it App 1.

$ mkdir -p ~/multiple-apps/app-1
$ cd ~/multiple-apps/app-1

Create the two files we need:

# App 1
# ~/multiple-apps/app-1/docker-compose.yml
services:
  app:
    image: kooldev/php:8.0-nginx
    ports:
      - 80:80
    volumes:
      - .:/app/public

# App 1
# ~/multiple-apps/app-1/index.php
<?php
    echo "Welcome to App 1!\n";

With these two files, you can now get App 1 up and running using kool start, and check the status of its service container using kool status:

$ kool start
Creating network "app-1_default" with the default driver
Creating app-1_app_1 ... done

$ kool status
+---------+---------+---------------------------------------------+---------------+
| SERVICE | RUNNING | PORTS                                       | STATE         |
+---------+---------+---------------------------------------------+---------------+
| app     | Running | 0.0.0.0:80->80/tcp, :::80->80/tcp, 9000/tcp | Up 4 seconds  |
+---------+---------+---------------------------------------------+---------------+
[done] Fetching services status

$ curl localhost
Welcome to App 1!

Awesome! Your app service container is running, kool status shows that port 80 is mapped from your host to the container, and curl localhost successfully returns the output of App 1.

But then it starts getting tricky

As your project evolves over time, you need to add a second application called App 2, which runs alongside App 1. In other words, to work on the project, you need to run both apps at the same time.

Let's quickly set up App 2.

$ mkdir -p ~/multiple-apps/app-2
$ cd ~/multiple-apps/app-2

Once again, let's create the two files we need (inside the app-2 directory):

# App 2
# ~/multiple-apps/app-2/docker-compose.yml
services:
  app:
    image: kooldev/php:8.0-nginx
    ports:
      - 80:80
    volumes:
      - .:/app/public

# App 2
# ~/multiple-apps/app-2/index.php
<?php
    echo "Welcome to App 2!\n";

This time, when you try to get App 2 up and running (using kool start), you run into a problem.

$ kool start
Creating network "app-2_default" with the default driver
Creating app-2_app_1 ...
Creating app-2_app_1 ... error

ERROR: for app-2_app_1  Cannot start service app: driver failed programming external connectivity on endpoint app-2_app_1 (24719704f55491122a18f051d3f1e789b6afc3f34ccf7bfe3d7eac510117ef42):
  Bind for 0.0.0.0:80 failed: port is already allocated

ERROR: for app  Cannot start service app: driver failed programming external connectivity on endpoint app-2_app_1 (24719704f55491122a18f051d3f1e789b6afc3f34ccf7bfe3d7eac510117ef42):
  Bind for 0.0.0.0:80 failed: port is already allocated
ERROR: Encountered errors while bringing up the project.

As per the error message, you have a port conflict (Bind for 0.0.0.0:80 failed: port is already allocated). You cannot have two different containers bound to the same port on your host.

Before you continue, let's stop your App 2 and App 1 containers:

$ cd ~/multiple-apps/app-2 # you should already be here
$ kool stop

$ cd ~/multiple-apps/app-1
$ kool stop

Not so fast!

To fix this error, your first impulse is probably to use different ports for each service. For example, you can run App 1 on localhost:8081 and App 2 on localhost:8082. However, you'll quickly realize this solution isn't viable because it's not flexible enough, and doesn't provide intercommunication between applications over a shared Docker network.

Proxy to the rescue

The proxy design pattern provides a much better solution for running multiple Docker applications at the same time in your local development environment.

Add a global network to Docker Compose

First, you need to improve the Docker Compose environments used by each of your apps. Using one of the many best practices built into the Docker configurations included with Kool Presets, let's create a shared network between Docker containers.

By default, all containers in a docker-compose.yml file will share the same virtual network. This means two different applications will not have a channel of communication. For this reason, Kool Presets will usually have two networks for each container: kool_local and kool_global.

kool_local is a local network that's only available to the group of containers from that docker-compose.yml file. It's the same as the default network (if we didn't specify the network ourselves).
kool_global is a global network created outside the scope of any particular docker-compose.yml file. It's available system-wide, and any containers running on the host can join it.

Let's create an external kool_global network inside each Docker Compose environment, and add each app to it.

# App 1
# ~/multiple-apps/app-1/docker-compose.yml
services:
  app:
    image: kooldev/php:8.0-nginx
    expose:
      - 80
    volumes:
      - .:/app/public
    networks:
      kool_global:
        aliases:
          - app-1

networks:
  kool_global:
    external: true

# App 2
# ~/multiple-apps/app-2/docker-compose.yml
services:
  app:
    image: kooldev/php:8.0-nginx
    expose:
      - 80
    volumes:
      - .:/app/public
    networks:
      kool_global:
        aliases:
          - app-2

networks:
  kool_global:
    external: true

Notice that we replaced the ports configuration with expose. You don't want these app containers bound to the host anymore, in order to avoid a conflict. Instead, you want to bind a single container to the host, which proxies each request internally over the kool_global network to the correct service container using its network alias.

The aliases key on the container network works like a domain name that resolves to that container's address when used within the same network. This is a great way to normalize names for service containers that need to talk to each other.

Set up the proxy

As mentioned earlier, we're going to use a Caddy web server as our reverse proxy. It's our first choice because it has a simple configuration interface and a rich feature set. Traefik or Nginx would work great too, so feel free to use what you like best when you implement this solution in a real project.

Let's start by creating a Caddyfile configuration file in a new proxy directory:

$ mkdir ~/multiple-apps/proxy
$ cd ~/multiple-apps/proxy

# ~/multiple-apps/proxy/Caddyfile
{
  auto_https off
}

http://a.localhost {
  reverse_proxy / http://app-1
}

http://b.localhost {
  reverse_proxy / http://app-2
}

Notice that we use the app-1 and app-2 container network aliases to point to each destination, based on the incoming Host request (a.localhost vs. b.localhost). You should also add these local domains to your /etc/hosts file: echo "127.0.0.1 a.localhost b.localhost" | sudo tee -a /etc/hosts.

By default, Caddy tries to use HTTPS for all hosts. For this tutorial, we're disabling it. We'll cover local TLS usage in a future article.

Next, let's create a new docker-compose.yml for Caddy itself:

# ~/multiple-apps/proxy/docker-compose.yml
services:
  proxy:
    image: caddy:2-alpine
    ports:
      - 80:80
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
    networks:
      - kool_global

networks:
  kool_global:
    external: true

And that's it. You're done configuring your proxy.

Now, all you need to do is spin up your App 1, App 2 and Proxy service containers (using kool start of course), and verify it works by sending a couple of test requests.

# Proxy
$ cd ~/multiple-apps/proxy # you should already be here
$ kool start
Creating proxy_proxy_1 ... done

# App 1
$ cd ~/multiple-apps/app-1
$ kool start

# App 2
$ cd ~/multiple-apps/app-2
$ kool start

$ curl -H "Host: a.localhost" http://localhost
Welcome to App 1!

$ curl -H "Host: b.localhost" http://localhost
Welcome to App 2!

W00t! You now have both apps up and running at the same time. You can access them using different host names, and they can also communicate with each other.

To clean up your local environment, you'll need to move into each directory (app-1, app-2, and proxy) and run kool stop, and then remove the directories you created: rm -r ~/multiple-apps.

Next steps

Kool's core team is already working on a new set of commands to make the above steps seamless and transparent, so you don't have to worry about the details. We invite you to join the discussion and contribute.

If you like what we're doing, please show your support by starring us on GitHub!

Support the Kool open source project

Kool is open source and totally free to use. If you're interested in learning more about the project, please check out kool.dev. If you have questions, need support, or want to get involved, please join our Slack channel.

Use Kool to Dockerize Your Local Development Environment the Right Way

Fabrício José Souza — Thu, 01 Jul 2021 20:04:20 +0000

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.

PHP Images (https://github.com/kool-dev/docker-php)
Nginx Images (https://github.com/kool-dev/docker-nginx)
Node Images (https://github.com/kool-dev/docker-node)
Java Images (https://github.com/kool-dev/docker-java)
DevOps Images (https://github.com/kool-dev/docker-toolkit)

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!

Battle-Tested

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.

Article No Longer Available

kool-dev / kool

From local development to the cloud: web apps development with containers made easy.

About `kool`

Learn more at kool.dev.

Installation

Requirements: Kool is powered by…

View on GitHub

Running Laravel on Docker is really easy with Kool

Daniel Polito — Tue, 22 Jun 2021 18:31:04 +0000

In just 3 simple steps, you can use Kool CLI's kool create command to start a new Laravel application running in a local Docker environment. Kool is an open source dev tool that makes using Docker for local development a lot easier.

Before you start, if you haven't done so already, you need to install Docker and Kool CLI.

1. Create a new Laravel application

$ kool create laravel my-project

This command may take a minute or two to complete while Composer downloads Laravel's vendor dependencies. After installing Laravel, kool create automatically runs the kool preset laravel command, which helps you set up your project's development environment using an interactive wizard.

PHP

? What app service do you want to use  [Use arrows to move, type to filter]
> PHP 8.0
  PHP 7.4

Database

? What database service do you want to use  [Use arrows to move, type to filter]
> MySQL 8.0
  MySQL 5.7
  MariaDB 10.5
  PostgreSQL 13.0
  none

Cache

? What cache service do you want to use  [Use arrows to move, type to filter]
> Redis 6.0
  Memcached 1.6
  none

Package Manager

? What javascript package manager do you want to use  [Use arrows to move, type to filter]
  npm
> yarn

After selecting your preferences, the latest version of Laravel will be installed and ready for you in your my-project folder, along with your new kool environment.

Move into your new Laravel project:

$ cd my-project

The kool preset command auto-generated the following configuration files and added them to your project, which you can modify and extend.

+docker-compose.yml
+kool.yml

2. Update `.env.example`

Next, we need to make a few tweaks to the default .env.example file that ships with Laravel in order to match the services in your docker-compose.yml file. For example, we need to change the hosts from localhost to the appropriate service container name, which are accessible from within Docker.

Database Services

MySQL 5.7 and 8.0 / MariaDB 10.5

-DB_HOST=127.0.0.1
+DB_HOST=database

PostgreSQL 13.0

-DB_CONNECTION=mysql
+DB_CONNECTION=pgsql

-DB_HOST=127.0.0.1
+DB_HOST=database

-DB_PORT=3306
+DB_PORT=5432

Cache Services

Redis

-REDIS_HOST=127.0.0.1
+REDIS_HOST=cache

Memcached

-MEMCACHED_HOST=127.0.0.1
+MEMCACHED_HOST=cache

3. Run `kool run setup`

Now, spin up your local environment for the first time using the setup script in your kool.yml file:

$ kool run setup

Note: if you're running this command for the first time, Docker may need to download all the container images that are being used, which can take a few minutes, depending on your internet connection.

That's it!

After kool run setup has finished, you can access your new Laravel app at http://localhost.

$ kool run setup

Creating network "my-project_kool_local" with the default driver
Creating volume "my-project_database" with default driver
Creating volume "my-project_cache" with default driver
Creating my-project_cache_1    ... done
Creating my-project_app_1      ... done
Creating my-project_database_1 ... done

Dive Deeper

Read the docs for our Laravel Preset to learn more about using Kool with Laravel.
Go to kool.dev to learn more about the Kool open source project.

kool-dev / kool

From local development to the cloud: web apps development with containers made easy.

About `kool`

Learn more at kool.dev.

Installation

Requirements: Kool is powered by…

View on GitHub

DEV Community: kool.dev

Kool's Next Chapter: Closing the Gap Between AI-Generated Code and Production

Where It All Started

What Hasn't Changed

From Local to Cloud — The Hard Way

The New Bottleneck

The Reborn Phase

Built for Agents. Easy for Humans.

Borrow Our Cloud, or Bring Your Own

What's Ahead

The Kool Way to Run Hugo Static Sites on Docker

Requirements

Step 1 – Create a New Hugo Application

Step 2 – Start Your Local Environment

Level Up Your Development Workflow

Support the Kool Open Source Project

kool-dev / kool

From local development to the cloud: web apps development with containers made easy.

About kool

Installation

Running NestJS on Docker is Really Easy with Kool

Requirements

Step 1 – Create a New NestJS Application

Step 2 (Optional) – Add Environment Variables

Database Services

Cache Services

Step 3 – Start Your Local Environment

Level Up Your Workflow

Add Scripts to kool.yml

Run Commands

Connect to the Database

Add Dependencies

View the Logs

Share Your Work

Switch Projects

Dive Deeper

kool-dev / kool

From local development to the cloud: web apps development with containers made easy.

About kool

Installation

Use Kool to run Multiple Docker Applications at the same time in your Local Development Environment

Requirements

It always starts off simple

But then it starts getting tricky

Not so fast!

Proxy to the rescue

Add a global network to Docker Compose

Set up the proxy

Next steps

Support the Kool open source project

Use Kool to Dockerize Your Local Development Environment the Right Way

The Real-World Learning Curve

A Better Way with Kool

Kool CLI

Kool Presets

Kool Docker Images

Kool Cloud (Coming Soon)

Flexible and Extensible

Open Source

Battle-Tested

Give It a Try

Not Using Docker for Development?

Article No Longer Available

kool-dev / kool

From local development to the cloud: web apps development with containers made easy.

About kool

Installation

Running Laravel on Docker is really easy with Kool

1. Create a new Laravel application

PHP

Database

Cache

Package Manager

2. Update .env.example

Database Services

Cache Services

3. Run kool run setup

Dive Deeper

kool-dev / kool

From local development to the cloud: web apps development with containers made easy.

About `kool`

About `kool`

About `kool`

2. Update `.env.example`

3. Run `kool run setup`

About `kool`