docker/for-mac is an issue tracker, not a Docker Desktop download

What docker/for-mac actually is

This repository is an issue tracker. The README says so directly: it "contains an issue tracker for Docker Desktop for Mac -- an integrated Docker experience on OS X or macOS." There is no source code for Docker Desktop here, no build scripts, and no release artifacts. The top level holds .github/, .nurse/, FAQ.md, README.md and security.md, which is the shape of a bug-report repository rather than a product repository.

That distinction matters because the name invites the opposite assumption. Someone searching for a Docker Desktop download will land on docker/for-mac and find a list of open bugs. The README points elsewhere for the software itself: Docker Desktop for Mac is "free to download" from the Docker store, and documentation lives at docs.docker.com/docker-for-mac/. The audience for this repository is narrow: people who already run Docker Desktop on a Mac and have found a defect they can describe well enough for someone else to reproduce.

The sunset notice and what it means for your report

The README carries a note at the top: "This repository is being sunset in favor of desktop-feedback. Existing issues will remain here but will be moved to the new repository as they are updated." The last push to master was on 2026-03-02, and the repository is not archived, so it is readable and still open, but the stated direction of travel is toward the replacement tracker.

Read that notice as a routing instruction, not as a shutdown date. Nothing in the README says the repository will close or that new issues are rejected. What it does say is where activity is heading. If you are deciding where to spend effort, a new report filed here may sit until someone updates it, at which point it moves. A report filed on desktop-feedback starts where the maintainers say they are going. The practical consequence is that the older tracker is now mostly useful for searching: a bug you hit today may already have a thread here with a workaround, even though the thread will be relocated later.

Filing a bug report that survives triage

The README gives the workflow in one sentence: browse the existing issues, search from the bar at the top (the README notes `s` to focus), and if you do not find your issue, open a new one. The repository has no installable artifact of its own, so the nearest thing to a first use is producing a report. There is no CLI, no package to add, and no configuration file this repository defines.

Before opening anything, search the tracker. The README's own instruction is to search first:

# open the issue list in a browser
git clone https://github.com/docker/for-mac.git
cd for-mac
ls

Cloning gives you README.md, FAQ.md, security.md and the .github/ and .nurse/ directories, which is everything the repository holds. If you clone it expecting Docker Desktop binaries, you will not find them. The FAQ.md file is worth reading before posting, since it exists precisely to absorb questions that would otherwise become issues.

The README states that bugs "can be filed as issues in this repository, which we respond to on a best-effort basis." That phrase sets expectations: no service level, no guaranteed reply. It also states that "support requests in this repository (i.e., trouble installing or using the software) will be ignored." A report that describes what you did, what you expected, and what happened instead is a bug report. A report that asks how to configure something is a support request, and the README says it will be ignored.

Where to go when you need help rather than a fix

This is the limitation that catches most people. Docker Desktop for Mac is commercial software with paid support tiers, and the README routes those users separately: "Support for Docker Desktop is available to Docker customers on a Pro or Team plan by completing the Desktop support form." If you pay for Pro or Team, the tracker is not your support channel, and using it as one wastes a cycle.

For everyone else, the README names two other destinations. The extensive documentation at docs.docker.com/docker-for-mac/ is the first place to look when something is unclear, and community support is available from the Docker community Slack. Neither is a bug tracker. The split is deliberate: defects go to issues, questions go to documentation, Slack, or paid support depending on your plan.

There is also a security.md file at the top level, which is the conventional location for a vulnerability disclosure policy. The README does not describe it, so read the file itself before sending anything sensitive to a public issue thread. Filing a security problem as an ordinary issue is the failure mode this file exists to prevent.

HyperKit, DataKit and VPNKit: the components behind the reports

The README lists three notable open source components that Docker Desktop for Mac uses: HyperKit, "a toolkit for embedding hypervisor capabilities in your application"; DataKit, "a tool to orchestrate applications using a 9P dataflow"; and VPNKit, "a set of tools and services for helping HyperKit VMs interoperate with host VPN configurations." These are separate repositories, not directories inside this one.

Knowing the split helps you guess where a bug belongs, though the README does not give a routing table. A networking symptom that only appears on a corporate VPN points at the VPNKit layer. A problem that looks like the virtual machine itself misbehaving points at HyperKit. A file-sharing or mount problem sits closer to the 9P dataflow that DataKit describes. The README stops short of telling you which component owns which symptom, so treat this as orientation rather than a decision procedure.

The licensing picture is similarly indirect. The README says a full list of components and licenses is available inside Docker Desktop from `About Docker Desktop -> Acknowledgements` in the whale menu. That menu is the authoritative inventory, and it is not reproduced in this repository. If you need to audit what ships in the product, the application itself is the source, not the tracker.

Alternatives: desktop-feedback and the docs site

The real alternative is the one the README names. desktop-feedback is where the project says it is consolidating, and the difference in approach is one of direction rather than format: both are issue trackers, but for-mac is the tracker whose existing issues "will be moved to the new repository as they are updated." Filing on the new tracker means your report starts where the maintainers intend to work. Searching for-mac still has value because the historical record lives here until threads are migrated.

The second alternative is not a tracker at all. docs.docker.com/docker-for-mac/ is documentation, and the README calls it "a great place to look for answers" when something is unclear. If your problem is that you do not understand a behaviour, the documentation is the correct destination and the tracker is not. The Docker community Slack occupies a third position: it is where the README sends people who need community help, which is a different thing from reporting a defect. Choosing among the three is mostly a question of whether you have a reproducible bug, an unanswered question, or a paid support entitlement.

Maintenance status and the cost of following it

The last push to master was on 2026-03-02, and the repository is not archived. The README's own note explains why activity is winding down: the repository is being sunset in favour of desktop-feedback. There are no releases to upgrade, because this repository ships no software, so the upgrade cost is not measured in versions.

The cost is instead the cost of a moving target. A thread you open here may be migrated, and the README says migration happens "as they are updated," which means a quiet issue can stay put for a while. Anyone who bookmarks a for-mac issue as a reference should expect the URL to change eventually. For a team tracking a known defect, that is an argument for watching desktop-feedback rather than relying on a single old thread.

On licensing, the README supports only a limited statement. Docker Desktop for Mac is described as free to download, with paid Pro and Team plans that include support. The open source components carry their own licences, listed in the Acknowledgements screen inside the application. This repository itself does not state a licence, so nothing here should be read as granting rights over Docker Desktop or over the bundled components.

Editorial conclusion

Use docker/for-mac only if you have a reproducible bug in Docker Desktop for Mac and can describe it without asking for help; the README states that support requests in this repository will be ignored, and that existing issues will be moved to desktop-feedback as they are updated. If you need installation help or a Pro or Team plan support case, use the documentation or the Desktop support form instead. Before posting, check FAQ.md and the existing issues, and confirm your report names a Docker Desktop version and a concrete reproduction, because a report without either is likely to be closed rather than moved.

Frequently asked questions

Official sources

1. docker/for-mac on GitHub
2. Issues
3. Project website
4. README