compose support?

[magnusviri]

Will you be creating a tool that allows users to use docker_compose.yml files?

See https://docs.docker.com/compose/.

[awilfox]

Yes, I would also love to see Compose support for container. Is this something that would accepted as a contribution?

[ttys3]

just found a impl https://github.com/mcrich23/container-compose

[bergrahm]

I am a heavy-weight compose user. Having the option to drop and replace would dramatically increase the chance for me to adopt this tool without hassle. Great work by the way!

[codedoga]

+1

[psy0rz]

Without compose support i will just keep using docker desktop for now. What would be the advantage of this new system?

[ArquitetoMovel]

I'm using the https://orbstack.dev it also is made in swift and not use vm

[66Ton99]

https://orbstack.dev/ uses VM underhood

[koi-tattoo]

I've rolled up a script to emulate some functionalities of docker-compose https://gist.github.com/koi-tattoo/1decd7f52f55ddb902e8a9eb78f8c587.
I mostly generated it through claude 4 sonnet as I was just trying to have something working fast. It managed to up this compose file https://gist.github.com/koi-tattoo/5f91de153768865d6d29f3773564a75d decently, maybe you guys can try to use it to easily test apple containers through your already established compose files.

Edit: see the issue docker/compose/issues/12934, maybe it is on docker-compose's end to implement this feature.

[ralfkrause]

I’ll test it and will give an update here.

[ralfkrause]

The scripts does the main things.
During up volumes if not defined with type bind are skipped. Giving error message 'named volumes...'.
During down I got the error message that the container could not be deleted. But that's just because they are getting started with option --rm. But that's no big deal.
Setting the hostname of the container is not supported. But that's because it's not supported by Apples container system. At least not at the moment.
It's the same as the container name.
Traffic between container of the same multi container project does not work when using the hostname of the container. But there is no problem when using the IP address.

But far from that all I tested works.

[t3chn0m4g3]

yes, compose is the peanut-butter and jelly!

[psy0rz]

Dont get me wrong its super cool apple does this!

[bgottsch]

+1

some integration pointers:

• naming: container compose?
• load balancers like Traefik as a container

[llmons]

+1

[pszymkowiak]

+1

[dmatton]

+1

[koi-tattoo]

According to docker/compose#12934, it could be done if the apple container runtime supports the Moby API (https://github.com/moby/moby/blob/master/api/README.md)

[mani-arjunan]

+1

[tarikweiss]

+1

[EugeneBad]

+1E6

[thoerdo]

+1

[hamza-m-masood]

+1

[zhuoyang]

+1

[xdaniel3]

+1

[miko866]

+1

[iperezx]

+10000
I don't mind doing testing if they need people for testing the feature

[martinborgman]

+1

[kiransmatat-gif]

+1

I don't want the initiative of supporting docker-compose to stop. I would like to appreciate devs and community at apple for introducing container to macos.

But for apple container to be used by devs like us in scale, compose is the most.

[manhduc-nguyen]

+1 compose super needed

[kvokka]

TBH, this is the only reason for my usage pattern to upgrade to MacOS 26 from 15 and replace Docker for devcontainer. But without the support of compose, it just doesn't make sense.

There were a few PR's about this feature that were rejected by maintainers. Unfortunately, there is no roadmap or glimpse that our voices are heard, since this discussion has been in here for more than 6 months.

