Augani/dory

One Mac. Your whole development world.
Docker, Compose, Kubernetes, Linux virtual machines, and policy-bound agent sandboxes
in one native, open-source local development system.

Website · Download · Compatibility · Architecture · Performance evidence · Sponsor · Agent reference

Dory is built and qualified for Apple Silicon. Intel Mac support will follow after dedicated hardware validation. Current downloads and the Homebrew cask do not include an Intel build.

Dory 0.4.6 is 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.

Explore the interactive Dory interface

Dory is a self-contained local runtime for software development on macOS. It gives standard Docker tools a native Apple Silicon engine, adds one-click Kubernetes, full graphical Linux desktops, and persistent headless servers, and keeps the whole workspace operable from both a SwiftUI app and a versioned command-line interface.

There is no required Docker Desktop, external VM manager, account, cloud control plane, telemetry, or commercial-use tier. Dory is GPL-3.0 software and stores workload data on your Mac.

• A complete runtime, not a dashboard. Docker Core includes its engine, guest, Docker tools, Compose, Buildx, networking, file sharing, and recovery tools. Kubernetes and Linux machine payloads are signed components rather than permanent app weight.
• One shared container VM. Containers use one persistent Linux engine. Its memory ceiling is configurable, and free guest pages can be returned to macOS.
• Linux machines beside containers. Machines are separate VMs with their own disk, address, resources, shell, shares, and snapshots. They are not disguised containers.
• Install custom arm64 Linux. Choose an installer ISO and virtual-disk size in the desktop creation flow. Dory fingerprints the exact media, reports architecture compatibility separately from runtime qualification, and privately imports accepted bytes. It preserves the VM's EFI identity and NVRAM; eject or reattach the ISO from the machine menu after installation. A private bidirectional serial console supplies durable boot diagnostics and recovery input. Snapshots preserve the disk and EFI firmware state together, including across export/import.
• Desktops update without recreation. 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.
• Every important setting is in the app. 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 path.
• Automation is a product surface. JSON schemas, safe dry runs, event streams, wait commands, a machine-readable guide, and MCP let coding agents operate Dory without scraping the UI.
• Recovery preserves data. Repairs are targeted, cleanup is a dry run by default, engine restarts require clear intent, and ordinary uninstall keeps the selected data drive.

brew install --cask Augani/dory/dory

The Homebrew cask installs Docker Core. Add Kubernetes, Linux Machines, or individual graphical desktop packs from Dory after it opens.

Open Dory once. 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 kubectl. Docker Desktop and a separate Docker CLI install are not required.

Start with the one Apple Silicon Dory 0.4.6 Docker Core DMG. The signed catalog shows its exact download and installed sizes. Drag Dory to Applications, open it, then add only the components you want. The website's component selector can open the same selection in Dory after installation. Dory shows the signed sizes again and waits for explicit confirmation before downloading any optional payload.

Docker Core contains Dory.app, the Docker engine and CLI, Compose, Buildx, networking, storage, migration, diagnostics, and recovery. The signed component catalog offers:

Component download and installed sizes come from the signed release catalog, not estimates. Dory stores installed payloads inside the selected .dorydrive/components directory. Removing a component reclaims only its installed payload. Workload data on the selected drive is preserved. The Kubernetes component size covers kubectl; the selected k3s container image is downloaded on first cluster creation and then remains in Docker storage on the selected data drive.

The native Components screen and dory component commands install, update, verify, and remove the same catalog entries. Components are transactional, digest-verified, architecture-checked, and activated atomically. A cached catalog is used offline only after its signature is verified again. The Core app reuses its signed engine kernel and rootfs for its macOS 14 fallback through internal aliases, so compatibility does not make users download duplicate VM payloads.

Dory.app uses one signed update feed while optional components update independently on the selected data drive, so an app update cannot silently add a large Linux payload.

