Catalogs, Manifests, Packages: Anatomy of Munki

Tom edited this page Dec 22, 2017 · 4 revisions

Munki consists of four major object types that you're going to need to be familiar with. Each of them have clear roles and structures, and it's really important to understand how they all fit together and how to build them.


Much like a shipping manifest, Munki's Manifests are a list of items that must be checked off during a run of the Managed Software Center tools. Manifests are structured XML files that conform to the Apple PLIST DTD. They contain a number of key arrays designed to denote specific procedures.


Manifests require Catalogs to properly reference packages. Think of Catalogs like a retail store, and think of Manifests like a shopping list. All the items on a manifest need to be present in the Catalog for a successful run. This would also allow you to have different versions of a software package for a production catalog than for testing catalogs.

Managed Installs

This is the shopping list of packages from the repository that Munki will install on a machine that references this manifest.

Managed Uninstalls

This is the shopping list of packages from the repository that Munki will uninstall on a machine that references this manifest.

Included Manifests

A manifest may include another manifest's name for reference. This would allow you to have multiple manifests for a given machine. For example, you might have a master apps manifest, a creative apps manifest, and a windows vm manifest that installs three separate sets of packages. Your machine's manifest could reference them all for simplicity's sake, and for the sake of only having to update a few manifests, rather than every manifest, when changes and updates are made.

Managed Updates

If you have update packages for installed packages on a machine, they can go in the Managed Updates section.

Optional Installs

If you have software that Users may install themselves, but aren't required to have, they can go here, and then they are available from within Managed Software Center for optional download and install.


Think of Catalogs like retail stores. The items on their shelves are the items in the store's Catalog. Catalogs are generated by /usr/local/munki/munkiimport while importing packages, or by invoking /usr/local/munki/makecatalogs.

You should not edit the catalogs manually. Let /usr/local/munki/makecatalogs do it for you.

You may have as many catalogs as you like with Munki, but as many as you have, you have to manage them all. Many shops tend to default to testing, production and development.


Packages are what Munki installs. They consist of a pair of logical items in munki: the package itself, and the pkginfo file that determines some of the niceties of install. You have a pair of directories in your repository, one for the .pkg file (called pkgs) and one for the structured XML file that conforms to Apple's PLIST DTD (called pkgsinfo). The Packages are large binary objects - for the purposes of this document, they're black boxes, you don't care about them - and the Package Info files contain everything else you need to know.

Much like the Manifests, the Package Info files contain key arrays that determine how and if the Packages are installed. A full list of supported pkginfo keys is available, but this section will give you some of the highlights.

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.