Free macOS menu bar app
BuildBar
Netlify sites and build status in the macOS menu bar
List every Netlify site and the latest deploy without opening a dashboard. The icon turns blue while anything is building.
v2.2.1 · 15.7 MB · macOS · Apple silicon · free for personal and public use
What it does
Netlify builds from your menu bar
- All sites and latest deploys from the menu bar
- Blue while building, red if a latest deploy failed
- Auto-Import from Netlify CLI, browser, or a pasted token
Version history
BuildBar release notes
Every published version, newest first.
v2.2.1
Current9 Nov 2026- The time on a site's row is when its deploy went live or failed. It was the time the deploy started, so a 6-minute build that had just been published read `Published · 6m ago`, and one that failed after 6 minutes read `Failed · 6m ago`. Rows, the site's submenu and the preview line now show when the deploy finished; a deploy still building keeps its elapsed time.
v2.2.0
8 Nov 2026- A menu bar icon drawn from the BuildBar logo. The up arrow inside the ring, as on entelxcore.com, instead of a generic system symbol. When nothing needs attention it still takes the menu bar's own color, light or dark, and it is tinted when a production deploy builds or fails, as before.
- A clearer menu. Each site is one row: a status dot (teal when its production deploy is ready, red when it failed, a half dot in your accent color while it builds, gray for anything else), the name, and the state with its time in a right-aligned column, such as `Published · 4m ago`, `Building · 1m 12s` or `Failed · 25m ago`. A ready deploy that is not the live one (after a rollback, or with auto publishing locked) reads `Ready`. The header, with the app's logo, starts with `Production`. Previews still never color a row.
- The new teal logo. The app's icon is now the teal BuildBar logo from entelxcore.com.
v2.1.0
8 Nov 2026- Added deploy actions to each site's submenu. Retry deploy and Clear cache and retry deploy start a new production deploy from the latest commit on the production branch; Cancel deploy stops a production deploy while it builds; Roll back to previous deploy… publishes the newest finished production deploy before the live one. Each asks first, naming the site (a rollback names the deploy's time, branch, commit and title, and the live deploy it replaces), runs in the background, then says what happened: done, Netlify's sign-in was rejected (Reconnect), Netlify couldn't be reached, or Netlify refused with its own message. The menu then refreshes. A deploy canceled this way is not announced as “Failed”.
- Added a separate line for previews; the row and the icon now follow production. The newest deploy of any kind used to drive each site, so a broken deploy preview marked the site Failed and turned the icon red while production was fine. The row, the icon, the badge and the 10-second polling now follow the latest production deploy only, and the latest deploy preview or branch deploy is a secondary line in the submenu (“Preview · feature-x · Failed 3m ago”) with Open preview, plus Open preview deploy for its log when it failed. It still takes one deploys request per site per refresh. Open last deploy is now Open production deploy.
- Added a quiet notice for a failed preview. Production deploys are announced as before (Building, Deployed, Failed). A failed deploy preview or branch deploy now posts “Preview failed · site” (or “Branch deploy failed · site”) without a sound, never “Failed site”; previews building or going live are not announced.
v2.0.3
7 Nov 2026- The menu bar icon shows on a light menu bar. The idle icon and its badge were always drawn white, so they vanished when the wallpaper (or Reduce Transparency) made the menu bar light. The idle icon is now a template image that macOS draws in the menu bar's own color and redraws when that changes, and the idle badge uses the menu bar's text color; the blue, red, orange and update-dot icons keep their colors.
- Settings survive a write cut short. state.json was rewritten in place, so a crash or full disk mid-write left it empty or half written, and BuildBar then forgot its settings and sign-in mode. It is now written to a temporary file in the same folder and swapped in once complete.
- A new credential is checked on its own. Checking a pasted token or an imported browser session also fell back to the saved browser cookie, so once that session expired a fresh cookie was never tried (re-importing kept failing), and a mistyped token showed as connected while an old cookie still worked. Only the credential being checked is now sent, and saving a token removes the old browser cookie from `.env`, so it can no longer stand in when the token stops working.
- Sites from a failed refresh no longer look current. When a check failed (offline after sleep, Netlify down, a 429), the menu kept showing the last sites as if they were fresh, and a site that was building stayed “building…” with a blue icon and 10-second polling until the next successful check. The menu now says “Couldn't refresh — showing data from 14:32” with the error underneath, such a site reads “Last seen building”, the icon is no longer blue for it (a failed deploy still shows red), and checks keep to the normal interval until one succeeds.
- Connect and Auto-Import no longer freeze the menu bar, and say when Netlify can't be reached. Checking a credential ran on the main thread, so BuildBar hung for up to 50 seconds when offline, and Auto-Import then reported “The browser session cookie was not accepted”. The check now runs in the background (the menu reads “Checking with Netlify…”), and a network error, timeout or Netlify error says the credential couldn't be checked and nothing was saved, instead of calling it rejected.
- A token pasted with curly quotes is saved instead of silently dropped. A token copied as “nfp_…” (with the curly quotes Notes, Mail or chat apps add) made Save close without a word. Surrounding curly or straight quotes and whitespace are now removed, a token with such characters inside is refused with a message saying to paste it as plain text, and a request with characters that can't be sent ends in a normal error instead of an exception.
- A deploy waiting for approval no longer counts as building. A deploy in Netlify's “pending review” state (for example a deploy preview from an outside contributor) waits for someone on the team to approve it, which can take days, yet BuildBar turned the icon blue, polled every 10 seconds and posted “Building” for it. Such a site now reads “Awaiting approval” and leaves the icon and polling alone; once approved, it builds and is announced as usual.
v2.0.2
7 Nov 2026- Every deploy gets its Building, Deployed and Failed notification. After any notification BuildBar stayed silent for 5 minutes, across all sites, so a build that finished within 5 minutes of “Building X” never got its “Deployed X” or “Failed X”, and changes on other sites in that window were lost for good. A deploy that started and finished between two checks posted nothing, and a site whose deploy could not be read for one check (or every site, after a check while offline or a Netlify sign-in error) re-announced an old failure once it could be read again. BuildBar now remembers each site's last known deploy and posts once for every change of deploy or state, for every site that changed, with no global pause; a site it has not read a deploy for yet is only recorded, never announced.
- Launch at login no longer starts a second BuildBar, or quits the one you are using. Turning it on loaded the login item right away, and since it starts at load, a second BuildBar appeared next to the first; turning it off unloaded the item, which stops BuildBar when it was the copy started at login. The setting now only adds or removes the login item, which macOS uses at the next login.
- A failed update no longer leaves BuildBar closed. If installing the update failed after BuildBar quit, nothing reopened it. The installer now reopens the installed BuildBar whenever it cannot finish, an update zip with more than one BuildBar.app is refused, and an update that could not be installed at all (BuildBar opened from a temporary location macOS uses for downloads, or an Applications folder this user cannot write) is refused before BuildBar quits, with a message saying why.
- “Update took too long … was cancelled” now really cancels. The download kept going after that message and could quit BuildBar and install minutes later. A cancelled update now stops, and the timeout only counts time without download progress, so a slow connection is no longer cut off.
v2.0.1
7 Nov 2026- BuildBar no longer polls Netlify non-stop. After every refresh it restarted its timer, and a rumps timer fires as soon as it starts, so the next refresh began at once: Netlify was asked back to back, ignoring the check interval (and the 10-second interval while a build runs), using CPU and API quota the whole time. The timer now waits the interval before the next refresh.
v2.0.0
7 Nov 2026- Signed with Developer ID and notarized by Apple. BuildBar was ad-hoc signed, so macOS blocked the first launch until quarantine was cleared in Terminal or the app was opened with right-click → Open. It is now signed with ENTELXCORE's Developer ID Application certificate, with the hardened runtime, and notarized and stapled by Apple: it opens with a double-click like any other app. Because the signature now stays the same from version to version, access you grant it under Privacy & Security carries over to updates instead of being lost with each new build.
- Opens on macOS 13 and later, as the README says. Release builds were made with Homebrew's Python, which is built for the Mac's own macOS, so 0.1.6 needed macOS 27 to open at all. Releases are now built with Python from python.org, the app declares macOS 13 as its minimum, and `release.sh` checks every bundled binary against it before publishing.
- Updates must be signed by the BuildBar developer. Check for Updates… now unpacks the downloaded zip and checks, before BuildBar quits, that the app inside is signed with ENTELXCORE's Developer ID. A tampered or broken download ends in an “Update failed” alert and the current version keeps running.
v0.1.6
18 Oct 2026- Dependabot deploys no longer count. Each site shows its newest deploy that isn't from a `dependabot/…` branch, so a failed Dependabot deploy preview no longer marks the site Failed (or turns the icon red) while production is fine. Dependabot builds don't turn the icon blue or post notifications either. If Dependabot made all of the last 20 deploys, the site shows its latest production deploy.
v0.1.5
9 Oct 2026- You now see when an update is out. When the background check finds a new version, the “Update available” dialog (Install & restart… / Not now) now opens by itself, in front of other windows, once per version. Until now it only posted a notification, which macOS never showed.
- Notifications go through Apple's current API (UNUserNotificationCenter). rumps used the deprecated NSUserNotificationCenter, whose notifications current macOS drops without an error, so the Building / Deployed / Failed deploy notices never appeared either. macOS only shows them for Developer ID signed apps; this ad-hoc build logs the reason to its error log instead.
- HTTPS works on Macs without Homebrew: the bundled OpenSSL only looked for certificates in Homebrew's folder, so requests (update checks included) failed certificate verification there. macOS's own `/etc/ssl/cert.pem` is now trusted as well.
v0.1.4
9 Oct 2026- Built with current dependencies: `packaging` 26.3, `python-dotenv` 1.2.4, `pycryptodomex` 3.24.0, PyInstaller 6.22.3. `requirements.txt` now allows `packaging` 26.x (was capped below 26).
- The build no longer logs `Hidden import 'Crypto' / 'keyring' not found`: those leftover hidden imports were dropped from `build_bar.spec`. browser-cookie3 uses `Cryptodome`, which is still bundled.
v0.1.3
16 Sep 2026- Auto-check for BuildBar updates every 6 hours (was 12). A failed check (offline right after login, server error) is retried up to 3 times, 10 minutes apart, instead of waiting for the next interval.
- Source installs need Python 3.10+: `install.sh` skips Apple's bundled 3.9 and rebuilds a virtualenv created with it (the .app is unaffected).
- The first silent update check really waits a minute after launch. rumps timers fire as soon as they start, so it used to run immediately — twice — often before Wi-Fi was up after login.
v0.1.2
12 Sep 2026- Auto-check for BuildBar updates every 12 hours (first check about a minute after launch). A purple dot on the menu-bar icon plus a notification when a new version is ready; Check for Updates… becomes “Update x.y.z available…”.
v0.1.1
12 Sep 2026- Quit no longer reopens BuildBar. Launch at login used `KeepAlive`, so launchd started the app again. Match RunBar: `KeepAlive` off, unload the login item on Quit (plist stays for the next login).
v0.1.0
10 Sep 2026- First release: menu-bar Netlify build monitor (no Dock icon)
- Lists all sites with latest deploy Ready / Failed / building…
- Blue icon while any site is building, red if the latest deploy failed
- Auto-Import from Netlify CLI, browser `_nf-auth` cookies, or a pasted PAT
- Poll every 30s (15 / 60 / 120 in Settings); 10s while a build is in progress
- Launch at login, notifications, and BuildBar self-update plumbing
More free tools
