Decant
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.
Drag and drop is lovely.
Unless you're the one dragging.
Open the DMG, drag the app to Applications, done. It's a great way to install
an app on one Mac with an admin account. On a fleet of locked-down Macs it's a queue of
tickets, or an afternoon repackaging someone else's app as a .pkg.
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, owned by that user. Nobody needs admin rights. Users who'd
rather do it themselves get Decant.app, with exactly the same checks, if you let them.
Secure by default
Because "it was on the vendor's website" isn't a security policy.
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.
Simple to run
No repackaging, no wrapper scripts to babysit, no "can you just make me an admin?"
- Deploy the package. One signed, notarized
.pkginstalls/usr/local/bin/decant, Decant.app and the update daemon. Don't want the app?decant-cli.pkgleaves it out, and updates keep it that way. - Deploy the profile. The sample
.mobileconfigsets secure defaults. Adjust what you need. - 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- Never prompts. The command line has no UI, mounts images hidden and refuses licence dialogs, so nobody gets asked to click Agree.
- Idempotent. Run it every hour if it makes you feel better. If the version hasn't changed, nothing happens.
- Stable exit codes tell your MDM when to retry: no user logged in, app running, or another install in progress.
- Every user, or one.
--all-usersinstalls a separate, separately verified copy for each account. - Apps keep updating. Built-in updaters work without admin rights.
- Decant keeps itself current. It installs its own new releases once they're a week old (you choose, up to 14 days) and the Mac is idle. It checks the package's checksum, signing team and notarization first. Prefer to ship updates through your MDM? Turn it off in the profile.
- Leaves when asked.
sudo decant uninstallremoves the tool, the app, the daemon, the logs and every user's settings.
For users, too
For people who'd rather not raise a ticket to install a PDF reader.
- Drop a DMG on Decant. Or use Open With in Finder.
- 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.
- Install. The button only appears when every check has passed. Decant installs the exact app it checked, even if the DMG changes underneath it.
It runs as the user and reads the same managed profile, so nobody can turn a check off. Menu bar, open at login and update settings can be locked from the profile too.
Rather keep installs to yourself? Set AllowUserInstalls to
false and only your MDM can install. Decant.app tells users it has been disabled
by their administrator and quits. It also leaves the menu bar and stops opening at login.
Your scripts run as root, so they still install for whoever is signed in.
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.