Augani Dory: a native Apple Silicon runtime for Docker, Kubernetes and Linux VMs
Dory is the complete local development system for Apple Silicon: Docker, Compose, Kubernetes, virtual machines, and policy-bound agent sandboxes.
At a glance
- What is it?
- Dory replaces Docker Desktop on Apple Silicon Macs with a SwiftUI app and a versioned CLI that run containers, k3s clusters, graphical Linux machines and policy-bound agent sandboxes from one engine. It is GPL-3.0, Apple Silicon only, and its README is thin on rollback and upgrade detail.
- Who is it for?
- Adopt Dory if you develop on an Apple Silicon Mac and want Docker, k3s and graphical Linux machines under one GPL-3.0 runtime with a CLI that agents can drive. Do not adopt it on Intel hardware, and do not expect the README to tell you how to roll back an engine upgrade.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly Swift, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 29, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The gap Dory fills on an Apple Silicon Mac
Most Mac developers run three or four tools that do not know about each other: a container runtime, a VM manager for a Linux desktop, a Kubernetes distribution, and something to keep coding agents away from the host filesystem. Dory's claim is that these are one product. The README describes it as a "self-contained local runtime for software development on macOS" with no required Docker Desktop, external VM manager, account, cloud control plane, telemetry, or commercial-use tier. That last item matters for anyone whose employer restricts Docker Desktop licensing: Dory is GPL-3.0 and stores workload data on the Mac.
The target user is narrow and identifiable. You need an Apple Silicon Mac running macOS 14 or later, because the README states that Dory is built and qualified for Apple Silicon and that Intel support will follow after dedicated hardware validation. The current downloads and the Homebrew cask do not include an Intel build. If your team is still on Intel Macs, this project is not for you yet, and no configuration will change that.
Dory is not a thin wrapper around an existing engine. The repository layout shows a Swift application (Dory/), a storage provider split across DoryStorageProvider/ and DoryStorageShared/, a guest/ directory, a dory-core/ and dory-core-swift/ pair, patches/, and a rust-toolchain.toml. That is a runtime with its own guest and its own storage layer, not a UI over someone else's socket.
One shared container VM, separate machines for everything else
The architecture the README describes has two distinct virtualization paths. Containers share one persistent Linux engine. Its memory ceiling is configurable, and free guest pages can be returned to macOS. Linux machines are separate VMs with their own disk, address, resources, shell, shares and snapshots. The README is explicit that they are not disguised containers, which is the right call: a GNOME desktop and a headless Alpine server have different lifecycle needs from a container that should start in under a second.
Storage is a single managed `.dorydrive`, with external APFS drive support, sparse growth, verified backup, restore and safe selection. Networking covers localhost ports, automatic and user-defined local domains, trusted HTTPS, low ports, host services, custom DNS and proxy ports, and opt-in LAN access. Kubernetes is one-click k3s with selectable v1.34, v1.35 and v1.36 presets plus a native resource browser.
The agent story is the part that distinguishes Dory from a desktop container app. The README lists a versioned JSON guide, non-interactive schemas, read-only MCP mode, machine execution, and policy-enforced isolated sandbox VMs. The repository carries a SANDBOX_THREAT_MODEL.md at the top level, which suggests the sandbox boundary is documented rather than assumed. The README does not describe what the policy language looks like or where policies are stored, so anyone evaluating the sandbox for a security-sensitive workflow should read that threat model file directly.
Component packaging is deliberate. Dory 0.4.6 is described as one smaller Docker Core app with optional, signed Kubernetes, Linux Machines, Linux Desktop, Debian, Ubuntu and Kali components. The website shows the exact total before download, carries that choice into Dory for confirmation, and can remove optional payloads later without deleting containers, volumes, cluster state, machine disks, snapshots or exports. That separation is a real design decision: the base install stays small, and the heavy graphical desktops are opt-in.
Installing Dory with Homebrew and running your first container
The README gives one install path, a Homebrew cask:
brew install --cask Augani/dory/doryThe cask installs Docker Core only. Kubernetes, Linux Machines, or individual graphical desktop packs are added from inside Dory after it opens, so the first launch is where the optional components get chosen.
Open Dory once. According to the README, the daemon keeps `docker`, `docker compose` and `dory` available in `~/.dory/bin`, creates the `dory` Docker context, and points it at `~/.dory/dory.sock`. That means the standard Docker CLI keeps working, but it talks to Dory's socket rather than Docker Desktop's. The README excerpt does not give a command for inspecting which context is active; the Docker context is named `dory`, so that is the name to look for when you check your CLI configuration.
For a first real use, the README's own framing is that Dory gives standard Docker tools a native Apple Silicon engine, so the first thing to try is a normal container run through the Docker CLI that is now pointed at the Dory context. If it fails, the README points at Dory's active diagnostics, targeted repair, and support bundles rather than a manual daemon restart: engine restarts require clear intent, and cleanup is a dry run by default. Installing the Kubernetes component adds `k` to the same bin directory, though the README excerpt does not spell out the full command surface for it.
Migration is transactional, with a completeness report you should read
Dory imports from Docker Desktop, OrbStack, Colima, Rancher Desktop, Podman, or another Docker-compatible socket. The README describes the import as transactional, in either a full or an exact-selection mode, and says it produces a selected/verified/omitted completeness report. That report is the part worth your attention. A migration that silently drops a volume is worse than one that refuses to run, and a report that names what was omitted is the difference between the two.
The README does not document rollback for a completed migration. It documents that ordinary uninstall keeps the selected data drive, and that cleanup is a dry run by default, but there is no described path for undoing an import after it commits. If you are moving a production-adjacent local environment, take a verified backup through Dory's storage surface first, or test the import against a scratch drive.
The same caution applies to desktop component updates. Signed Debian, Ubuntu, Kali and graphical-kernel component updates are applied to existing persistent guests. Dory creates a last-good snapshot, preserves installed applications and user data, reboots and qualifies the desktop, and restores the snapshot automatically if installation, boot or qualification fails. That is a well-specified failure path. What the README does not say is how long a last-good snapshot is retained, or how many of them accumulate. On a laptop with a fixed disk, that is a real question.
Where Dory is the wrong choice
The Intel exclusion is the hardest limitation, and it is not a temporary inconvenience you can work around. The README states downloads and the Homebrew cask do not include an Intel build, and that Intel support follows after dedicated hardware validation. There is no source-build instruction in the excerpt for producing one yourself.
GPL-3.0 is the second constraint. For local development this is usually a non-issue, but if your organisation has a blanket ban on GPL software in the developer toolchain, Dory is caught by it. The README does not offer a commercial licence or an exception, and it explicitly says there is no commercial-use tier. Nothing here is legal advice; the point is that the licence question has one answer and you should not expect a second one.
Third, Dory is a runtime with its own guest and storage layer. That is more to maintain than a CLI that shells out to an existing daemon. The README's answer is targeted repair, active diagnostics and support bundles, plus a storage layer with verified backup and restore. Whether that is enough depends on how much you depend on the runtime. If you only need `docker build` and `docker run` a few times a week, a smaller tool will do, and the optional Kubernetes and Linux desktop payloads are weight you will never open.
Finally, the documentation has gaps. The README excerpt does not cover rollback of an engine upgrade, snapshot retention limits, or the policy format for sandbox VMs. Those are exactly the areas where an operator needs specifics.
How Dory differs from OrbStack
OrbStack is the obvious comparison, and it appears in Dory's own topics list and in the migration sources. The difference is scope rather than speed. OrbStack is a fast container and Linux machine runtime for macOS. Dory ships containers, k3s with selectable v1.34, v1.35 and v1.36 presets, full graphical desktops (Ubuntu 24.04 LTS GNOME, Debian 13 Xfce, Kali rolling Xfce) alongside lightweight Alpine headless VMs, and a policy-enforced sandbox tier for coding agents.
That breadth is also the trade-off. A tool that manages a Kubernetes cluster, a GNOME desktop and an agent sandbox has more surface area to get wrong than one that runs containers well. Dory's answer to that is componentisation: Kubernetes and the Linux desktop packs are optional signed components that can be removed later without deleting containers, volumes, cluster state, machine disks, snapshots or exports. If you never install them, you are running Docker Core plus a SwiftUI app.
The second difference is automation. Dory exposes JSON schemas, safe dry runs, event streams, wait commands, a machine-readable guide, and MCP. OrbStack's CLI is capable, but Dory treats agent operation as a product surface rather than something you script around. If your workflow involves coding agents that need to start containers or inspect a cluster without scraping a UI, that is the reason to pick Dory over a runtime with a thinner automation contract.
A third option is Colima, which is also listed as a migration source. Colima is a CLI-first approach built on Lima, with no native app. Dory's pitch against that is the graphical path: the README states that engine resources, storage, migration, automatic and custom domains, low ports, LAN access, Auto-Idle, machine environment policy, USB and managed defaults all have a graphical setting.
Maintenance, releases and upgrade cost
The repository is not archived, and the last push was on 2026-09-06. The most recent release listed is v0.4.5 on 2026-08-13, following v0.4.4 on 2026-08-11 and v0.4.3 on 2026-08-06. Those three releases land within a single week, which tells you the project is moving in small increments rather than large ones. The README also references Dory 0.4.6, which is ahead of the newest listed release.
Upgrade cost has two parts. The base app is one smaller Docker Core app, so upgrading it is an app replacement. The optional Kubernetes and Linux desktop components are signed and versioned separately, and desktop component updates are applied to existing persistent guests with a last-good snapshot taken first. That snapshot mechanism is what makes an upgrade survivable, and it is also what you should watch on disk usage.
The compatibility surface is versioned in a way that matters for planning. Kubernetes presets are pinned at v1.34, v1.35 and v1.36, so a cluster you create today has a defined version rather than whatever is current. Docker Core ships the Docker 29 API and CLI, Buildx, BuildKit and Compose v2. If your tooling depends on a specific API version, check COMPATIBILITY.md in the repository before you migrate, because the README does not enumerate every supported combination.
On licensing, GPL-3.0 applies to Dory itself. The README states there is no commercial-use tier and no account requirement, and that workload data stays on the Mac. Whether GPL-3.0 obligations reach your own code depends on how you link to or distribute Dory, which is a question for your legal team rather than this article.
Editorial conclusion
Adopt Dory if you develop on an Apple Silicon Mac and want Docker, k3s and graphical Linux machines under one GPL-3.0 runtime with a CLI that agents can drive. Do not adopt it on Intel hardware, and do not expect the README to tell you how to roll back an engine upgrade. Before committing, run a migration dry run and read COMPATIBILITY.md and SANDBOX_THREAT_MODEL.md in the repository.
Frequently asked questions
What is Augani Dory?
Dory is a local development runtime for Apple Silicon Macs that combines a Docker engine, Compose v2, one-click k3s Kubernetes, graphical and headless Linux virtual machines, and policy-bound agent sandboxes in one SwiftUI app with a versioned CLI. The README describes it as self-contained, with no required Docker Desktop, account, cloud control plane or telemetry, and it is licensed GPL-3.0.
How do I install Augani Dory on a Mac?
The README gives a single Homebrew cask: brew install --cask Augani/dory/dory. That installs Docker Core only; Kubernetes, Linux Machines and individual graphical desktop packs are added from inside Dory after it opens. Dory requires an Apple Silicon Mac running macOS 14 or later, and the current downloads and cask do not include an Intel build.
Is Augani Dory a Docker Desktop alternative for macOS?
Dory is positioned that way. It ships the Docker 29 API and CLI, Buildx, BuildKit, Compose v2, registries, bind mounts, volumes and custom networks, and it can import transactionally from Docker Desktop, OrbStack, Colima, Rancher Desktop, Podman or another Docker-compatible socket with a selected/verified/omitted completeness report.
Can Augani Dory run Kubernetes locally?
Yes. The README describes one-click k3s with selectable v1.34, v1.35 and v1.36 presets plus a native resource browser. Kubernetes is an optional signed component rather than part of the base Docker Core install, and the README states it can be removed later without deleting containers, volumes, cluster state, machine disks, snapshots or exports.
Does Augani Dory work on Intel Macs?
No. The README states Dory is built and qualified for Apple Silicon, that Intel support will follow after dedicated hardware validation, and that current downloads and the Homebrew cask do not include an Intel build.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/augani-dory)