Kolo supports Docker for local Django development. In many cases, no additional configuration is required for Kolo to work.
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 Kolo 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
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 doesn’t prevent it entirely.
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
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