Series: Setting Up Signet & OpenClaw, shown on a Mac Mini Runtime target: 10-12 minutes Tone: Plainspoken, reason-first, showing terminal throughout
Now that the machine is reachable and sane to manage remotely, we make it pleasant to maintain.
That part matters more than people admit. A server you hate logging into is a server you postpone touching. Then updates get skipped, fixes get delayed, and the whole box slowly turns into a haunted shed.
So in this video we're doing the boring but necessary developer setup: Homebrew, Node, Bun, Git, Neovim, tmux, and a shell that does not make remote work feel like punishment.
And same rule as the last video: the goal is not to manually paint every line onto the machine forever. If you already have dotfiles, bootstrap scripts, or a repo that defines your standard environment, use them. I will link my dotfiles and example configs in the description. The video should focus on the moving parts that matter, not pretend every good setup begins with hand-typed heredocs.
This is also where macOS and Linux look most similar in practice. You still need the same categories of tools: package manager, shell config, editor, tmux, git, Node, Bun. The only thing that really changes is how you install them.
First, SSH in.
ssh mac-mini
On a fresh Mac, Homebrew is usually the first thing missing.
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
Once that finishes, add it to your shell path. On Apple Silicon,
Homebrew lives in /opt/homebrew, not /usr/local.
echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> ~/.zprofile
eval "$(/opt/homebrew/bin/brew shellenv)"
Check it.
brew --version
One useful gotcha to remember: non-login shells do not automatically see Homebrew on PATH. If you are automating this box through SSH tools later, you may need to prefix commands with:
eval "$(/opt/homebrew/bin/brew shellenv)" &&
That detail bites people constantly.
Linux equivalent: this is where you would use apt, pacman, dnf,
or whatever your distro speaks. Same tool stack, different package
manager.
Now install the core packages.
brew install neovim tmux git starship gh node
The list is deliberate. On Linux, I would install the same general stack and move on.
neovim, because editing files over SSH should not feel miserable.tmux, because remote sessions drop and I do not enjoy losing work.git, because this machine is going to own real config.starship, because shell ergonomics matter.gh, because HTTPS pushes on a headless Mac are annoying without it.node, because Signet's bin shim expects it even if Bun does most of the heavy lifting.
Signet runs happily with Bun, so install that next.
curl -fsSL https://bun.sh/install | bash
Then reload your shell.
source ~/.bashrc
# or if you're on zsh:
source ~/.zshrc
Verify it.
bun --version
The Bun install flow is basically the same on Linux too.
The Node plus Bun combo is not optional here. Even if you install
signetai globally with Bun, the generated bin shim still uses
#!/usr/bin/env node. If node is not on PATH, the CLI falls over in a
way that feels dumber than it should.
Set your Git identity if this machine does not already have one.
git config --global user.name "Your Name"
git config --global user.email "your@email.com"
If this box is mostly going to push to GitHub over HTTPS, a GitHub noreply address is often the least annoying option.
This step is boring until you skip it. Then the first git push fails
with could not read Username: Device not configured, and now you're
troubleshooting credentials on a headless Mac instead of doing the work
you actually meant to do.
So do it now.
gh auth login
Follow the prompts, then install the credential helper.
gh auth setup-git
That is the part that makes ordinary HTTPS pushes behave.
Use whatever editor setup you actually like. The point is not to copy my dotfiles exactly. The point is to have a remote editing environment you trust.
I keep my Neovim config in git, so I clone it. If you already have your own editor repo, use that instead.
mkdir -p ~/.config
git clone https://your-git-server/your-user/nvim.git ~/.config/nvim
If your config expects a machine-specific config.json, create the
small override file it needs. I keep an example in the repo linked in
the description. I am not going to read a full JSON blob at you in a
setup video.
Then install plugins headlessly.
nvim --headless "+Lazy! sync" +qa
For the shell and terminal side, I prefer linking my own personal dotfiles instead of pretending they belong inside the editor config. If you already keep your dotfiles in a repo, this is the moment to use them. Mine are linked in the description as an example.
For example:
git clone https://your-git-server/your-user/dotfiles.git ~/.dotfiles
ln -sf ~/.dotfiles/.tmux.conf ~/.tmux.conf
ln -sf ~/.dotfiles/starship.toml ~/.config/starship.toml
If your Neovim repo already includes those files and that is how you like to organize things, that is also fine. The important part is just that the machine ends up with the same environment you are used to.
And make sure tmux has the backspace fix for SSH.
# Add to ~/.tmux.conf
set -ga terminal-overrides ",*:Tc,*:kbs=\177"
That one tiny line saves a remarkable amount of irritation.
Now make the shell a little less bare.
If you already keep your shell config in dotfiles, this is where I would just link it and move on. That is the realistic path. If you need a starting point, I have an example shell config linked in the description.
The minimum pieces I care about are simple:
export EDITOR=nvim
export VISUAL=nvim
eval "$(starship init zsh)"Everything else is personal preference. The point is not to reproduce my aliases line for line. The point is to make the box feel familiar enough that you will keep using it.
Reload the shell.
source ~/.zshrc
Run the checklist.
nvim --version | head -1
tmux -V
node --version
bun --version
gh --version
starship --version | head -1
gh auth status
git config --global user.name
If all of that answers cleanly, the machine is in good shape.
One habit is worth calling out before we move on.
When you're working on a remote box, live in tmux.
tmux new -s main
If your connection drops, the work keeps running. Reattach with:
tmux attach -t main
That becomes especially important in the next video when we start running Signet setup and background services.
That's the environment pass.
The point here was not perfection. It was to make the machine pleasant enough that you will keep maintaining it. In the next video, we install Signet and turn this from a remote machine into an actual agent box.