BRAMPP → Install

Install

Running in 60 seconds

Download, drag, open, run the wizard. This page covers what each step does, how to check the app is genuine, and what to do on the rare occasion something goes wrong.

Before you start

Requirements

  • macOS 14 Sonoma or newer. The app uses APIs that do not exist earlier.
  • Apple Silicon. BRAMPP is a native arm64 build; so are the Homebrew services it manages.
  • Homebrew. If it is missing the setup wizard offers to install it — it does not do so behind your back.
  • An administrator account. Editing /etc/hosts, binding low ports and adding a certificate authority to the system trust store all need it. You will be asked, in the moment, for each.

Disk space is mostly not BRAMPP's. The app itself is a few tens of megabytes. What takes room is the stack you choose to install through it — Apache, PHP versions, MariaDB and the rest live under /opt/homebrew like any other Homebrew package, and brew upgrade keeps them current.

Setup

Four steps

  1. Download and drag. Grab BRAMPP.dmg from Releases and drag BRAMPP.app into Applications. Run it from Applications rather than from the mounted disk image — a few macOS protections behave differently inside a read-only volume.
  2. Open it. The app is Developer ID signed and notarized, so macOS launches it without an extra step. No right-click → Open, no trip to Privacy & Security.
  3. Run the setup wizard. It works through Apache ports, PHP-FPM, the mkcert certificate authority, localhost SSL, MariaDB root access and phpMyAdmin — installing only what you approve and printing every command it runs into the console, so nothing happens that you cannot read.
  4. Create your first domain. + New Domain → pick a name and a platform → open https://myproject.test. The virtual host, hosts entry, site folder, starter project and certificate are all in place by then.

From a clean machine the wizard is the long part, and it is long mostly because Homebrew is downloading. Everything after that is seconds.

Trust

Signed, and verifiable by you

You should not have to take a download's word for what it is. Here is how to check.

Every release is signed with a Developer ID Application certificate and submitted to Apple. The resulting ticket is stapled both to the DMG and to the app inside it, which is the part that matters if your first launch happens without a network — Gatekeeper can verify a stapled ticket offline, and cannot verify an unstapled one.

After installing, confirm it yourself:

spctl -a -vvv -t exec /Applications/BRAMPP.app
# accepted
# source=Notarized Developer ID

To see who signed it and with which team identifier:

codesign -dv --verbose=4 /Applications/BRAMPP.app 2>&1 | grep -E 'Authority|TeamIdentifier'

Building from source produces an unsigned local build instead. That is expected — an app you compiled yourself is never quarantined, because it never passed through the download path that applies the quarantine flag.

Alternative

Building from source

The repository is MIT licensed and builds with Xcode 15 or newer:

git clone https://github.com/macitkaraca/brampp.git
cd brampp/macos
open BRAMPP.xcodeproj

Select the BRAMPP scheme and run. The unit tests live in the BRAMPP test target and run with ⌘U — they cover the pure logic (version comparison, config parsing, dependency ordering, path validation) rather than anything that would touch your actual services.

Troubleshooting

When something does go wrong

"BRAMPP can't be opened"

Almost always an older download. Signing and notarization landed in a specific release; a DMG saved before that will still trip Gatekeeper. Delete the copy in Applications, empty the Trash, and download the current DMG from Releases again. If it persists, check what macOS actually objects to:

spctl -a -vvv -t exec /Applications/BRAMPP.app

A port is already taken

macOS ships its own Apache, and it is occasionally running. BRAMPP tells you which process owns the port rather than just failing; the usual fix is to stop the system copy:

sudo launchctl unload -w /System/Library/LaunchDaemons/org.apache.httpd.plist

A new domain is not being served

If a domain seems invisible to the web server, restart that service from the Services tab — and if it keeps happening on a current build, please open an issue with the domain's platform and web server, because that is a bug rather than something you should have to work around.

The browser still complains about the certificate

Check the wizard finished the mkcert step; the CA has to be in the system trust store, not just generated. The local HTTPS guide explains what to look for and why .local can fail even when everything else is correct.

NextWhat BRAMPP manages → AlsoGuides →