containers
dockerfile_inline ignored
Describe the bug
Using the compose file below with podman compose --file docker-compose.yml up results in the Dockerfile in the folder being used for the build instead of dockerfile_inline or an error if not Dockerfile is in the folder (Error: no Containerfile or Dockerfile specified or found in context directory, C:\foo: The system cannot find the file specified.).
docker-compose.yml
services:
caddy:
image: foo/caddy:latest
build:
dockerfile_inline: |
FROM caddy:builder AS builder
RUN \
xcaddy build \
--with github.com/caddyserver/transform-encoder
FROM caddy
COPY --from=builder /usr/bin/caddy /usr/bin/caddy
pull_policy: build
To Reproduce Steps to reproduce the behavior:
podman compose --file docker-compose.yml up
Expected behavior foo/caddy:latest is built with the inline dockerfile
Actual behavior Dockerfile in folder where the command is run is used or an error if no Dockerfile present.
Output
$ podman-compose version
podman-compose version 1.5.0
podman version 5.6.2
$ podman --version
Client: Podman Engine
Version: 5.6.2
API Version: 5.6.2
Go Version: go1.25.1
Git Commit: 9dd5e1ed33830612bc200d7a13db00af6ab865a4
Built: Tue Sep 30 20:36:54 2025
OS/Arch: windows/amd64
Server: Podman Engine
Version: 5.4.2
API Version: 5.4.2
Go Version: go1.23.7
Git Commit: be85287fcf4590961614ee37be65eeb315e5d9ff
Built: Wed Apr 2 01:00:00 2025
OS/Arch: linux/amd64
$ podman-compose up
Error: no Containerfile or Dockerfile specified or found in context directory, C:\foo: The system cannot find the file specified.
ERROR:__main__:Build command failed
Environment:
- OS: Windows
- podman version: 5.6.2
- podman compose version: f7eeda1a3db10952424af6a5b0501c269ebe3f0d
Additional context
I reported this in podman, but they say that the issue is with this project instead. I mentioned this in this related issue, but opened a new one given that one is close.
podman compose has the same result as podman-compose. Using docker compose with podman seems to work.
> $env:DOCKER_HOST='npipe:////./pipe/docker_engine'
> docker-compose --file docker-compose.yml up
compose build requires buildx 0.17 or later
> docker compose --file docker-compose.yml up
[+] Building 44.9s (13/13) FINISHED docker-container:default
=> [caddy internal] booting buildkit 0.9s
=> => starting container buildx_buildkit_default 0.9s
=> [caddy internal] load build definition from Dockerfile 0.1s
=> => transferring dockerfile: 477B 0.0s
=> [caddy internal] load metadata for docker.io/library/caddy:latest 3.9s
=> [caddy internal] load metadata for docker.io/library/caddy:builder 4.0s
=> [caddy auth] library/caddy:pull token for registry-1.docker.io 0.0s
=> [caddy internal] load .dockerignore 0.0s
=> => transferring context: 146B 0.0s
=> [caddy builder 1/2] FROM docker.io/library/caddy:builder@sha256:53f91ad7c5f1ab9a607953199b7c1e10920c570ae002aef913d68ed7464fb19f 6.5s
=> => resolve docker.io/library/caddy:builder@sha256:53f91ad7c5f1ab9a607953199b7c1e10920c570ae002aef913d68ed7464fb19f 0.0s
=> => sha256:5ba89021cd2228dabc9573a2dd0ba4a636fafc3f994dbedd55b9b534d026d89d 1.85MB / 1.85MB 0.3s
=> => sha256:6136507627de565426e95282d3bd0ca833235a615f16ddc635a702fceefa4505 398B / 398B 0.2s
=> => sha256:b17c81c92b076b36a55ac2331362ddeccef473e2e9cd05c14659c2065eedb3d4 6.21MB / 6.21MB 0.3s
=> => sha256:f3f5ae8826faeb0e0415f8f29afbc9550ae5d655f3982b2924949c93d5efd5c8 126B / 126B 0.2s
=> => sha256:91631faa732ae651543f888b70295cbfe29a433d3c8da02b9966f67f238d3603 60.15MB / 60.15MB 1.9s
=> => sha256:85e8836fcdb2966cd3e43a5440ccddffd1828d2d186a49fa7c17b605db8b3bb3 291.15kB / 291.15kB 0.3s
=> => extracting sha256:85e8836fcdb2966cd3e43a5440ccddffd1828d2d186a49fa7c17b605db8b3bb3 0.1s
=> => extracting sha256:91631faa732ae651543f888b70295cbfe29a433d3c8da02b9966f67f238d3603 3.7s
=> => extracting sha256:f3f5ae8826faeb0e0415f8f29afbc9550ae5d655f3982b2924949c93d5efd5c8 0.0s
=> => extracting sha256:4f4fb700ef54461cfa02571ae0db9a0dc1e0cdb5577484a6d75e68dc38e8acc1 0.0s
=> => extracting sha256:b17c81c92b076b36a55ac2331362ddeccef473e2e9cd05c14659c2065eedb3d4 0.1s
=> => extracting sha256:5ba89021cd2228dabc9573a2dd0ba4a636fafc3f994dbedd55b9b534d026d89d 0.0s
=> => extracting sha256:6136507627de565426e95282d3bd0ca833235a615f16ddc635a702fceefa4505 0.0s
=> [caddy stage-1 1/2] FROM docker.io/library/caddy:latest@sha256:9e95012adcbbd599f853cb315b986781845c238f9e52aa3652798758cca01422 1.1s
=> => resolve docker.io/library/caddy:latest@sha256:9e95012adcbbd599f853cb315b986781845c238f9e52aa3652798758cca01422 0.0s
=> => sha256:67e3c8bc26d8f0e5df4ea5405a1c979aa5493679cef2e1eb255aa07bffeb7e28 15.92MB / 15.92MB 0.7s
=> => sha256:68bad5cd4577dae30587abbb0a8108d45d58e384305b5d123d2fbd738042ef0a 7.50kB / 7.50kB 0.2s
=> => sha256:094994dd0a888230052dc694e55fba90dcfb325d8fa94440c3ed81c87c95ae06 355.52kB / 355.52kB 0.3s
=> => sha256:2d35ebdb57d9971fea0cac1582aa78935adf8058b2cc32db163c98822e5dfa1b 3.80MB / 3.80MB 0.4s
=> => extracting sha256:2d35ebdb57d9971fea0cac1582aa78935adf8058b2cc32db163c98822e5dfa1b 0.1s
=> => extracting sha256:094994dd0a888230052dc694e55fba90dcfb325d8fa94440c3ed81c87c95ae06 0.1s
=> => extracting sha256:68bad5cd4577dae30587abbb0a8108d45d58e384305b5d123d2fbd738042ef0a 0.0s
=> => extracting sha256:67e3c8bc26d8f0e5df4ea5405a1c979aa5493679cef2e1eb255aa07bffeb7e28 0.2s
=> => extracting sha256:4f4fb700ef54461cfa02571ae0db9a0dc1e0cdb5577484a6d75e68dc38e8acc1 0.0s
=> [caddy builder 2/2] RUN set -o nounset -o xtrace && xcaddy build --with github.com/caddyserver/transform-encoder 29.4s
=> [caddy stage-1 2/2] COPY --from=builder /usr/bin/caddy /usr/bin/caddy 0.1s
=> [caddy] exporting to docker image format 2.6s
=> => exporting layers 1.2s
=> => exporting manifest sha256:fcef88093eb0ae3aeb81cdd86338a5e2172c20465844790559aef6c6545634ee 0.0s
=> => exporting config sha256:1bc897e8cecd9852e4e981e73863287f62fcf0bd37ef8b456c26537a8a302d89 0.0s
=> => sending tarball 1.4s
=> [caddy] importing to docker 0.0s
=> [caddy] resolving provenance for metadata file 0.1s
[+] Running 1/1
✔ Container bar-caddy-1 Recreated
I attempted to reproduce the issue using the following setup:
podman-compose --version
podman-compose version 1.5.0
podman version 5.4.2
OS: Debian GNU/Linux 13 (trixie)
compose.yml:
services:
caddy:
image: foo/caddy:latest
build:
dockerfile_inline: |
FROM docker.io/library/caddy:builder AS builder
RUN \
xcaddy build \
--with github.com/caddyserver/transform-encoder
FROM docker.io/library/caddy
COPY --from=builder /usr/bin/caddy /usr/bin/caddy
pull_policy: build
(The only change from the original compose.yml is the fully-qualified image name for Caddy.)
- Run:
podman-compose --file docker-compose.yml up -d - Verify:
podman ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
b065b2a24134 localhost/foo/caddy:latest caddy run --confi... About a minute ago Up About a minute 80/tcp, 443/tcp, 2019/tcp, 443/udp podman-compose_caddy_1
The container starts successfully.
dockerfile_inline support was implemented in https://github.com/containers/podman-compose/issues/864.
Thank you @mokibit for looking into this. On Windows 11 I don't appear to get the same result. I'm not the only person experiencing this as deathtracktor also reported this. Are you sure that the container being built is the one in docker-compose.yml and not one in a local Containerfile or Dockerfile, as that is what I'm experiencing?
Using your docker-compose.yml instead:
services:
caddy:
image: foo/caddy:latest
build:
dockerfile_inline: |
FROM docker.io/library/caddy:builder AS builder
RUN \
xcaddy build \
--with github.com/caddyserver/transform-encoder
FROM docker.io/library/caddy
COPY --from=builder /usr/bin/caddy /usr/bin/caddy
pull_policy: build
With podman-compose:
> podman-compose --version
podman-compose version 1.5.0
podman version 5.7.0
When no Dockerfile in the same path:
> podman-compose --file .\docker-compose.yml up
Error: no Containerfile or Dockerfile specified or found in context directory, C:\foo: The system cannot find the file specified.
ERROR:__main__:Build command failed
With podman compose:
> podman compose --file .\docker-compose.yml up
>>>> Executing external compose provider "C:\\Program Files\\Docker\\Docker\\resources\\bin\\docker-compose.exe". Please see podman-compose(1) for how to disable this message. <<<<
time="2025-12-01T11:44:12Z" level=warning msg="Docker Compose is configured to build using Bake, but buildkit isn't enabled"
[+] Running 0/1
- Service caddy Building 0.0s
unable to prepare context: unable to evaluate symlinks in Dockerfile path: CreateFile C:\foo\Dockerfile: The system cannot find the file specified.
Error: executing C:\Program Files\Docker\Docker\resources\bin\docker-compose.exe --file .\docker-compose.yml up: exit status 1
When a Dockerfile is in the same path it is used instead for the build, ignoring dockerfile_inline.
Hi, @fydon.
Thanks for clarification.
I ran command podman-compose --file ./docker-compose.yml up -d both with and without a Dockerfile in the directory.
In both cases the result is the same: dockerfile_inline is used (no error is raised when the Dockerfile is missing) and the container podman-compose_caddy_1 is created successfully.
It looks like a Windows-specific bug.
Thank you. Are there any Windows contributors who could attempt to reproduce and resolve this?
I'm busy at the moment, but when I get a chance I'll try to reproduce on macos to see if dockerfile_inline is only working on Linux. If binaries where provided, I could test this quicker.
Thank you. Are there any Windows contributors who could attempt to reproduce and resolve this?
Not than I know of-maybe, but I’m not aware of any.
I'm busy at the moment, but when I get a chance I'll try to reproduce on macos to see if dockerfile_inline is only working on Linux. If binaries where provided, I could test this quicker.
Issues in podman-compose are fixed slowly, because the project depends mostly on volunteers so any help is appreciated.