With the powerful, open-source tool Munki, systems administrators can manage software, settings, and configurations. Boasting a strong user support community, Munki can be installed, configured, and run on macOS Mojave to manage all of the Apple computers in the enterprise–no matter how large or small. After all, Munki was developed by Walt Disney Animation Studios to aide in the management of the thousands of Macs they use daily when working on everything from animated shorts to feature films.

Best of all, Munki only relies on Apple’s native software packages, read and write permissions for shared deployment directories, and a web server to deliver the packages to client computers.

SEE: System update policy template download (Tech Pro Research)

In this article, I’ll outline the steps necessary to set up Munki on macOS Mojave.

Before we jump in, there are a few requirements necessary to ensure that Munki can run properly. Munki 3 supports all versions of macOS. However, due to Apple removing the web server component from its latest version of macOS Server, the set-up process for Munki running natively on macOS Mojave is slightly different from prior versions in set up (Specifically running locally on the client versions of macOS–deprecating the need for a macOS Server.). Regardless of the underlying version of macOS, Munki will manage all versions of macOS and OS X client much the same.

The requirements are:

  • Apple computer running macOS Mojave 10.14 or later
  • Munki 3 package (latest v3.5.3, as of this writing)
  • Google Chrome.dmg installer package
  • Internet Access
  • Switched Network
  • Admin credentials

Creating the Munki repository

Launch Terminal and enter the following commands to create the directories on the root location that will be used to create the directory structure for the Munki repository. When naming the repository, the word “repo” was used in the example, but it can be named to anything you wish (Figure A).

cd /Server/SharedFolder

mkdir repo

mkdir repo/catalogs

mkdir repo/pkgs

mkdir repo/pkgsinfo

mkdir repo/manifests

The final command below, when run, will change the permissions to assure that it’s accessible.

chmod -R a+rX repo

Configure Apache2 web server

Next, enter the following command to configure the native Apache2 component to serve the newly created repo via HTTP:

sudo ln -s /Server/SharedFolder/repo /Library/WebServer/Documents/

By default, the Apache2 component serves files hosted in its DocumentRoot, which can be located at the directory path: /Library/WebServer/Documents/. The command above creates a symbolic link to the repo in that directory, so those files will be delivered over the network.

To start the Apache2 server, execute the command below in Terminal:

sudo apachectl start

By contrast, to stop the service, replace “start” with “stop” if the service requires it be stopped or restarted.

Installing Munki tools

Execute the Munki Tools package and follow the prompts to complete the install (Figure B).

By clicking on the Customize button, the individual tools that make up the package may be selected (or deselected) for installation. For the admin workstation set up, installing all the tools has its advantages. Click the Install button to complete the installation (Figure C).

A reboot will be required once Munki Tools is installed (Figure D).

Configuring the Munki repository

After rebooting, launch Terminal and enter the following command to change directories and configure the Munki repository’s settings (Figure E).

cd /usr/local/munki

munkiimport –configure

The command will ask a series of questions in order to set the correct configuration. First up is to enter the Repo URL. Depending on how the repo will be hosted, the entry could change from either a locally hosted (ex. file:///path/to/repo), a shared drive (ex. smb://path/to/repo), or web hosted (ex. http://domain.com/path/to/repo). For the purpose of this article, we’ll go with our file-hosted set up and enter the following:


The second question is the pkginfo file’s extension. These files contain configuration information for each package that is imported. While typically not edited, it could be, and you may find some packages do require some light editing to make them deploy silently. The most common extension is .plist, so we’ll enter that here.

Third, we are prompted to choose a default app to edit the configuration files. You can enter the path or name of any installed application you prefer. To keep things simple, I’ve chosen the built-in TextEdit.app native to macOS.

Next, we must create a catalog to store the package information for Munki. The catalogs will be read by Munki and used to provide context as to what applications are available for deployment. You can enter any name you choose, and more than one catalog may exist. Here I’ve entered Default as the catalog name.

Last, a repo access plugin must be selected. Unless there is a preference, FileRepo is the default choice. You may leave the entry blank, and the system will automatically default to that plugin’s configuration. The repository is now configured

Importing the initial package

While we’re almost done with the Munki set up, we must have at least one package in the catalog before completing the process. To add the initial package, we’ll use Google Chrome as an example. From Terminal, enter the following command to get the process started (Figure F).

munkiimport /path/to/googlechrome.dmg

2.Again, Munki will prompt for a series of information regarding the package being imported, such as Item Name, Display name, Description, etc. Some of this information will auto-populate, some will not. That which doesn’t should be added manually. By observing Figure F above, most of the information is basic and does not impact Munki too much except for the Catalogs section. Here you must enter the name of the catalog created in section IV above or else the package will not be linked to Munki for distribution.

Additionally, you will be asked whether to import the item or not. Select Y to import it, as well as creating product icons and rebuilding the catalog. This will update the catalog with the newly imported package. You may; however, select N to skip the editing of the pkginfo file as Google Chrome does not require any additional syntax to deploy it.

Note: Typically, drag-and-drop-style installs do not require editing of the .plist configuration file. Installer-based PKG files may require additional syntax or switches to be passed along to complete the install process. In those cases, you will need to edit the pkginfo file to manually add those parameters.

Configuring the repo’s manifest

The manifest file in Munki acts as a sort of map that tells the repo where catalogs are located and therefore what is in those catalogs, allowing Munki to manage software deployments with ease. By default, no manifest exists so one must be created. In Terminal, enter the following command to begin (Figure G).


Begin by creating the new manifest and giving it a name with this command:

new-manifest site_default

Next, link the catalog created in section IV to the newly created manifest:

add-catalog Default –manifest site_default

The L\last step is to add the package created in section V to the manifest:

add-pkg Chrome –manifest site_default

Munki is officially installed, set up, and ready for use. To test web connectivity, launch a browser and enter http://localhost/repo/manifests/site_default. You should receive a confirmation of the entries add to the manifest in section VI above (Figure H).

Alternatively, by entering the following command in Terminal to verify the software repo URL is configured correctly (Figure I).

defaults read /Library/Preferences/ManagedInstalls

Lastly, to test how Munki works at retrieving the packages and installing them, call the command from Terminal (Figure J).

sudo managedsoftwareupdate

The above command will read the information stored in the catalogs and identify what applications are available and ready to be installed when compared against the inventory on the local machine. To install these apps, rerun the same command, but add the “–installonly” suffix to actually perform the install (Figure K).