Chromebrew: a package manager for ChromeOS in developer mode

What Chromebrew adds to a developer-mode Chromebook

ChromeOS ships a Linux kernel, but the userland is not a general-purpose distribution. The project's own framing is that the missing pieces for using a Chromebook as a full-featured Linux distro were gcc and make with their dependencies. Chromebrew supplies those pieces and a package manager around them, exposed as a single crew command.

The intended user is not someone who wants a Linux desktop on a Chromebook. It is someone who already runs ChromeOS in developer mode and wants compilers, interpreters and CLI utilities inside that environment rather than in a separate container or a replaced firmware. The README is explicit about the prerequisite: a Chromebook with developer mode enabled, configured by following the instructions for your specific device on the ChromiumOS Wiki. It also warns that developer mode is insecure if not properly configured, and suggests setting a password at the VT-2 login screen plus enabling signed boot with chromeos-setdevpasswd and crossystem dev_boot_signed_only=1.

That framing matters. Chromebrew is an addition to ChromeOS, not a replacement for it, and every constraint below follows from that.

How crew resolves, downloads and installs packages

The package definitions live in the packages directory of the repository, and the top level also carries commands/, lib/, manifest/, tools/, bin/ and install.sh. The command surface is wide for a project of this scope: build, check, const, deps, diskstat, download, files, help, install, list, postinstall, prop, reinstall, remove, search, sysinfo, update_package_file, update, upgrade, upload, upstream, version, whatdepends and whatprovides.

Several of those reveal the data flow. download fetches a package into CREW_BREW_DIR, which defaults to /usr/local/tmp/crew, without installing it. install resolves dependencies and prompts for confirmation before writing. files lists the installed files of a package, and whatprovides does a regex search for packages containing a given file, which is how you find out which package owns a binary. whatdepends walks the graph in the other direction. upstream checks whether a newer upstream version exists, and build compiles from source and stores the archive and checksum in the current working directory.

One behaviour is easy to miss: the README states that Chromebrew wipes its BREW_DIR, /usr/local/tmp/crew by default, after installation unless you pass -k or --keep to crew install. If you are inspecting a downloaded archive after the fact, that directory will not be there.

Installing Chromebrew from a VT-2 shell

The installer does not run in crosh on ChromeOS M117 and later. The README attributes this to security changes introduced in that release, so the supported path is a VT-2 terminal session, opened with Ctrl+Alt+Right arrow and logged in as the chronos user. If you cannot reach that session, the README points back at the prerequisites: the device is probably not in developer mode.

Once you are in VT-2, the documented one-liner downloads and runs the install script, then reloads your shell configuration:

bash <(curl -L git.io/vddgY) && . ~/.bashrc

After that, crew should be on your PATH. The general invocation form is a command followed by one or more packages:

crew <command> <package1> [<package2> ...]

A first real use is to search for what you want and then install it, keeping the downloaded archive if you plan to inspect it:

crew search gcc
crew install --keep gcc

The README documents --keep as the flag that stops crew from wiping /usr/local/tmp/crew after installation. To see what a package actually put on disk, use crew files, and to find which package owns a file, use crew whatprovides. The README does not document a rollback command; remove and reinstall are the documented ways to change an installation.

Channel support, architecture limits and the 2017 release history

The most consequential constraint is the channel. The README states in bold terms that the beta, dev and Canary channels are not supported and should not be used with Chromebrew, and that ignoring this will cause major issues with the installation. It points to issue #2890 and the project FAQ for detail. That is not a soft recommendation. If your device is enrolled in a non-stable channel, Chromebrew is the wrong tool for you until you move back to stable.

Architecture support is uneven by design. x86_64 is listed as supported, i686 as limited because Google discontinued support, with GUI apps no longer supported and CLI programs still attempted. armv7l is supported. aarch64 is marked supported with a footnote: the project currently provides only armv7l packages even when the Chromebook has an aarch64 userspace, with issue #8044 given as the reference. On an aarch64 device you should expect armv7l binaries rather than native ones.