Use Settings > Updates for the normal in-place upgrade. Dory verifies the Sparkle feed and signed archive, free space, selected data drive, component compatibility, and readable data-schema path; records the exact app, configuration, component generation, and verified snapshot reference; then runs Docker API, volume-marker, pre-existing container/port, and optional Kubernetes smoke tests on the next launch.

If that smoke test fails, Dory restores the exact last-known-good app, configuration, and verified component generation without blindly downgrading durable data. An unsafe schema rollback stops in a guided recovery state and produces an owner-only export instead of guessing. Inspect either path:

dory upgrade status --json
dory upgrade recovery --json

Homebrew installations can use the normal cask upgrade; workload data remains on the selected .dorydrive:

brew update
brew upgrade --cask Augani/dory/dory

Uninstall/reinstall is a recovery option, not the normal update workflow. Ordinary uninstall still preserves the selected drive. Keep only one copy of Dory.app so macOS registers the correct bundled services.

• Apple Silicon Mac
• macOS 14 Sonoma or later
• 8 GiB of Mac memory recommended for mixed container, Kubernetes, and machine workloads
• Xcode 26 or later only when building Dory from source

Wait for the app to report that the engine is ready, then use normal Docker commands:

docker context use dory
docker run --rm hello-world
docker run -d --name web -p 8080:80 nginx
open http://localhost:8080

Start a Compose project from a terminal or open its YAML file from the Compose screen:

docker compose up -d
docker compose ps

Check the full runtime before a development session:

dory doctor --active
dory routes --json
dory disk --json

Dory is designed for existing Docker clients and standard Docker API consumers. dory <args> is also a direct passthrough to the bundled Docker CLI, so dory ps and docker ps target the same engine.

Use the CLI for the full Docker surface. In the app you can:

• create, start, stop, restart, inspect, and delete containers;
• group and control Compose services together;
• filter all, running, and stopped containers;
• view CPU and memory activity, ports, configuration, and environment variables;
• stream and copy logs;
• use an embedded interactive shell or open a separate Terminal.app window;
• open published ports from the container row.

• Pull, build, run, inspect, tag, save, load, delete, and prune images.
• Create, inspect, browse, copy, delete, and prune named volumes.
• Create bridge networks with custom IPAM, aliases, connect or disconnect containers, inspect, delete, and prune.
• Authenticate to private registries with Docker-compatible credential flows.

Buildx and BuildKit are bundled. Dory supports build contexts, secrets, SSH mounts, cache import and export, registry authentication, cancellation, and common multi-stage builds. Native arm64 images are fastest. Common linux/amd64 images and build workloads run on Apple Silicon through Dory's built-in FEX path, which is enabled by default on new installs and can be changed in Settings. This translates x86_64 Linux applications inside Dory's ARM64 container VM; it does not boot an Intel guest OS or installer. Rosetta has the same application-only boundary when used inside an eligible ARM64 Linux VM. Dory exposes no partial x86 VM mode. Future whole-system x86 support requires a complete packaged QEMU TCG backend with independently qualified firmware, devices, lifecycle, security, recovery, and performance; see the x86 whole-machine emulation contract.

The Build Activity screen keeps durable status, logs, cache use, and cancellation controls for builds launched by Dory. Builds started by another Docker client remain that client's responsibility; Dory does not pretend it can safely cancel work it did not launch.

Paths in your Mac home directory and on mounted drives under /Volumes are shared at their native paths. Dory's release gates cover read, write, truncate, spaces in paths, host edit visibility, file locking, and watcher behavior. Run this when a tool such as Vite, Tailwind, or Webpack does not see changes:

dory mount --json
dory doctor --json --only mounts,watch,filelock

Dory bundles Compose v2. Profiles, override files, .env, builds, health dependencies, named volumes, custom networks, and external resources use the normal docker compose workflow. The native Compose screen can open a YAML file, start or stop a project, restart running services, run down, and jump from a service to its container details.

