Docker

Kolo supports Docker for local Django development. In many cases, no additional configuration is required for Kolo to work.

Kolo VSCode Extension

When you’re using the Kolo VSCode extension (instead of the Kolo web app), Kolo relies on a volume definition to your working directory, which most projects already have configured. If your project does not yet have this configured, then you will need to set this up in order for the Kolo VSCode extension to work.

So for example, in your Dockerfile you might have something like this specified:

WORKDIR /code
COPY . ./

And then in your docker-compose.yml file, you will need the following corresponding volume definition:

  volumes:
    - .:/code

Kolo works by writing data to a sqlite database from within your running Django app. This volume definition ensures that the db.sqlite3 file that Kolo stores in the .kolo directory is stored not just inside Docker but also on your host operating system, where it can then be read by the Kolo VSCode extension.

Docker on Mac

We recommend you use VSCode’s Remote Containers extension.

This avoids issues where Docker’s virtual file system system sync interferes with Kolo reading and writing its own .kolo/db.sqlite3 file.

If you’re unable to use VSCode’s Remote Container extension, we recommend enabling “VirtioFS accelerated directory sharing” (on Docker 4.6 or later). This mitigates the issue described above, but, unfortunately, doesn’t prevent it entirely.

File ownership

If you’re having trouble getting traces to show up in VSCode, it may be because the .kolo directory is owned by root. This can happen in some cases, depending on how Docker is set up. To check whether the .kolo directory is owned by root, run ls -l

You can fix this by changing the ownership of the .kolo directory to the current user, for example by running sudo chown -R $USER .kolo