# Container-Compose: a Compose front end for Apple Container > Container-Compose parses docker-compose.yml files and drives Apple Container with them, so a multi service application can be defined with the format you already know on a Mac. It suits someone moving a Compose workflow onto Apple's own container runtime, and it is explicitly a bridge rather than a Docker wrapper. **Mcrich23/Container-Compose** — A docker-compose like tool for Apple Container - Repository: https://github.com/Mcrich23/Container-Compose - Stars: 980 · Forks: 58 - Language: Swift - License: Apache-2.0 - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/mcrich23-container-compose ## A bridge, and the README says so twice Container-Compose brings limited Docker Compose support to Apple Container, allowing you to define and orchestrate multi-container applications on Apple platforms using familiar Compose files. The second sentence of the introduction is the important one. This project is not a Docker or Docker Compose wrapper but a tool to bridge Compose workflows with Apple's container management ecosystem. That distinction is what a reader should hold on to. A wrapper would take your Compose file and hand it to a Docker daemon, and everything you rely on in Docker would come along. A bridge has to reimplement the parts of the semantics that matter, and the parts it has not implemented are the parts that will surprise you. The word limited in the first sentence is the same point stated in the feature description, and it is the honest description of a project that translates a specification into a different runtime rather than delegating to the original one. The project is Apache-2.0 licensed, the primary language is Swift, the last push to the main branch was on 2026-09-25, and the release history shows 1.2.0 on 2026-09-21, 1.1.0 on 2026-07-13 and 1.0.0 on 2026-06-11, so it is a young project that has already had a few feature releases. ## What it actually supports The feature list is six items and each one maps to a part of the Compose specification that the tool interprets. Compose file support means it parses and interprets docker-compose.yml files to configure Apple Containers. Apple Container orchestration means it launches and manages multiple containerized services using Apple's native container runtime. Environment configuration means it supports environment variable files, the .env file, to customise deployments. Service dependencies mean you can specify service dependencies and startup order, which is the feature that makes multi service applications work in the right sequence. Volume and network mapping means it maps data and networking as specified in Compose files to their Apple Container equivalents. And the last item is a statement of intent rather than a feature: the project is designed for future extension and customisation. The dependency and startup order support is the one worth dwelling on. In Docker Compose, depends_on with a condition is how you express that a service should not start until its database is ready, and reproducing that in a different runtime requires the tool to understand ordering and possibly health conditions. A bridge that implements the simple version gets you most of the way, and the simple version is what most Compose files use. The environment file support matters for a related reason. A Compose file usually references variables without defining them, and the .env file is where the values live, so a tool that ignores .env gives you a stack with the wrong configuration and no obvious error. ## Installing it, and the Swift build underneath The prerequisites are a Mac running macOS with Apple Container support, macOS Sonoma or later recommended, plus Git, and the Xcode command line tools if you are building from source. The recommended install is Homebrew, and it is two commands: ```sh brew update brew install container-compose ``` The source route is three steps. Clone the repository: ```sh git clone https://github.com/Mcrich23/Container-Compose.git cd Container-Compose ``` Build the executable, with a note to ensure you have Swift installed or the required toolchain: ```sh make build ``` And optionally install it globally: ```sh make install ``` The Makefile shows what those targets do, and it is worth reading because it explains the install path. The build target runs a release build of the Swift package with the sandbox disabled, and the install target depends on build, creates the bin directory under a prefix of /usr/local by default, and copies the built executable there. There are also uninstall and clean targets, where uninstall removes just the executable and clean removes the whole .build directory. The prefix variable means the install location is configurable, which matters on a Mac where /usr/local is often not on the path for a user who installed Homebrew into /opt/homebrew. The repository is a Swift package, with Package.swift and Package.resolved at the top level, a .swiftpm/ directory, Sources/ and Tests/ directories, a CONTRIBUTING.md, a SECURITY.md and a Sample Compose Files/ directory. ## Running it, and the macOS 15 DNS caveat After installation the tool is run with a single command: ```sh container-compose up ``` And you may need to provide a path to your docker-compose.yml and .env file as arguments, which tells you something about the default behaviour. The tool finds the Compose file in the working directory, and the arguments exist for the case where the file lives somewhere else, which is common when a project keeps its compose configuration in a subdirectory. The caveat is stated at the top of the README rather than buried, and it is the one thing to know before you install. Container-Compose does not automatically configure DNS for macOS 15, Sequoia, and the recommendation is to use macOS 26, Tahoe, for an optimal experience. That is a platform-level limitation rather than a bug in the tool, and it is the kind of thing that turns into an afternoon of debugging if you hit it without warning. Services that resolve each other by name depend on the DNS setup, and if the name resolution is not configured, a service that should be talking to a database is simply failing to connect with no obvious cause. The contribution guidance is a standard fork, branch, commit, test, push and pull request sequence, with the note to add tests to your changes, and the support guidance is to open an issue. One inconsistency in the README is worth flagging for a reader. The License section says the project is licensed under the MIT License, while the repository metadata reports Apache-2.0, and the LICENSE file in the repository is what settles it. The MIT sentence may be a leftover from an earlier state of the project, and the kind of contradiction that makes a difference if you are choosing a licence for a derived work. ## Conclusion Adopt Container-Compose if you already define your services with Compose files and want the same description to run on Apple Container instead of Docker, because the tool exists purely to translate that format rather than to wrap Docker. Do not adopt it expecting Docker compatibility, since the README says it is not a Docker or Docker Compose wrapper and it provides limited support. Before you rely on it, note that it does not configure DNS automatically on macOS 15, so use macOS 26 for the better experience, and check which parts of your Compose file it actually honours, since the project describes its support as limited. ## FAQ ### What does Container-Compose do with Apple Container? It parses and interprets docker-compose.yml files to configure Apple Containers, and launches and manages multiple containerized services using Apple's native container runtime. It also supports .env files, service dependencies and startup order, and maps volumes and networking from Compose files to Apple Container equivalents. The README stresses it is not a Docker or Docker Compose wrapper but a bridge between Compose workflows and Apple's container ecosystem. ### How do I install and run Container-Compose? With Homebrew, `brew update` and `brew install container-compose`, or from source with `git clone https://github.com/Mcrich23/Container-Compose.git`, `make build` and optionally `make install`. Then run `container-compose up`, passing a path to your docker-compose.yml and .env file as arguments if they are not in the working directory. ### Does Container-Compose work on macOS 15? It does not automatically configure DNS on macOS 15, Sequoia, and the README recommends macOS 26, Tahoe, for an optimal experience. The prerequisites otherwise ask for a Mac with Apple Container support, with macOS Sonoma or later recommended. ### What licence is Container-Compose under? The repository metadata reports Apache-2.0, while the README's License section says MIT and points at the LICENSE file. The LICENSE file in the repository is the one to check if you need the exact terms, particularly for a derived work. ## Sources - [Issues](https://github.com/Mcrich23/Container-Compose/issues) - [License: Apache-2.0](https://github.com/Mcrich23/Container-Compose/blob/main/LICENSE) - [Mcrich23/Container-Compose on GitHub](https://github.com/Mcrich23/Container-Compose) - [README](https://github.com/Mcrich23/Container-Compose/blob/main/README.md) - [Releases](https://github.com/Mcrich23/Container-Compose/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mcrich23-container-compose