# AutoPkg turns packaging chores into versioned recipe files

> AutoPkg is a macOS automation framework that replaces the manual ritual of downloading, unpacking, reconfiguring and repackaging third-party software for mass deployment with recipe files in plist or YAML. Version 3.0 landed in September 2026 after a release-candidate phase, which is the version to read the upgrade notes for.

**autopkg/autopkg** — Automating packaging and software distribution on macOS.

- Repository: https://github.com/autopkg/autopkg
- Website: http://autopkg.github.io/autopkg
- Stars: 1,486 · Forks: 223
- Language: Python
- License: Apache-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/autopkg-autopkg

## The list of chores it removes

The README describes AutoPkg as an automation framework for macOS software packaging and distribution, oriented towards the tasks you would otherwise perform by hand to prepare third-party software for mass deployment.

The list of those tasks is the most useful part of the documentation, because it defines the scope precisely. You download an application or its updates, usually through a browser. You extract them from a range of archive formats. You add site-specific configuration and sane versioning information. You fix poorly written installer scripts. You write the result back to a compressed disk image or installer package. You import that into a distribution system such as Munki, Jamf Pro or FileWave. You then customise the associated metadata with site data, post-installation scripts and version information.

The problem the framework names is repetition, not difficulty. These steps follow similar patterns per application, and at scale the job becomes a daily set of sub-tasks you must remember, and document, for every application and every update. That documentation requirement is the real cost, and it is the thing a shared recipe file actually removes.

The mechanism is a Recipe file in plist or YAML format. You define the steps once, AutoPkg runs them automatically instead of by hand, and the definition can be shared with others.

## Recipes are the product, and AutoPkg does not supply them

It is worth being explicit about a point the README implies rather than states: the recipes are the substance, and they come from elsewhere.

The framework defines the format and the process, and it delegates recipes to recipe repositories. That delegation is why the README calls for Git to be installed, calling it highly recommended so that autopkg can use git to manage recipe repositories, while adding that knowledge of Git itself is not required. Version control is therefore not a convenience here, it is part of how recipes are fetched and updated.

The consequence for an adopter is that evaluating AutoPkg means evaluating a recipe ecosystem, not this repository. If the application you manage most has no maintained recipe, or has one that has not been updated for a vendor change, you are writing that recipe yourself.

The site below `Code/` and `Scripts/` in the repository layout is where the framework implementation and command line tooling live, and the project also ships a `CHANGELOG.md`, `CONTRIBUTING.md` and a `LICENSE.txt` at the root.

Documentation is not in the repository. The README points to a wiki for a getting started guide, a FAQ and further documentation, and to a Google group for discussion of use and development. That is a real consideration for a tool you are considering depending on: the reference material lives outside the code you can read offline.

## Installation, Python, and what the packaging implies

Installation is the release artefact. The README points to the latest release page rather than giving a package manager command, so you download and install the macOS package directly.

Two environment facts follow from that. AutoPkg requires macOS. And since AutoPkg 2.0, Python 2 is no longer supported; the installer contains a bundled version of Python 3 along with its dependencies. That last point removes the most common failure mode for this class of tool, where a system Python upgrade silently breaks an admin tool.

The source side is a conventional Python project. There is a `requirements.in` and a matching `requirements.txt`, and the header of the pinned file records how it was produced:

```bash
uv pip compile requirements.in --universal --python-version 3.11 --output-file requirements.txt
```

Compiling for Python 3.11 with the universal flag is how the project pins one dependency set across interpreters, and it explains the platform markers inside the file. `requests`, `certifi` and `urllib3` cover network access; `lxml` and `pycparser` cover XML and plist parsing; `pyobjc-core` with the Cocoa, CoreServices and Foundation frameworks is the macOS bridge; `xattr` handles extended attributes, which matters because macOS quarantine flags live there and a repackaged app that keeps the original quarantine state will not behave as intended.

Dev tooling is pinned in the same file: `black`, `isort`, `flake8` with `flake8-bugbear`, `pre-commit` with `identify` and `nodeenv`, and `virtualenv` and `distlib` beneath it. The root has `.pre-commit-config.yaml`, `.flake8`, `.isort.cfg`, `.coveragerc` and `.markdownlint.yaml`, so formatting, linting, coverage and markdown are all enforced through git hooks.

Testing is enforced too: the README carries a passing-tests badge wired to a GitHub Actions workflow.

One macOS-specific caveat is stated directly. AutoPkg is tested on the current macOS release, and it may work on older releases but is not actively tested on them.

