a friendly homebrew-style CLI workflow for the administration of Mac applications distributed as binaries
Pull request Compare This branch is 1 commit ahead, 63856 commits behind caskroom:master.
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.


"To install, drag this icon..." no more!

Let's see if we can get the elegance, simplicity, and speed of Homebrew for the installation and management GUI Mac applications like Google Chrome and Adium.

brew-cask provides a friendly homebrew-style CLI workflow for the administration of Mac applications distributed as binaries.

It's implemented as a homebrew "external command" called cask.

Let's try it!

Get brew-cask

Tap this repository and install the brew-cask tool:

$ brew tap phinze/homebrew-cask
$ brew install brew-cask

Now let's install our first Cask

Let's see if there's a Cask for Chrome:

$ brew cask search chrome

Cool, there it is. Let's install it.

$ brew cask install google-chrome
Success! google-chrome installed to /usr/local/Cellar/google-chrome/stable-channel

Now we have Google Chrome.app in our Cellar. Cool.

If you like, it's easy to get it linked somewhere more visible (see "Alfred Integration" below for an idea that makes this step unnecessary):

$ brew cask linkapps
/Users/phinze/Applications/Google Chrome.app -> /usr/local/Cellar/google-chrome/17.0.963.56/Google Chrome.app

And there we have it. Google Chrome installed with a few quick commands; no clicking, no dragging, no dropping.

open "~/Applications/Google Chrome.app"

What Casks are available?

Just run brew cask search with no arguments to get a list.

How do I update brew-cask?

Since this repository is a Tap, you'll pull down the latest Casks with a simple brew-update. When the brew-cask tool itself is updated, it will show in brew outdated and you can upgrade it via the normal Homebrew workflow.

What is a Cask?

A Cask is like a Formula in Homebrew except it describes how to download and install a binary application.

Casks currently have three fields:

  • url: (required) points to binary distribution of the application
  • version: (required) describes the version of the application available at the URL
  • homepage: the same as Homebrew's - it doesn't do anything yet, but will be wired in

What's the status of this project? Where's it headed?

It's really just a start at this point, but it works, and I've got big plans!

brew-cask currently understands how to install dmg and zip files that contain a .app file. I'd like to extend it to be able to handle pkg files as well as the numerous other permutations of compression and distribution in the wild (.app inside dmg inside zip; folder inside dmg; etc.).

I plan to use the Cask model to allow per-project customization of behavior, like Homebrew does with Formula. This would allow weirdo applications like, say, Eclipse ("you really want me to drag that whole folder to Applications? ew.") to contain their complexity.

Each Cask will then encapsulate and automate the story of how a given application should be installed. If all goes well - I'm hoping to build up a community-maintained collection of Casks that becomes the standard way that hackers install Mac apps.

Can I contribute?

Yes, yes, yes! Please fork/pull request to update Casks, to add features, to clean up documentation--anything at all that you can do to help out is very welcome.

It's also pretty darn easy to create Casks, so please build more of them for the software you use. And if brew-cask doesn't support the packaging format of your software, please open an issue and we can get it working together.

The whole idea is to build a community-maintained list of easily installable packages, so the community part is important! Every little bit counts.


You can add Casks to your existing (or new) taps: just create a directory named Casks inside your tap, put your Casks there, and everything will just work.

Alfred Integration

I've been using Casks along with Alfred to great effect. Just add /usr/local/Cellar as a Search Scope in Alfred's preferences, and then applications become available in Alfred immediately after a brew cask install. Your fingertips will thank you.

With this setup, you don't actually need brew cask linkapps if you always open your apps from Alfred. This means that everything stays nice and tidy.

Oh, and you can brew cask install alfred too! Not bad, eh?

Why use Homebrew's Cellar? Why not just manage apps directly in Applications?

The short answer to this would be: for the same reason that Homebrew does not install applications directly into /usr/local.

We don't know up-front precisely what files are going to be in the dmg/zip/tgz/etc, so it's really helpful to have a place to dump all of them safely then iterate through and act on the files we care about. For a .app file this may be symlinking it into ~/Applications or /Applications, for a .pkg file this might be running the installer. For a screensaver it may be symlinking it into the appropriate directory for it to show up in System Preferences.

The reason I implemented this project on top of Homebrew was because I believe that their methodology for managing applications has a lot of merit. I'd prefer to try and work things so that we can keep ourselves Homebrewy both in implementation and idioms. Trying to manage all of ~/Applications would move the project more towards a standalone system, which would mean reimplementing a lot of the Homebrew stuff we lean on now.