Dory replaces Docker Desktop on Apple Silicon Macs with a Swift-based runtime that also ships one-click k3s, graphical Linux VMs and MCP-accessible agent sandboxes. It is a serious fit for solo Mac developers who want one installer and no account, and a poor fit for anyone on Intel hardware or a mixed-OS team.

Can I use Augani/dory 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 Augani/dory still maintained?

Yes. The repository last received commits 2 days ago.

What programming language is Augani/dory written in?

Mainly Swift, according to GitHub's language statistics.

Dory review: Docker, Kubernetes and Linux VMs for Apple Silicon

At a glance

What is it?: Dory replaces Docker Desktop on Apple Silicon Macs with a Swift-based runtime that also ships one-click k3s, graphical Linux VMs and MCP-accessible agent sandboxes. It is a serious fit for solo Mac developers who want one installer and no account, and a poor fit for anyone on Intel hardware or a mixed-OS team.
Who is it for?: Adopt Dory if you develop on an Apple Silicon Mac running macOS 14 or later, you want Docker, Compose and k3s from one signed installer, and you are willing to accept GPL-3.0 terms and a project whose latest release is 0.4.5. Do not adopt it if you need Intel Mac support, a Windows or Linux client, or a long-established commercial support contract.
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 15, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

Hysen Labs Editorial · September 11, 2026 · Augani/dory

The macOS container gap Dory is trying to close

On Apple Silicon, Docker Desktop is the default answer and it comes with a licence tier, an account, and a background service you do not fully control. Alternatives exist (OrbStack, Colima, Rancher Desktop, Podman) but each one tends to solve one slice: containers, or Kubernetes, or a Linux VM. Dory's pitch in the README is that it covers all three in a single native app, with no required account, no telemetry, no cloud control plane and no commercial-use tier. The target user is a developer on an Apple Silicon Mac who wants Docker 29 API and CLI, Buildx, BuildKit and Compose v2 to work, plus a k3s cluster and a graphical Linux desktop, without stacking three separate tools. The README is explicit that this is Apple Silicon only: Intel Mac support is described as following later, after dedicated hardware validation, and current downloads and the Homebrew cask do not include an Intel build. That single sentence disqualifies Dory for anyone still on an Intel MacBook or a Mac Pro tower.

One container VM, separate Linux machines, signed optional components

The architecture visible in the README has three layers. First, a single persistent Linux engine runs containers: its memory ceiling is configurable and free guest pages can be returned to macOS, so containers share one VM rather than each spinning up its own. Second, Linux machines are separate VMs with their own disk, address, resources, shell, shares and snapshots. The README states plainly that they are not disguised containers, which matters if you need to test kernel modules, systemd units or a real GNOME session. Third, Kubernetes is a one-click k3s install with selectable v1.34, v1.35 and v1.36 presets and a native resource browser. Dory 0.4.6 is described as one smaller Docker Core app plus optional signed Kubernetes, Linux Machines, Linux Desktop, Debian, Ubuntu and Kali components. The website shows the 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 decoupling is the most interesting design decision here: instead of shipping a monolithic app, Dory treats Kubernetes and desktop images as removable payloads.

Networking, storage and the .dorydrive model

The README lists localhost ports, automatic and user-defined local domains, trusted HTTPS, low ports, host services, custom DNS and proxy ports, and opt-in LAN access. Custom domains and trusted HTTPS are the features people usually reach for OrbStack or a separate reverse proxy to get, so having them in the same app is a real convenience. Storage is a single managed .dorydrive with external APFS drive support, sparse growth, verified backup, restore and safe selection. The README does not spell out the on-disk format of .dorydrive beyond calling it managed, so if you care about portability of that data you will need to check the architecture docs rather than the README. Networking being opt-in for LAN access is the right default: it means a fresh install is not silently exposing containers to your local network.

Installing Dory and what the daemon puts on disk