Hope that there will be a moment when we'll be noticed, or at least the proper path will be shared, so it'll be an option to contribute. (And I'm happy to participate)

[kvokka]

Any external project is a dependency injection. Docker Desktop works very stable, and has all the required pieces.
And it has drop in replacement like podman, that includes podman compose feature, making the transition simple and secure. All the hassle is to replace the bin file link.

Here it was advertised as a native alternative, but instead we are still getting an MVP. So i'm a bit confused, by the performance of the biggest company in the world

And i'm ok to contribute, as well as many others, but all pointing that it will be for nothing, since all the solutions will be from outside, and from inside of the company it's not the priority.

And would easily accept it from any other brand, but not from the wealthiest company in the world!

[hulleyrob]

Which completely misses the point that nobody wants to use it until compose support is built in.

I think if this was a small bug fix, or a small feature, I'd agree with you but since this is a foundational feature + an Apple ecosystem repo, I think it should be Apple's work in this case

Im not bothered how it gets there but until we can use our current compose files with this system it's dead in the water to a lot of people. Nobody wants a third party plug-in why not just use Docker that comes with compose support?

[stivens]

It wouldn't be Apple if they didn't ignore every other standard in favor of their own.

[hulleyrob]

It wouldn't be Apple if they didn't ignore every other standard in favor of their own.

Fair!

[kiransilwal1]

Hi, guys can I join the party?

I thought apple would think about usecase before delivering a product. But with this one I too am disappointed.

[flindeberg]

Have a look at socktainer, a Docker Engine API / moby wrapper for Apple container. socktainer will allow you to use (some) tools which rely on the Docker Engine API.

Point $DOCKER_HOST to the socktainer-socket (e.g. export DOCKER_HOST=unix://$HOME/.socktainer/container.sock) and then just go ahead with the docker cli-tools, including (some functionality of) docker compose.

[flindeberg]

First off, I think you are a bit confused, Colima is just a wrapper dependent on one / several OCI image container runtime implementation(s). Colima does not run anything, it propagates instructions to container runtimes.

Apple container is native on macOS, just as docker and containerd are native wrt the Linux kernel. These are container runtimes. Management tools such as Colima can use them. Comparing Colima with Apple container runtime makes no sense what-so-ever, its like comparing Uber (the app) to a physical taxi car.

You are of course entitled to your opinion, but if you, for example, are in need of performance and your metal is a mac, the apple container system is an order or two more efficient for certain tasks.

If you use containerd or docker on a mac (macOS + hardware + rest of the stack) you are essentially running a container inside a VM (containerd on macOS uses lima), wasting resources and loosing performance.

[stivens]

From a User Developer Experience perspective, Colima (or containerd/docker) is a battle-tested, reliable tool that provides a seamless workflow. Suggesting that someone should switch to an underdeveloped, third-party wrapper for a native Apple runtime just for the sake of 'native efficiency' makes little sense in a real-world dev environment.

Regarding your performance argument:

Local vs. Production: We develop on macOS, but we deploy on Linux. The 'order of magnitude' performance gain you mentioned is irrelevant during local development. I don't need microsecond latency to run a few microservices or a database locally; I need a stable, predictable environment that mirrors production. Local development isn't about handling 'hundreds of thousands of requests per second'

Predictability over Benchmarks: Using Colima/docker/containerd ensures that what I run locally is almost identical to what happens in the CI/CD pipeline and on the production server. Introducing 'Apple-specific' runtime quirks just to save a few CPU cycles is a classic case of premature optimization.

Stability: I’d rather have a tool that 'just works' than a high-performance experiment that requires constant troubleshooting.

In short: I value my time as a developer more than the marginal resource savings of a native runtime that isn't ready for prime time yet.

[stivens]

Don't get me wrong - of course, if Apple supported all Docker Compose features natively and flawlessly, that would be amazing. But as long as it requires installing underdeveloped, third-party wrappers just to get basic functionality working, it’s simply not worth the headache.

[ebesirik]

Stability: I’d rather have a tool that 'just works' than a high-performance experiment that requires constant troubleshooting.

it is not about high performance, for me (and I believe for of the most people here) it is about docker (and others) taxing the system while developing. Not everybody uses 128G M4 Max, I for one would really like to be able to run containers without maxing out system ram or cpu on my Macbook Air M3 with the comfort of a lightweight laptop.

In short: I value my time as a developer more than the marginal resource savings of a native runtime that isn't ready for prime time yet.

about maturity of the runtime, I would agree with you, but I can also wait until it matures and use Docker Desktop for ease of use and maturity.

[stivens]

but I can also wait until it matures

That’s why we want native Compose support from Apple. When someone suggests some random third-party workarounds instead, they're missing the point. That's not a real solution.

[sfatula]

Yeah, native support, from Apple. For now, I have to use Orbstack as it's faster than the other solutions. Development takes time, hopefully compose is on the roadmap.

[renan-garcia]

+1

[iperezx]

+1M

[arch-fan]

i'll make a somersault if this becomes real