Orchard v2.4.2
Installation
- Download the DMG file below
- Open the DMG and drag Orchard.app to your Applications folder
- Launch Orchard from Applications
Changes
Hi everyone, this release is a huge one personally, and one that's long overdue.
Since Apple launched container, everyone's been looking for Compose support so Docker Compose files can be brought across. The maintainers themselves have turned this down in several issues, pushing it onto the community. I've closed a lot of feature requests because I hoped this would be a core feature, but the maintainers made it very clear they are not going to work on it.
In the early days, many people, including myself, attempted to build something to solve that. However, they were all independent binaries, and still are — requiring their own commands and not portable.
A few releases ago, container added support for plugins, the first of which is an official k8s one — it's the same plugin Orchard itself calls to bring k8s to your box.
So in order to bring these worlds together, I've created a new project, compose, which is a plugin for apple/container that can be installed without Orchard (although it's offered to you with minimal work involved via the UI).
The syntax for compose looks exactly how you would want it:
container compose up --helpI'm opening that up in the hope that other developers can contribute to it and make it the standard way to use Compose with containers. There is no Orchard logic in it — it's a plugin and can be bundled as a Swift library in 3rd party tools such as other UI's or applications, instead of being proprietary.
With this being so new, if you have any feedback or want to contribute, please do!
Check out the project and give this new Orchard release a go — navigate to the Compose view where it will be installed for you, if you wish.
Added
-
The shell a container terminal opens with is now a setting, taken as written and passed through with its flags, so
bash -lgets a login shell that reads your rc files (#107). Which shells an image has and which flags they accept is a property of the image, so there is nothing here for Orchard to enumerate and nothing worth validating beyond refusing to send an empty command.shremains the default because it is the one shell a minimal image is likely to have, which makes it a safe default rather than a good one. -
A Compose tab, for bringing a set of services up and down from a compose file. Projects are found by the labels on their containers rather than by any file Orchard keeps, so a project brought up from the terminal appears here without Orchard having been told anything, and a project Orchard has been shown a file for can be brought up, taken down and reconciled from the window. Running
upa second time compares each service against a hash stamped on the container it produced, then creates, starts, leaves alone, recreates or removes each one accordingly, and every step is listed as it happens. -
Compose keys that cannot be honoured are never quietly dropped. Adding a project shows what will be ignored, how much ignoring it costs, and the line each key sits on, and the project goes on showing that afterwards: three weeks later nobody remembers what they accepted, and the containers cannot tell them. A file that grows a new unhandled key is put back in front of you before the next
uprather than waved through on an older answer. A service that builds is built through the same path as the Images tab, so its BuildKit log shows up under Builds like any other build.The planning behind the tab is andrew-waters/compose, a Swift package Orchard links and which also backs the
container composeplugin, so the terminal and the window cannot drift apart. Two limitations are worth stating up front: without health reporting in the runtime,upstarts dependencies before dependents but does not wait for them to become ready, and hostnames have to be unique across every container on the machine, so a service answers to<project>-<service>rather than to its service name. -
The Compose tab offers to install the
container composeCLI plugin when it is not there. Orchard itself never needs it, because the window links the planner and runs plans over XPC, so this is an offer rather than a fault and the banner is coloured accordingly: every project in the list works with nothing installed. It is worth offering because container's own installer clears the plugin directory on every upgrade (apple/container#1617), so a plugin someone installed by hand goes missing again through no fault of theirs. Installing fetches the latest release, unpacks it, and puts the two files where the CLI looks, with the work shown step by step in a sheet: this downloads 15MB and then asks for an administrator password, and someone about to be asked for their password should be able to see what asked and why. Everything up to the copy happens unprivileged in a temporary directory, so a failure before that point never prompts at all, and a download in flight can be cancelled.
Fixed
- Ghostty no longer gets a new window, and a second copy of itself, every time you open a container terminal (#107). Orchard launched it with
open -na, and-nstarts a separate instance: a window in one instance can never join a window in another, so a new window was not a design choice so much as an inevitability, and every container opened left another Ghostty running. Ghostty 1.3 ships a scripting dictionary, so it is now driven the way Terminal.app and iTerm2 already were rather than throughopen, and all three stop being special cases. Whether the terminal arrives as a tab or a window follows the system-wide "Prefer tabs when opening documents" setting rather than a preference of Orchard's own: you have answered that question once, for every app. macOS defaults that tofullscreenrather thanalways, so the default is still a window; the difference is that it is now the system's answer rather than Orchard overriding it.
Checksums
- SHA256: See the
.sha256file for verification
System Requirements
- macOS 26 (Tahoe)
- Apple Container installed