Maintenance status is a separate question from the README text. The repository is not archived, but the last push was on 2017-01-13, and the most recent release listed is 0.4.1 on that same date, after v0.4 on 2017-01-12 and v0.3.1 on 2015-06-08. The README text refers to copyright through 2025 and to ChromeOS M117, which is later than the release history, so the README and the releases do not tell the same story about activity. Judge the project by the release dates, not by the currency of the documentation.

Where Chromebrew is the wrong choice

Chromebrew assumes developer mode, and developer mode is a security trade-off the README itself flags as insecure if not properly configured. On a managed or shared Chromebook, or one where you rely on verified boot without the signed-boot setting, that trade-off is probably not worth a compiler. Chromebrew is also not a way to get GUI applications on i686, since the README states GUI apps are no longer supported there.

It is also not the right tool if you want a supported, vendor-blessed Linux environment. ChromeOS already offers a Linux container on many devices, and the README's own framing positions Chromebrew as filling the gap left by gcc and make, not as a general desktop environment. If your goal is running graphical Linux applications, a container is the more direct route and does not require developer mode. If your goal is a CLI toolchain inside the ChromeOS userland, Chromebrew is aimed exactly at that, with the caveat that the release history is old.

One more boundary: the installer no longer works in crosh on ChromeOS M117 and later. Anyone following older instructions found elsewhere will hit that wall, and the README's redirect to VT-2 is the only documented workaround.

Chromebrew compared with a ChromeOS Linux container

The practical alternative for most Chromebook users is the Linux container that ChromeOS provides. The difference in approach is architectural. A container runs a separate Linux userspace with its own package manager, its own filesystem, and its own kernel interface, isolated from ChromeOS. Chromebrew installs into the ChromeOS userland itself, under /usr/local, which is why it needs developer mode and why it is exposed to ChromeOS changes such as the M117 crosh restriction.

The container route gives you a distribution's full package set and graphical application support, and it does not depend on developer mode. Chromebrew gives you a smaller package tree defined in the repository's packages directory, but it puts the tools next to the system rather than beside it, and its crew commands such as whatprovides, whatdepends and diskstat are built around that placement. If you need a specific CLI binary and want it in the same filesystem as the rest of ChromeOS, that is the case Chromebrew serves. If you need a full distribution, the container is the shorter path.

Neither is a substitute for the other, and the README does not claim otherwise.

Licence and the cost of keeping a Chromebrew install current

Chromebrew is released under the GNU General Public License, version 3 or later, with copyright attributed to Michal Siwek and contributors from 2013 to 2025. One file is an exception: the project embeds docopt.rb at lib/docopt.rb and retains its MIT license in lib/docopt.LICENSE. If you redistribute Chromebrew or a modified version, those two licence texts apply to different parts of the tree. This is a description of what the repository states, not legal advice; check the licence files yourself before redistributing.

Upgrade cost is where the age of the release history bites. crew update updates crew itself, and crew upgrade updates all or specific packages, with crew upstream to check whether a newer upstream version exists for a package. Those commands are documented, so the mechanism for staying current exists. What the README does not document is a rollback path if an upgrade breaks a package; remove and reinstall are the documented recovery commands.

The larger cost is that the last push was on 2017-01-13. Package definitions in packages/ are only as current as the repository's commit history, and the README's own references to ChromeOS M117 and issue #8044 sit far ahead of that date. Before relying on a package, check the packages directory for the definition and confirm it matches the version you need.

Editorial conclusion

Adopt Chromebrew if you have a developer-mode Chromebook on the stable channel, you are comfortable in a VT-2 shell, and you want CLI packages managed by one command instead of hand-built tarballs. Do not adopt it on beta, dev or Canary channels, since the README states those are not supported and will cause major issues with the installation. Before installing, verify three things: that your device is in developer mode, that you are on the stable channel, and that the packages you need appear in the packages directory. Also check the armv7l note for aarch64 devices, because the README states only armv7l packages are provided even on an aarch64 userspace.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes