Decant

App installs for managed Macs

Drag and drop is lovely.
Unless you're the one dragging.

On a fleet of locked-down Macs, "drag it to Applications" is a queue of tickets, or an afternoon repackaging someone else's app. Decant does the dragging: hand it the vendor's disk image from your MDM and it checks the app, then installs it into the signed-in user's ~/Applications. Nobody needs admin rights.

Download the latest release Read the admin guide

macOS 26+ · Apple silicon · Intune, Jamf, Kandji and other MDMs · Open source

Decant.app showing an app whose signature and notarization checks have passed, with an Install button

Installs the vendor's DMG

The disk image goes in unchanged. No repackaging, no wrapper scripts.

No admin rights needed

Each app lands in the user's ~/Applications, owned by them.

Refuses what it can't verify

Developer ID, notarized, one app and nothing else. Or nothing.

Security

Secure by default

Because "it was on the vendor's website" isn't a security policy.

Verifies before it installs

Strict code signature, Developer ID and notarization through Gatekeeper, and an optional pinned Team ID and bundle ID. Ad-hoc and unsigned apps are refused.

Notarized means notarized

If Gatekeeper is switched off, or a local rule waved the app through, nothing proves notarization, so Decant refuses. A Team ID only counts if Apple issued the certificate.

Verifies what it installs

All checks run on a root-owned staged copy, which is then swapped in atomically. Symlink tricks and races in the user's folder can't redirect root's writes.

Only simple images

Exactly one app and nothing else that runs. A .pkg in disguise, an "Install Foo.app", a helpful script: all refused, with nothing changed.

No silent rollbacks

Downgrades are refused. Editing the version number in Info.plist won't keep an old, vulnerable copy around, however creative the user is.

Locked configuration

Settings come from a managed profile that users can't change. Root-owned, non-writable files only.

Deploy

Simple to run

No repackaging, no wrapper scripts to babysit, no "can you just make me an admin?"

  1. Deploy the package

    One signed, notarized .pkg installs /usr/local/bin/decant, Decant.app and the update daemon. Don't want the app? decant-cli.pkg leaves it out, and updates keep it that way.

  2. Deploy the profile

    The sample .mobileconfig sets secure defaults. Adjust what you need.

  3. Add a script per app

    Point it at the vendor's download URL and Team ID. The DMG goes in unchanged.

$ decant install Example.dmg --expect-team-id ABCDE12345
RESULT updated exit=0: Updated Example.app from 1.2 to 1.3 at /Users/alex/Applications/Example.app
$ decant install Example.dmg --expect-team-id ABCDE12345
RESULT unchanged exit=0: Example.app 1.3 is already installed

The app

For users, too

For people who'd rather not raise a ticket to install a PDF reader.

  1. Drop a DMG on Decant

    Or use Open With in Finder.

  2. See what's inside

    Every check runs first. The app's name, version, Team ID and destination are shown. If anything fails, it says why and changes nothing.

  3. Install

    The button only appears when every check has passed. Decant installs the exact app it checked, even if the DMG changes underneath it.

Decant.app window asking the user to drop a disk image or choose one

Know the limits

It installs drag-and-drop apps. It isn't magic. Apps installed into ~/Applications are writable by the user. Apps with system extensions, privileged helpers or a fixed /Applications path should still be deployed as packages. The README covers the trade-offs in full.

Let Decant do the dragging.

Free and open source under the Apache License 2.0.

Download the latest release Read the admin guide