macOS Software management with Munki

Munki is a powerful open-source tool for managing software across macOS systems.

Instead of waiting for users to click "Update," automations handle the installs for you. Once a Mac is pointed at your managed software catalog, pre-configured client Macs can pull apps, updates, or even uninstall applications with zero drama on the client side.

By the end of this page, you'll understand exactly how Munki clients are managed using nothing but plain .plist files sitting on an ordinary web server, why that deliberately boring design is secretly brilliant, and the one critical permission question that determines whether it's also truly safe.

Here is the answer first, no warm-up. Munki is an open-source macOS software management system whose entire control plane is a directory of Apple property-list (plist) text files, served as static files by a plain web server. No application server. No database. No magic. Just files.

Why use Munki?

Munki is a macOS software management toolset solution for a small business's with a need to manage and control installations, updates, and remove software on managed Macs using a simple web-server-based repository of packages. Munki is licensed under the permissive Apache License 2.0, so you can read every line, fork it, and run it without asking anyone's permission. You can browse the project on GitHub or at its home, munki.org.

For example, a small business with 20–50 Macs can use Munki to keep security tools, browsers, and productivity apps updated across all machines. Instead of manually updating each one or paying for an expensive MDM solution, they set up Munki once. Required apps install automatically, optional tools appear in a self-service catalog for users, and everything stays current with minimal ongoing effort.

The origin story is the first surprise. Munki was lead-developed by Greg Neagle, a Staff Systems Engineer at Walt Disney Animation Studios, and released as open source by the studio itself. The same place that renders animated hair frame by frame quietly built one of the most widely used Mac management frameworks on the planet and then gave it away. Not bad for a side effect of keeping the animators' workstations stocked.

What Is a plist File?

A plist, short for property list, is Apple's native format for structured data. It comes in a human-readable XML flavor, a compact binary flavor, and an older legacy ASCII form. macOS and iOS lean on plists everywhere, from app preferences stored through NSUserDefaults to the Info.plist baked into every app bundle. If you have ever poked around a Mac's guts, you have met one.

Apple's own documentation describes the format in plain terms.

"Property lists organize data into named values and lists of values using several object types. These types give you the means to produce data that is meaningfully structured, transportable, storable, and accessible, but still as efficient as possible."

Apple Developer Documentation, Property List Programming Guide

The key word for our purposes is storable. A plist is a file you can open in a text editor, read with your own eyes, diff against yesterday's version, and check into Git. Hold that thought, because it is the whole reason Munki works the way it does.

How Munki Actually Works: pkginfo, Catalogs, and Manifests

Munki's repository runs on three kinds of plist files, and once you know what each one does, the whole system clicks into place. They build on each other like a recipe: ingredients, pantry, then the order ticket for each table.

The Munki documentation is blunt about the format, which saves us a lot of guessing.

"Manifests and catalogs are stored on the web server as standard Apple plist files in text format. pkginfo files are also plist-formatted files."

Munki documentation, project wiki

Here is what each file does:

• pkginfo is one plist per installer item. It holds the metadata Munki needs to handle a piece of software: its name, version, what it requires, how to detect whether it is already installed, and what to do on update or removal. Think of it as the label on the can.
• Catalogs are plists built from all those pkginfo files by a tool called makecatalogs. A catalog is the searchable index of everything available in the repo. Think of it as the pantry inventory, assembled from every label.
• Manifests are plists that say what a given machine, or group of machines, should have installed and what should be removed. Think of it as the order ticket pinned above the stove for each table.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>SoftwareRepoURL</key>
    <string>https://your-munki-server/repo</string>
    <key>ClientIdentifier</key>
    <string>your-manifest-name</string>
    <key>InstallAppleSoftwareUpdates</key>
    <true/>
    <key>ShowOptionalInstalls</key>
    <true/>
    <key>AggressiveUpdateNotificationDays</key>
    <integer>14</integer>
    <!-- Other common keys -->
    <key>ManagedInstallsDir</key>
    <string>/Library/Managed Installs</string>
    <key>PackageVerificationMode</key>
    <string>hash</string>
</dict>
</plist>

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>catalogs</key>
    <array>
        <string>production</string>
    </array>
    <key>display_name</key>
    <string>Firefox</string>
    <key>installer_type</key>
    <string>pkg</string>
    <key>item_name</key>
    <string>Firefox</string>
    <key>name</key>
    <string>Firefox</string>
    <key>minimum_os_version</key>
    <string>10.15</string>
    <key>version</key>
    <string>latest</string>  <!-- or specific version -->
    <key>uninstallable</key>
    <true/>
