Questions about dev containers

Hi Julian Herbst97 

1. Passing the project directory through docker-compose volumes

Yes, that's the right way to do it. The Docker Compose interpreter expects your project to be mounted inside the container, and a bind mount in the volumes: section is how that's normally done. Reading config files from the mount and writing the filled PDFs back to the host through it is a normal use of bind mounts, so no need to change anything there. The setup is described in https://www.jetbrains.com/help/pycharm/using-docker-compose-as-a-remote-interpreter.html.

2. The "ghost" devcontainer-NNNN containers in the Services pane

Trust docker ps -a here: those entries aren't real containers and take up no space. PyCharm starts short-lived helper containers for indexing and interpreter introspection, and there's a known display bug where stale entries for them stay in the Services view even though Docker already removed them. They can't be deleted from the IDE and they disappear after a restart. This is tracked as PY-78640. You can vote for it and follow updates there, see this article on how watching YouTrack issues works.

3. Getting new dependencies into the container after uv add

This part is expected behavior rather than a bug. With a compose-based interpreter, the packages live in the image, and PyCharm doesn't rebuild it when pyproject.toml changes. The simple approach is to rebuild the service after dependency changes, then re-run:

docker compose build <your-service>

Also worth knowing: PyCharm 2026.1 added a proper uv interpreter type for Docker and Docker Compose (PY-84075), which makes PyCharm understand uv-managed environments inside containers much better (package listing and management used to fail for them). If you're on an older version, updating to 2026.1 is worth it for this workflow.

4. Docker Compose interpreter vs. dev containers in the Services pane

These are two different features. With a Docker Compose interpreter, PyCharm itself runs locally and the container is only the Python runtime: PyCharm starts the service to run or debug your code and stops it afterwards, which matches what you described. Dev Containers (the thing asking for devcontainer.json) is full remote development: the IDE backend runs inside the container and your local window becomes a thin client to it. devcontainer.json is a file from the open Dev Containers specification that describes the whole environment, an image or a compose service plus lifecycle hooks such as postCreateCommand (another place where uv sync could live in that model).

Since you mainly want your code to run in the container while you work in a local IDE, the compose interpreter you already have is the simpler fit. Dev containers become interesting when you want the entire development environment, including the IDE tooling, to live inside the container.

If something still doesn't behave as described, let us know your PyCharm version (Help | About) and we'll take a closer look.

My PyCharm version is the most current version of PyCharm Pro personal license, I'm not sure if there is still a difference between the other licenses.

I'm not actually on a local machine, I have a Windows PC at work and a Ubuntu VM where all my projects live that I use the “regular” remote development feature on.

The reason I asked about dev containers/docker interpreters is because of the way I deploy things when they are ready to run in the background, they are mostly automation scripts or mini apps that run in a container made with a dockerfile and docker-compose, and I usually pass one directory through the docker compose that I use for logs in case I need to look at them.

The problem I had is that the absolute path on the host machine would be something like /home/user/pycharmprojects/projectname/logs, but in the container it would just be /workspace/logs, which I'd have to rewrite or figure out a way around since I have to let things run in or outside of a container while writing and testing until it's ready for deployment.

Is there even a good way to mix development on a remote machine and a dev container? I wouldn't want to run PyCharm three times so I guess I'm asking what is the best way to have absolute file paths in my scripts/config files while being able to pass directories from my host machine into the container tat my code is running in.

Hope that makes sense, I'm used to writing code that lives and runs once, purely on my personal machine, rather than things that are in the background in a more production kind of environment.

Julian Herbst97, Your setup is simpler than it looks. With Remote Development, the PyCharm backend already runs on your Ubuntu VM, so everything you configure in that window, including a Docker Compose interpreter, lives on the VM and talks to the VM's own Docker daemon. "Host machine" in my previous answers means the VM in your case. You won't need a second or third PyCharm.

Dev Containers wouldn't help here either. They are for running the IDE backend itself inside a container, so they'd replace your current remote setup, not extend it. If you ever want to try them anyway: you can't create a Dev Container from inside a running Remote Development session, see https://www.jetbrains.com/help/pycharm/dev-container-limitations.html.

For the path mismatch, the usual fix is to stop hard-coding the base directory and read it from an environment variable, with the host path as the default:

import os
from pathlib import Path
LOG_DIR = Path(os.environ.get("LOG_DIR", "/home/user/pycharmprojects/projectname/logs"))

Then set the variable in your compose service for in-container runs:

services:
 app:
   environment:
     LOG_DIR: /workspace/logs
   volumes:
     - ./logs:/workspace/logs

The same code now runs unchanged on the VM and in the container, and the pattern carries over to deployment, where whoever runs the container decides the path.
 

Thanks! Looks like I got some rewriting to do but that's fine, thanks very much for the help. 👍