Install the Kubernetes component from the app or with dory component install kubernetes before enabling a cluster in the focused release. Docker-only users do not download kubectl.

The Kubernetes screen creates a local k3s cluster inside the shared engine and lets you choose a supported v1.34, v1.35, or v1.36 preset. The selected k3s image is downloaded on first enable and stored with Docker data on the selected Dory drive. Switching versions recreates the cluster and is presented as a destructive action.

The native browser covers:

• pods with logs, exec, copy, and delete;
• deployments with scale and rolling restart;
• services, ConfigMaps, Secrets, and Ingresses;
• namespace filtering, YAML apply, rollout status, and kubeconfig copy.

The component-managed kubectl and dory k8s <kubectl args...> target the same cluster. k3s has its own image store, so push a built image to a registry or import it into the cluster before using it in a Pod.

Install Linux Machines for headless guests. Graphical guests additionally need the Linux Desktop Runtime and the selected Debian, Ubuntu, or Kali distribution component.

Dory Linux machines are persistent, separate VMs rather than containers. The app offers Canonical's Ubuntu 24.04 LTS GNOME desktop plus Debian 13 and Kali Linux rolling Xfce desktops for graphical and command-line applications. A lightweight Alpine-based headless profile remains available for services, terminals, test environments, and agent work. Each machine has its own disk, address, resources, shares, and snapshots.

From the app or CLI you can:

• create, start, stop, delete, and inspect machines;
• choose Desktop Linux or Headless Linux when creating a machine in the app;
• choose 1 to 8 CPUs and 1 to 16 GiB of memory per machine;
• configure the desktop Linux username, then use its GNOME or Xfce session, embedded terminal, or an external terminal selected in Settings;
• use a root shell for lightweight headless machines or dory machine shell NAME;
• execute structured commands with dory machine exec NAME --json -- COMMAND;
• share the Mac home directory or add only selected folders;
• set a DNS target override and reach machines through local domains;
• install verified Node.js, Python, Go, Rust, Java, Ruby, or DevOps recipes;
• take, restore, clone, export, import, and delete snapshots.

Headless CLI example:

dory machine create dev
dory machine start dev
dory machine exec dev --json -- /bin/sh -lc 'apk add git && git --version'
dory machine snapshot dev --note before-upgrade
dory machine shell dev

Dory can keep local recovery bundles for a machine on an hourly, daily, or weekly schedule. Every run creates a scheduler-owned snapshot, exports a .dorymachine bundle, re-imports it to verify the archive, and publishes it atomically only after verification. The first run—and then every configured interval—also starts a disposable imported machine and requires it to reach the running state before deleting that verifier.

dory machine backup schedule dev --frequency daily --keep 7 --verify-every 7
dory machine backup status dev
dory machine backup run dev
dory machine backup remove dev

Snapshot creation briefly stops a running source machine and restores its prior state. Retention deletes only scheduler-owned archives and snapshots; manual snapshots are never touched. This is a local backup contract, not an S3 or managed offsite service, so copy important verified archives to independent storage as part of your normal backup policy.

Desktop machines use native arm64 Ubuntu 24.04 LTS with GNOME or Debian 13 and Kali rolling with Xfce, plus systemd, Bash, a configurable login user, and a 64 GiB thin-provisioned disk stored in the selected .dorydrive. Their window follows the Mac display at a true 2x framebuffer, resizes dynamically, and configures the selected desktop for Retina-sharp text and controls. They run normal graphical and command-line Linux applications and can mount the Mac home at ~/Mac only when the user enables that share. Installing a newer desktop component updates matching existing guests in place; their automatic last-good snapshot remains available in the normal snapshot list for manual rollback. Headless machines retain the smaller Alpine, root, and /bin/sh contract.