## What it is not

The most common misunderstanding is that AutoPkg is a deployment tool. It is not, and the README's own list shows why.

AutoPkg produces the artefact and hands it to a distribution system. Munki, Jamf Pro and FileWave are named as the systems that import what AutoPkg builds, which means the catalogue, the client inventory, the policy that triggers installation and the reporting all stay in those tools. If you have no macOS management system in place, AutoPkg has nowhere to import into.

It is also not an application catalogue. It does not decide what your fleet should have. A recipe exists for one application, and someone has to decide to run it.

Nor is it a general scripting environment. The abstraction is a recipe with well-defined process types, and writing arbitrary logic outside that model means writing a processor, which is development work against the framework's extension points.

There is a fourth boundary: AutoPkg does not fix a vendor's installer. It can work around a badly written script by rewriting it before repackaging, which the README lists as a task it performs, but it cannot make a broken vendor package work correctly when the underlying application misbehaves.

Finally, the platform limit is absolute. Everything here is macOS-specific, from pyobjc to the disk image formats, so a cross-platform macOS and Windows fleet gets no benefit from the Windows side.

## Version 3.0 and the release process behind it

The release history is the most informative thing about the project's current state.

Version 3.0.0 shipped on 2026-09-29. Before it came v3.0.0RC5 on 2026-09-21 and v3.0.0RC4 on 2026-06-08. That is a long release candidate cycle with a gap of more than three months between two of them, which suggests a major version where compatibility mattered enough to keep iterating rather than shipping once.

Practical guidance follows from that pattern. Read the `CHANGELOG.md` before upgrading, because a major version with a release-candidate phase is where behaviour changes hide, and expect to test against your recipe set rather than assuming existing recipes are unaffected. Recipes are external to this repository, so the blast radius of a framework upgrade depends on other people's files.

Licensing is Apache-2.0 in `LICENSE.txt`, which permits internal modification and redistribution inside an organisation and carries the usual patent grant, so building internal processors is unproblematic from a licence standpoint.

Maintenance: the repository is not archived and the last push was on 2026-10-12, four days before today, which places the work immediately after the 3.0 release. The topic list includes `hacktoberfest` and `macadmin`, and the wiki and Google group are the documented community channels, so the project is active and Mac admin community driven rather than a product with a support contract.

## Conclusion

AutoPkg is for a macOS administrator already deploying dozens of third-party applications to managed clients, where the same unpacking and repackaging ritual is repeated on every vendor update and has become a documentation burden. Do not adopt it as a general deployment tool, since it packages and imports into Munki, Jamf Pro or FileWave rather than replacing them, and do not adopt it on Windows or Linux because it requires macOS. Verify first which recipe repository you will point at, because the recipes are shared third-party definitions and AutoPkg itself ships none of the application-specific ones.

## FAQ

### What is AutoPkg used for?

AutoPkg automates the manual steps of preparing third-party macOS software for mass deployment: downloading it, extracting archives, adding site configuration and version information, fixing installer scripts, repackaging as a disk image or installer, and importing into a system such as Munki, Jamf Pro or FileWave.

### How do I install AutoPkg?

From the latest release page linked in the README, using the macOS installer. That installer bundles Python 3 and the required dependencies, so no separate Python setup is needed. The README notes that Python 2 has not been supported since AutoPkg 2.0.

### Do I need Git to use AutoPkg?

The README calls Git highly recommended, because autopkg uses git to manage recipe repositories. It also notes that knowledge of Git itself is not required. Git can be installed through Apple's command line developer tools.

### Does AutoPkg work on Windows or Linux?

No. The README states AutoPkg requires macOS, and it is tested on the current macOS release only. Older releases may work but are not actively tested.

### What is a recipe in AutoPkg?

A recipe is a file in plist or YAML format that defines the steps needed to package one application, so AutoPkg can run them automatically and share them with others instead of an administrator repeating them by hand.

### What license is AutoPkg released under?

Apache-2.0, with the licence text in LICENSE.txt at the repository root. The project also maintains a CHANGELOG.md, and version 3.0.0 was released on 2026-09-29 after several release candidates.

## Sources

- [autopkg/autopkg on GitHub](https://github.com/autopkg/autopkg)
- [License: Apache-2.0](https://github.com/autopkg/autopkg/blob/master/LICENSE)
- [Project website](http://autopkg.github.io/autopkg)
- [README](https://github.com/autopkg/autopkg/blob/master/README.md)
- [Releases](https://github.com/autopkg/autopkg/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/autopkg-autopkg