</dict>
</plist>

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>catalogs</key>
    <array>
        <string>production</string>
    </array>
    <key>managed_installs</key>
    <array>
        <string>Firefox</string>
        <string>GoogleChrome</string>
        <string>Office365</string>
    </array>
    <key>managed_uninstalls</key>
    <array>
        <string>SomeOldApp</string>
    </array>
    <key>optional_installs</key>
    <array>
        <string>Slack</string>
        <string>Zoom</string>
    </array>
</dict>
</plist>

The client on each Mac does the rest. It downloads the catalogs, reads the detail on individual manifest items, then builds a list of things to install and a list of things to remove. No server-side brain decides anything. The server just hands over files. The decision-making lives entirely in the client reading plain text.

Just a Web Server: Why the Repo Is Boring on Purpose

Now for the simplicity of the webserver that hosts the software repo for Munki. The Munki server, serves files. It does not run Munki. It does not need a database. It does not need PHP, Python, or a single line of server-side code. It hands out files and that is the entire job description.

The project documentation puts it about as plainly as it can be put.

"A basic Munki server is simply a web server. You do not need the Munki tools installed on the server. You are simply setting up a filesystem on a web server for clients to access."

Munki documentation, project wiki

This is the surprise that reframes everything. Most management platforms are sprawling applications with their own runtime, their own database, their own attack surface, and their own 2 a.m. outages. Munki's server is a directory tree of static files behind Apache, Nginx, or a cloud bucket. You can host the whole repo in the cloud and never touch a server process. The "platform" is a filing cabinet, and the intelligence rides on the client. Boring is a feature here, not a bug. Fewer moving parts means fewer things that can break, fewer services to patch, and a system you can actually reason about end to end.

Munki Is Not an MDM (and Why That Matters)

Here is the most common mix-up, so let us fence it off cleanly. Munki is not an MDM. It is configuration and software deployment management, categorized alongside configuration management, not Mobile Device Management. An MDM enrolls devices, pushes policy and profiles, and can wipe or lock a Mac through Apple's management protocol. Munki does none of that. It is laser-focused on one job: getting the right software onto the right machines and keeping it there.

In the real world, the two are partners, not rivals. Munki is commonly integrated into deployment workflows alongside an MDM. The MDM handles enrollment, identity, and policy. Munki handles the rich software catalog that MDMs are clumsy at. You let each tool do the thing it is genuinely good at.

The Security Flip Side: Who Can Write to Your plists?

Everything that makes Munki elegant also draws the security boundary in bright ink. If source catalog instructions are editable text files served off a web server, then the question that matters is not "is the format secure?" It is who can write to those files?

Walk the threat through. A manifest is a plist that tells a Mac what to install. An attacker who can edit a manifest, or drop a malicious pkginfo and rebuild the catalog, can instruct Macs within your SMB to install whatever they like, with the client's privileges, on every machine that reads that repo. The plain-text design that makes Munki so auditable for you makes it equally legible to anyone who gets write access. The pen is mightier than the page.

So the hardening checklist writes itself, and it is refreshingly concrete:

• Serve over HTTPS, always. Plain HTTP means the non-encrypted instructions travel in the clear and can be tampered with in transit. TLS is non-negotiable.
• Lock down write access to the repo. Reading the repo is harmless. Writing to it is total control. Keep the set of people and systems that can write to those plists as small as you can stand.
• Authenticate the clients. Munki supports requiring credentials to fetch the repo, so it is not an open buffet for anyone who finds the URL.
• Version-control everything. If a manifest changes, you want a commit that names who did it and when, not a mystery timestamp on a file.
• Harden the web server itself. The repo is only as safe as the host serving it. Patch it, monitor it, and treat it like the sensitive infrastructure it quietly is.

None of this is exotic. It is the same web-server discipline our team preaches across every project, and you can read more of that playbook in our cybersecurity coverage and our secure web solutions guidance. The reassuring part is that securing Munki is not a mysterious art. It is web-server hygiene you may already know.

Frequently Asked Questions

It's Just Files All the Way Down

The genius of Munki is that it refuses to be clever. While the rest of the industry built sprawling platforms with databases and daemons, a systems engineer at an animation studio decided a whole shop could be run from a folder of text files on a web server, and was right. That plainness is what makes Munki so inspectable, so version-friendly, and so pleasantly hard to break. It is also what hands you the one job you cannot skip: decide exactly who is allowed to write to those files, then guard that list like it controls every Mac you own, because it does. Ready to harden the web server underneath it all? Bring us your repo and your worries, and let our cybersecurity team help you keep the elegant thing elegant.