The custom ISO path accepts arm64 Linux installation media on Apple Silicon. It verifies the media architecture before allocation, computes an SHA-256 identity, and evaluates exact media/host runtime evidence separately; a known-unstable tuple is blocked while unknown media is clearly reported as unqualified. It uses native EFI and an NVMe root disk with fsync semantics, plus VirtIO display, network, audio, pointer, keyboard, clipboard, and memory-balloon devices; the distribution must include drivers for the devices it needs. Desktop ISO machines default to four vCPUs and 4 GB of memory as balanced resource defaults, not as compatibility claims. This path remains preview until the real-installer physical-Mac release matrix passes. Intel/x86_64 ISOs are rejected before allocation; Rosetta and FEX cannot boot them.

New machines do not receive arbitrary host environment variables. Settings contains an allow-list. ANTHROPIC_API_KEY is the default entry, while OPENAI_API_KEY, GH_TOKEN, and HF_TOKEN are available presets. Only named, non-empty values are copied at creation time.

Mac folders are also private by default. A persistent machine sees only mounts selected at creation, and an agent sandbox sees no host files unless an explicit mount is supplied.

CLIs inside a machine can optionally open authentication pages in the Mac browser and complete localhost callbacks through Dory's browser-login bridge.

Settings > Migrate & Compare detects Docker Desktop, OrbStack, Colima, Rancher Desktop, Podman, and other running Docker-compatible Unix sockets. It shows a preflight inventory before writing to Dory.

The import can preserve:

• image content and visible tags;
• named volume data;
• custom networks and detected IPAM settings;
• container configuration and Compose labels;
• writable container layers;
• port bindings;
• running, stopped, and paused state.

The source is treated as read-only. You can import everything or choose an exact set of images, volumes, networks, and containers; Dory automatically includes required dependencies. Capacity, portability, and name collisions are checked before writes, an interrupted import keeps recovery state, and success includes a completeness report for requested, automatically selected, verified, and deliberately omitted objects. Dory re-inventories both selected and omitted source objects before declaring success, never deletes the source, and rolls back target writes on failure. Bind-mounted files already live on the Mac and are referenced at their existing paths rather than copied into the data drive.

Keep the old runtime installed until the preflight and post-import checks pass.

The default data drive is:

~/Library/Application Support/Dory/Dory.dorydrive

Images, containers, named volumes, custom networks, machine disks, and snapshots live together in this managed drive. Runtime sockets, replaceable logs, and caches remain under ~/.dory.

Dory supports:

• local APFS data drives, including mounted drives under /Volumes;
• sparse Docker storage from 128 GiB to 2 TiB;
• safe growth without preallocating the full logical capacity;
• stopped-engine backups with chunk manifests and completion markers;
• full backup verification before restore;
• restore to a new path without overwriting an existing drive;
• explicit selection of a restored drive with the same durable identity.

Shrinking is refused. To move to a smaller drive, back up and restore into a new destination.

dory data path
dory data capacity --json
dory data grow 256 --json
dory data backup ~/Desktop/dory.dorybackup
dory data verify ~/Desktop/dory.dorybackup
dory data restore ~/Desktop/dory.dorybackup /Volumes/Work/Dory.dorydrive
dory data use /Volumes/Work/Dory.dorydrive

Published ports bind to localhost by default. Dory never widens an explicit 127.0.0.1 or ::1 binding.

Optional system integration adds:

• automatic names under *.dory.local or a per-user custom suffix;
• exact or leftmost-wildcard custom hostnames routed to a selected published HTTP port;
• a local certificate authority for trusted HTTPS;
• Dory-owned resolver and packet-filter rules;
• built-in forwarding for ports 80, 443, and published TCP ports below 1024;
• source-preserving LAN and Tailscale access as an explicit opt-in.

Settings > Network shows the exact plan before macOS authorization and can remove Dory-owned rules. The Docker bridge subnet, DNS resolver, HTTP proxy, and HTTPS proxy ports are configurable. This allows Dory to avoid VPN or local-network conflicts and lets separate macOS accounts choose unique suffixes and local service ports.

