DEV Community: Fabrício José Souza

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 Developer Role, Redefined

Fabrício José Souza — Tue, 10 Mar 2026 02:27:56 +0000

Developer = Product + Architect + QA.

That is the role of a software engineer today around the new reality brought upon us by AI agents. And if that formula sounds reductive, stay with me — because I think it describes what great developers have always done, and what every developer now needs to do deliberately.

This isn't new — it's newly visible

Developers have always worn these hats. You've always pushed back on requirements that didn't make sense. You've always made architectural calls — choosing a pattern, weighing a trade-off, deciding what to abstract and what to leave concrete. You've always been the last line of defense before code ships, testing the edges, catching what the specs missed.

What varied was the mix. A developer with deep domain experience leaned heavier into product thinking. Someone on an infrastructure team lived in the architecture space. A developer on a small startup team with no QA department? They became QA out of necessity. The distribution was always personal — shaped by the teams you worked with, the domains you lived in, your own preferences and strengths.

But here's what made certain developers stand out, consistently: a good balance across all three. The ones who could challenge a requirement and design a clean solution and define what "done" actually meant. The ones who didn't just write code, but owned the outcome.

What changed

AI agents now handle a growing share of the implementation itself. That's the shift everyone is talking about. But what it actually does is expose what was always true: the coding was never the whole job. It was just the most visible part. With that part increasingly assisted — or outright handled — by agents, what remains is the judgment layer. The product instinct, the architectural ownership, the quality mindset.

And here's the thing most people miss: AI assists every phase, not just implementation. Exploration, planning, code review, QA — agents can accelerate all of it. The developer who only uses AI to generate code is leaving most of the value on the table. The real leverage comes from knowing how to apply AI across the entire workflow.

The Developer Diamond

A development workflow isn't a straight line — it breathes. Exploration opens things up. Planning closes them down. Reviewing the plan opens them up again through different lenses. Implementation narrows to focused execution. QA widens out during manual testing, then closes back down through automation. Code review does the same: opens to question decisions, closes to actionable findings.

It's a series of diamonds — diverge, converge, diverge again — much like the Double Diamond from design thinking. And the key skill isn't mastering any single phase. It's knowing when to expand your view and when to close it down. That rhythm — open up to explore, narrow down to decide, open up to validate, narrow down to ship — is what turns AI assistance into compounding gains instead of scattered experiments.

The leadership question

If the role demands product sense, architectural judgment, and quality thinking — and these were always part of the job, just unevenly developed — then team leaders have a clear mandate: help each person on your team grow in the areas where they're least versed.

This is a personal journey conversation, which teams need to nurture. Not "learn a new framework" — but "where in the Product/Architect/QA triangle are you weakest, and how do we deliberately close that gap?" Some developers have strong product instincts but skip rigorous QA. Others architect beautifully but never challenge whether the feature should exist at all. The growth path is personal, and it's the leader's job to make it visible and intentional.

Practically, this means:

Identify where each team member naturally gravitates and where they avoid.
Create exposure — pair a product-weak developer with a PM for a sprint, or have an architecture-light developer lead a design review.
Build team skills, not just team prompts. If your prompt library only covers "generate code," you're optimizing the one part agents already handle well. The real leverage is in structured exploration, plan review through multiple lenses, acceptance criteria definition, architectural trade-off analysis.

The craft is migrating

The developer who can orchestrate the full diamond — knowing when to open up and when to close down, when to hand off to an agent and when to apply their own judgment — that's the profile that compounds in value. The craft isn't disappearing. It's migrating. And the developers and teams who name it, map it, and practice it deliberately are the ones who'll thrive.

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`

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