The README gives one install path that can be verified from the repository text: brew install --cask Augani/dory/dory. That cask installs Docker Core; Kubernetes, Linux Machines and individual graphical desktop packs are added from inside Dory after it opens. On first launch the daemon keeps docker, docker compose and dory available in ~/.dory/bin, creates the dory Docker context and points it at ~/.dory/dory.sock. Installing the Kubernetes component adds a k command (the README text is truncated at that point, so the full command name and behaviour are not confirmable from the supplied material). For automation, the README lists versioned JSON schemas, safe dry runs, event streams, wait commands, a machine-readable guide, read-only MCP mode, machine execution and policy-enforced isolated sandbox VMs. The practical implication: if you script against Dory, you should target the versioned schemas rather than the SwiftUI app, because the README treats the CLI and MCP surface as a first-class product rather than an afterthought.

Migration from Docker Desktop, OrbStack, Colima and Podman

Dory offers transactional full or exact-selection import from Docker Desktop, OrbStack, Colima, Rancher Desktop, Podman or another Docker-compatible socket, with a selected/verified/omitted completeness report. The word transactional is doing real work here: it implies the import either completes or rolls back, and the completeness report tells you what did not make it across. That report is the part worth reading carefully on a first migration, because images, volumes and networks are the things people assume transferred when they did not. The README does not describe how long a migration takes, how large the intermediate copy is, or whether the source tool must be stopped first. Treat those as open questions to resolve before you point Dory at a working Docker Desktop install you depend on.

Where Dory is the wrong tool

The hardest constraint is hardware. Apple Silicon only, macOS 14 or later, and no Intel build in the current downloads or Homebrew cask. If your team is mixed between Intel Macs, Apple Silicon Macs and Linux workstations, Dory is not a shared standard you can mandate. The second constraint is licence. Dory is GPL-3.0. That is fine for individual developers and for many internal uses, but it is a different posture from Docker Desktop's commercial terms, and any organisation with a policy against GPL tooling in the developer stack needs to resolve that before rollout. The third constraint is maturity. The most recent release listed is v0.4.5, dated 2026-08-13, with v0.4.4 and v0.4.3 in the same month. That is a fast patch cadence on a pre-1.0 project. The README also mentions Dory 0.4.6 as the current shape of the product, which suggests the documentation is tracking slightly ahead of the latest tagged release. If you need a runtime with years of production mileage behind it, Dory is not that yet.

How Dory differs from OrbStack and Colima

The closest comparison named in the README's own migration list is OrbStack. OrbStack is a commercial macOS container and Linux machine tool; the difference in approach is that OrbStack is a focused product you buy, while Dory is GPL-3.0 software that bundles Docker, k3s and graphical Linux desktops under one native SwiftUI app and one CLI. Colima takes the opposite tack: it is a CLI-driven wrapper around Lima, so you get a Linux VM and a Docker socket with very little GUI, and you assemble Kubernetes and desktop environments yourself. Dory's bet is that Mac developers want the assembled version, including the graphical Ubuntu, Debian and Kali desktops and the snapshot, clone, import and export flows around them. If you already have a Colima setup you like, Dory is not obviously better; it is more opinionated and more surface area to learn.

Maintenance, updates and GPL-3.0 implications

The README describes desktop component updates as 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 snapshot-and-rollback pattern is the kind of thing you normally build yourself around a Linux VM, so having it in the product is a genuine reduction in maintenance work. Repairs are described as targeted, cleanup as a dry run by default, and ordinary uninstall as keeping the selected data drive. On licence: Dory is GPL-3.0. That means the source is available and modifications you distribute carry the same licence. This is not legal advice, and whether GPL-3.0 is acceptable in your environment depends on how you use and redistribute the software, so check with whoever handles licensing at your organisation. There is no commercial support tier mentioned in the README, only a GitHub Sponsors link, which is worth weighing if you need a support contract.

Editorial conclusion

Adopt Dory if you develop on an Apple Silicon Mac running macOS 14 or later, you want Docker, Compose and k3s from one signed installer, and you are willing to accept GPL-3.0 terms and a project whose latest release is 0.4.5. Do not adopt it if you need Intel Mac support, a Windows or Linux client, or a long-established commercial support contract. Before installing, read COMPATIBILITY.md, confirm the exact optional components you want (Docker Core alone, or with Kubernetes, Linux Machines and desktop packs), and run the migration dry run against your current Docker Desktop, OrbStack, Colima, Rancher Desktop or Podman setup so you can see the selected, verified and omitted report before committing.

Official sources

Community notes