Custom hostnames must already resolve to 127.0.0.1 through /etc/hosts or local DNS. Add them in Settings > Network, for example admin.myproject.local or *.myproject.local to published port 80. Because /etc/hosts does not expand wildcards, use local DNS or list each hostname that should match a wildcard route. Dory's HTTP and HTTPS proxies then preserve the requested Host header and route both standard ports without a second forwarding app. The same configuration is available from the terminal:

dory network custom-domains
dory network set-custom-domain admin.myproject.local --published-port 80
dory network remove-custom-domain admin.myproject.local

Corporate networks use a separate guided profile in Settings > Network. It covers the observed macOS system/PAC proxy, dockerd pulls, the shared Docker client proxy used by BuildKit and default container injection, registry mirrors/insecure registries, digest-pinned CA scopes, split DNS, and bridge/VPN collisions. Dory preserves unrelated ~/.docker/config.json keys and disables only state whose ownership digest still matches. Preview every mutation before applying:

dory network corporate sample > corporate-profile.json
dory network corporate plan --file corporate-profile.json
dory network corporate apply --file corporate-profile.json
dory network corporate status --json
dory network corporate disable

Status probes retain the exact DNS server, route/interface/gateway, selected proxy, and CA IDs used. Proxy URLs containing credentials are rejected; keep credentials in the corporate proxy's own SSO/keychain flow rather than a profile or support bundle.

Containers reach Mac services through host.dory.internal. Common host AI endpoints are available without enabling preview guest GPU support:

Useful commands:

dory routes --json
dory network --json --active
dory network authorization-plan --json
dory network authorize --json --dry-run
dory network authorize --json --apply
dory network --lan-visible on

dory expose can also print or start a cloudflared command for a temporary public HTTPS tunnel.

Settings > Engine & Daemon controls the engine backend, CPU count, memory ceiling, common amd64 container-application support, and preview dual VirGL2/Venus GPU acceleration. Applying CPU or memory changes restarts the engine and restores the containers that were running.

Dory has four availability modes:

Auto-Idle can keep published ports, labeled projects, or Kubernetes awake. Its status and transition history are visible in the UI and CLI.

dory mode auto-idle
dory idle status --json
dory idle history --json
dory engine sleep
dory engine wake

The Health screen runs passive checks by default. Active probes create a small throwaway container to test DNS, ports, mounts, registry access, file watching, memory, and helpers. Results are grouped, repair actions are previewed, and support bundles are redacted.

dory doctor --json
dory readiness --json
dory doctor --json --active
dory doctor --json --diff
dory support bundle --json --active
dory repair all --json
dory repair all --json --apply
dory cleanup --json
dory cleanup --json --apply

dory readiness is the compact runtime truth contract. It shows the ordered app, doryd, VM, guest-agent, data-mount, network, dockerd, host socket/context, and optional Kubernetes stages with reason codes, deadlines, elapsed time, and the exact non-destructive repair owner/mutation.

Passive Health diagnostics also attribute physical memory, FDs, and threads to each Dory process; separate guest used/cache/reclaimable memory; show sparse-disk logical, physical, guest-used, reclaimable, and maximum bytes; expose narrow file-watcher roots and queue pressure; and identify Dory-owned resolver, route, low-port, PF, and UTUN state. Three rising samples produce an early warning. dory cleanup --json names reclaimable objects and never mutates without --apply.

repair all --apply does not restart a healthy data plane. Socket, guest-agent, dockerd, route, and data-drive repairs touch only their named layer; they do not delete images, volumes, machines, or the VM. A disruptive engine restart requires the specific engine target and --restart-engine. Cleanup is a dry run unless --apply is present, and volume pruning also requires --include-volumes.

Dory publishes a versioned local contract instead of asking agents to infer commands from terminal text.

dory agent guide --json
dory mcp serve --read-only
dory wait engine --until running --timeout 60 --json
dory events --follow --json

The stdio MCP server implements protocol version 2025-11-25 and exposes:

• dory.agent_guide
• dory.doctor
• dory.compat
• dory.engine_status
• dory.machine_list
• dory.machine_exec
• dory.sandbox_capabilities
• dory.sandbox_templates
• dory.sandbox_current
• dory.sandbox_use
• dory.sandbox_run
• dory.sandbox_create
• dory.sandbox_exec
• dory.sandbox_reset
• dory.sandbox_inspect
• dory.sandbox_list
• dory.sandbox_kill
• dory.wait
• dory.events

Launch with --read-only to block machine execution and sandbox writes. Agents should inspect first, prefer JSON, run dry-run commands before writes, and use the narrowest repair target.

Agent Sandboxes are dedicated headless VMs for coding agents and Linux CLI applications; they are distinct from interactive Linux Desktop VMs and general-purpose user-managed Linux Server VMs. The supported sandbox command shares no host files by default, runs non-root, defaults mounts to read-only, and enforces none, allowlisted outbound, or explicit full network policy. It also provides bounded scratch disk/process/wall limits, ephemeral secret and SSH-agent grants, rollback, inspectable manifests, a kill switch, named reuse, and daemon-owned TTL cleanup.

dory sandbox run --json --network none --rollback -- /bin/sh -lc 'uname -a'
dory sandbox run --json --mount "$PWD:/workspace" -- /bin/sh -lc 'ls /workspace'
dory sandbox run --json --network outbound --allow-network registry.example.com:443 -- COMMAND

For repeated local development or testing, create an Agent-ready named sandbox once and reuse it:

dory sandbox create my-project --workspace .
dory sandbox capabilities my-project --json
dory sandbox use my-project
dory sandbox attach
dory sandbox exec my-project -- go test ./...
dory sandbox inspect my-project --json
dory sandbox reset my-project --json
dory sandbox kill my-project

The core profile includes Bash, build tools, Git, curl, jq, ripgrep, Python, SSH tools, tmux, and common archive utilities. Reusable dev.dory.sandbox.template v1 JSON files select profiles, toolchains, policies, mounts, and limits; --setup FILE runs once as the non-root Sandbox identity before the reset baseline is captured. Dory detects Node, Python, Go, Rust, Java, and Ruby projects from the workspace, or you can choose a profile or repeat --tool. Tools and caches stay warm between commands. use/current/attach/switch remember a Sandbox and reconnect to its in-VM tmux session so agent processes survive host-terminal disconnects. reset restores the prepared baseline without changing the mounted host workspace. The sandbox root filesystem is sparse, so its 8 GB logical capacity consumes Mac storage only as data is written.

Run dory sandbox --help for every local option. The same create, exec, reset, inspect, list, kill, permission, credential, resource, timeout, and rollback controls are available to local agents through dory mcp serve and are described by dory agent guide --json.

Machine-readable references:

• llms.txt
• llms-full.txt
• agent-guide.json
• docs/agents.md
• docs/operations.md
• docs/compatibility.md

Everything below is available without using the command line:

The menu bar can also start and stop containers and Compose projects, open the app, and show engine, Kubernetes, and machine state.

Linux machines and built-in Kubernetes require the Dory daemon backend. The full Dory engine uses a Hypervisor.framework path on macOS 15 or later and a bundled Virtualization.framework fallback on macOS 14.

• No Dory account or sign-in
• No telemetry
• No required cloud service or remote control plane
• Localhost-only publishing by default
• Explicit macOS authorization before system networking changes
• A removable plan for Dory-owned resolver, certificate, and packet-filter rules
• No host file sharing in agent sandboxes by default
• Non-root sandbox commands, read-only mount defaults, uid-scoped egress filtering, bounded resources, ephemeral credential grants, and daemon-owned expiry
• Named environment-variable allow-list for new machines
• Redacted support bundles
• Signed and notarized release app, signed Sparkle updates, release manifest, and CycloneDX SBOM

