vendasta/setup-new-computer-script: a macOS bootstrap tied to one company

A bootstrap script hardwired to one company

The repository holds three things: a LICENSE file, a README and one executable file, setup-new-computer.sh. The project description says plainly what it is for: quick setup and installation of tools and applications for new developers at Vendasta. The documentation states it was tested on Mac OS 10.14 through 12 and works on both Intel and M1/M2 Macs, which narrows the audience to laptops that a company is currently handing out.

This is not a generic dotfiles repository. There is no global installer framework, no profile script for Linux, no Windows path. The topics listed for the project, setup-macos, setup-script and setup-wizard, match that scope. The license is MIT, so the code itself can be reused and modified, and the documentation even includes a section on using the script at another company. What that reuse requires is a rewrite of nearly every configuration value inside it.

The repository has no GitHub releases, so there is no versioned artifact to pin. The last push was on 2026-06-24, which tells you the script still receives occasional attention rather than being a frozen artifact from a past onboarding cycle.

Homebrew is the backbone, not the script

The most interesting part of the script is the block it appends to your shell profiles. The documented .bash_profile content starts by silencing the bash deprecation warning and then wires Homebrew into the environment with a check on the processor architecture, because Apple Silicon and Intel Macs put Homebrew in different prefixes.

# Start Homebrew
if [[ "$(uname -p)" == "arm" ]]; then
    # Apple Silicon M1/M2 Macs
    eval "$(/opt/homebrew/bin/brew shellenv)"

That conditional is the part worth stealing. Any script that assumes /usr/local/bin/brew breaks on a fresh M-series machine, and this one branches instead. The documented zprofile content follows the same shape for zsh, and the documentation says the script creates or modifies .bash_profile and .zprofile with path and autocomplete sources.

So the script's real function is not installing a single tool. It establishes a Homebrew based toolchain and then layers language runtimes and cloud clients on top, which is why it can be re-run and still make progress on a half configured machine.

One curl line installs it, the manual path avoids the pipe

The quick path pastes a single command into a Mac terminal, and the README recommends this route:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/vendasta/setup-new-computer-script/master/setup-new-computer.sh)"

Read what that line does. It pipes the contents of a file on the master branch straight into a shell interpreter, so you are trusting a branch head rather than a tagged release, and the project publishes no releases to pin instead. If your organisation reviews scripts before they run, the manual route is the one to take: download setup-new-computer.sh into your home folder, mark it executable, and run it from Terminal. The documentation also warns that some installs will ask for your password, and that you will be prompted for a Git email and name, which should match the ones used for your GitHub account.

Whichever route you take, the first real use ends the same way. The script finishes with authentication prompts for the cloud tooling and for the internal CLI, so plan to have those accounts open in another window.

Re-running installs is safe, re-running profile edits is not

The documentation makes two claims that sit in tension. It says you can run the script multiple times without issue, and that on a partially set-up computer it only installs what is missing. That is the behaviour you want from a bootstrap: a laptop that died halfway through onboarding can be repaired by running it again rather than by rebuilding the machine.

The same documentation then warns that if you run it on an already set-up computer, you should check .bash_profile and .zprofile for duplicated paths, imports and other repeated entries. So idempotency holds for package installation and breaks for configuration file writing. A second run on a laptop someone has already customised can leave Homebrew shellenv sourced twice, node upgrade logic appended again, and autocomplete sources repeated.

Practically, that means one of two rules. Run it once on a fresh machine and treat the profiles as generated output, or run it on a machine you have backed up and then diff .bash_profile and .zprofile before you commit them to your own dotfiles. There is no documented flag for a dry run or a profile-only pass, and the script file is the only source of that behaviour.

Authentication is left to your own accounts

Everything the script installs still needs credentials, and the documentation is explicit that a fresh laptop is not usable until you finish four steps by hand.

Git is configured to use SSH for GitHub URLs, so you must generate an SSH key and add the public key to your GitHub account, otherwise Git operations fail on the new machine. The Google Cloud SDK steps run at the end of the script, and the documentation lists them so you can re-run them after a skip:

   gcloud auth login
   gcloud auth application-default login
   gcloud auth configure-docker
   gcloud container fleet memberships get-credentials vendasta-central --project=repcore-prod
   gcloud auth print-identity-token

The cluster name and project identifier in that line are Vendasta's own, so outside the company this command targets something you do not own. The internal CLI is installed from the company's Go module path and is authenticated against a demo and a prod environment:

   go install github.com/vendasta/mscli@latest
   mscli auth login -e demo
   mscli auth login -e prod

JetBrains IDEs are the fourth step. You select the license server option and enter the Vendasta license server address, and the documentation notes that the first Activate click fails on purpose, producing a link to an authorization procedure you complete in JetBrains Vault before activating again.

Where the script stops working

Several limits are documented rather than hidden. The script is macOS only, with no path for Linux or Windows, so a Linux developer or a colleague on Windows gets nothing from it.

There is also a rough edge in zsh, which the documentation says is the default shell in newer Mac OS versions. After running the script you may see a compinit warning about insecure directories and be asked to ignore them or abort. The fix given is a single command:

compaudit | xargs chmod g-w

That command loosens group write permissions on directories flagged by compaudit, which is a real change to your filesystem rather than a cosmetic tweak, and it is applied wholesale to every directory compaudit reports.

The script also predates the removal of the bundled Python 2.7 that older Mac OS versions shipped. For the legacy App Engine projects, the documentation points to an internal help document on setting up PyCharm with Python 2.7, so this part of the onboarding path now depends on company documentation rather than on the script. The internal onboarding wiki page is likewise part of the required steps, and it sits behind a Vendasta Jira login that outside readers cannot open.

Day two: Node 20, Homebrew rollbacks, and no release tags

The script gets a laptop to a usable state, and the documentation then covers what happens afterwards. Vendasta uses Node v20, and a helper command in the shell profiles installs the chosen Node and npm versions, reinstalls global packages such as the Angular CLI, and sets the new version as default:

node-upgrade 20

If you want a version without that reinstall behaviour, nvm is the documented fallback:

# Install a specific version of Node
nvm install 18      # or 10.10.0, 8.9.1, etc

and switching versions is a matter of choosing a target, with the long term support alias available:

nvm use --lts

Homebrew handles the command line tools, and the documentation covers both directions, listing what is out of date and rolling back to a previously installed version of a formula:

brew update
brew outdated

brew switch git 2.25.0

For upkeep, the relevant facts are narrow: the repository has no GitHub releases, so there is nothing to upgrade to in the usual sense, and the last push was on 2026-06-24. The script updates by being re-run against a newer master branch, which means the version you get is whatever that branch happens to contain at the moment you run it.

Editorial conclusion

Adopt this script if you are onboarding a developer into the Vendasta environment and want the same toolchain the team already runs. Do not adopt it as a general purpose workstation bootstrap, since the cloud project, the JetBrains license server and the internal onboarding steps all point at Vendasta infrastructure. Before you rely on it, check the last push date, which was 2026-06-24, and read the .bash_profile and .zprofile changes yourself, because the script writes to both and the documentation admits duplicate entries can appear.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. vendasta/setup-new-computer-script on GitHub