SSH-agent forwarding is available at /run/host-services/ssh-auth.sock. Mount it only into trusted containers because any process with access can ask your agent to sign data.

docker run --rm \
  -v /run/host-services/ssh-auth.sock:/agent.sock \
  -e SSH_AUTH_SOCK=/agent.sock \
  your-image ssh-add -L

• Unavailable — Intel hosts: Apple Silicon is the only qualified host architecture. Intel support is planned for a later release after dedicated hardware validation.
• Unavailable — Intel Linux guests: x86_64 installer ISOs do not boot through Dory's ARM64 hardware-virtualization paths. Rosetta/FEX translate applications inside ARM64 guests, not a complete Intel guest OS; a future full implementation requires a packaged QEMU TCG backend.
• Recovery baseline — Desktop Linux: managed Ubuntu 24.04 LTS GNOME plus Debian 13 and Kali rolling Xfce arm64 profiles must boot and launch ordinary applications with software graphics. The exact release remains unqualified until the physical managed-desktop gate passes.
• Supported — Headless Linux: Alpine-based arm64 guests with an initial root /bin/sh login.
• Unqualified for public release — Desktop GPU acceleration: the repaired dual VirGL2/Venus tuple passed a 15-minute physical Developer-ID calibration with sustained VirGL, Venus Vulkan WSI, Zed, Firefox, and ordinary GNOME applications, with no rejected resource flush or device loss. Dory still makes no public acceleration claim until that exact tuple is release-signed, notarized, and passes the complete release matrix; software display remains the recovery path.
• Qualified-only USB passthrough: host discovery and explicit app/CLI attach/detach controls are wired. They enable only for a running raw-HV machine whose exact signed resolved plan authorizes removable USB; current production catalogs do not yet carry that qualification. Remembered replay remains disabled.
• Unavailable — audio passthrough: not part of the current release.
• Supported — agent sandboxes: grants and residual risks are documented in the agent guide.
• Specialized Docker extensions may depend on another product's private paths. Use dory compat and report the exact tool and version when that happens.

See COMPATIBILITY.md for the tested product contract and the architecture guide for the complete supported, preview, and unavailable matrix.

Ordinary uninstall stops Dory services and removes app-owned runtime and shell integration. It does not delete the selected .dorydrive, so reinstalling can reconnect to existing workload data.

brew uninstall --cask Augani/dory/dory

For a direct installation, run dory uninstall before deleting Dory.app. Deleting containers, volumes, machines, snapshots, or the data drive remains a separate explicit action.

git clone https://github.com/Augani/dory.git
cd dory
scripts/build.sh
scripts/test.sh

The source build defaults to Docker Core. DORY_DESKTOP_BUNDLE_MODE=all scripts/build.sh remains a developer-only offline fixture for exercising every graphical image in one local build. Public releases use Docker Core plus the signed component catalog.

scripts/test.sh is the public selector for the Rust workspace, the two Swift packages, app tests, UI tests, gvproxy, and a compile-only app build. Public CLI/repository contracts are composed by scripts/ci-test.sh and GitHub Actions; hardware and duration claims are not part of scripts/test.sh. Release qualification separately adds signed distribution, clean-install, live-engine, network, filesystem, migration, compatibility, performance, endurance, and notarization gates against the exact candidate.

Release operators use one command surface: scripts/dory-release.sh. Its clearly separated check, candidate, status, and publish actions coordinate the private signed candidate and the qualification-gated GitHub, Pages, component-catalog, and Homebrew release. See the release guide; the lower-level release scripts and workflows are implementation details, not separate operator steps.

The public documentation covers architecture, performance evidence, operations, and compatibility.

Before opening an issue, collect the smallest useful evidence:

dory version
dory doctor --active
dory support bundle --json --active

Include the Dory version, macOS version, Mac model, affected command or tool, and the redacted bundle path when appropriate. Open an issue or read CONTRIBUTING.md to help improve Dory.

GPL-3.0 © 2026 Dory contributors.