Setting Up My Dev Environment on Raspberry Pi 500+ in 2026

19 mars 2026

#raspberry-pi#linux#arm64#neovim#tmux#alacritty#zsh#devenv#golang#typescript

I recently got my hands on a Raspberry Pi 500+ — the keyboard-computer with 16GB RAM, a 256GB NVMe SSD and a Cortex-A76 quad-core under the hood. The project I’m currently working on targets Linux ARM64, so running the Pi as my main dev machine instead of cross-compiling from macOS just makes sense. Same architecture, same constraints.

This is a writeup of how I set it up. Not a beginner guide — more of a reference for myself and anyone who wants a similar setup without the trial and error.

The Stack

Alacritty — terminal emulator
zsh + oh-my-zsh + Powerlevel10k — shell
tmux — multiplexer
Neovim + kickstart.nvim — editor
Go 1.23, Node 24 (via nvm) — runtimes
Docker + Docker Compose — containers
Tokyo Night — colorscheme, everywhere

Why These Choices

Nothing revolutionary here. Alacritty is fast and GPU-accelerated, which matters more on a Pi than on a beefy laptop. Tmux because I live in the terminal and need persistent sessions. Neovim over VS Code because on ARM the difference in responsiveness is noticeable, and kickstart gives you a clean starting point you actually own rather than a distro you’re at the mercy of.

Tokyo Night as a unified theme across all layers — terminal, shell prompt, tmux status bar, editor — because visual consistency across the stack is underrated. When everything shares the same palette you stop noticing the tooling and start focusing on the code.

System Prep

sudo apt update && sudo apt full-upgrade -y
sudo apt install -y build-essential curl wget git unzip pkg-config \
  libssl-dev cmake ninja-build fontconfig ripgrep fd-find fzf

Alacritty

Alacritty isn’t in Pi OS repos in a recent enough version, so build from source using Rust:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
source "$HOME/.cargo/env"
git clone https://github.com/alacritty/alacritty.git
cd alacritty
cargo build --release
sudo cp target/release/alacritty /usr/local/bin/

Config lives at ~/.config/alacritty/alacritty.toml. The most important line:

[env]
TERM = "xterm-256color"

Without this, Alacritty advertises itself as alacritty to tmux, which breaks true color passthrough. Everything downstream — tmux, nvim, syntax highlighting — relies on this being set correctly.

MesloLGS NF is required for Powerlevel10k glyphs:

mkdir -p ~/.local/share/fonts
wget -O ~/.local/share/fonts/MesloLGS-NF-Regular.ttf \
  https://github.com/romkatv/powerlevel10k-media/raw/master/MesloLGS%20NF%20Regular.ttf
fc-cache -fv

zsh + oh-my-zsh + Powerlevel10k

sudo apt install -y zsh
sh install-omz.sh  # download and inspect first

# Powerlevel10k
git clone --depth=1 https://github.com/romkatv/powerlevel10k.git \
  ${ZSH_CUSTOM:-$HOME/.oh-my-zsh/custom}/themes/powerlevel10k

# Plugins
git clone https://github.com/zsh-users/zsh-autosuggestions \
  ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-autosuggestions
git clone https://github.com/zsh-users/zsh-syntax-highlighting \
  ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-syntax-highlighting

chsh -s $(which zsh)

The p10k instant prompt block must be at the very top of .zshrc — before oh-my-zsh, before PATH exports, before everything. If it’s not, you’ll get warnings inside tmux on every pane open.

Run the p10k wizard outside tmux on first launch. It detects font glyphs and writes ~/.p10k.zsh. Running it inside tmux before the color config is solid can produce a misconfigured prompt.

tmux

Default keybindings are fine. The only meaningful changes:

# Keep cwd when opening new panes/windows
bind '"' split-window -v -c "#{pane_current_path}"
bind % split-window -h -c "#{pane_current_path}"
bind c new-window -c "#{pane_current_path}"

# Critical for Neovim — eliminates escape key lag
set -g escape-time 0

# True color passthrough
set -g default-terminal "tmux-256color"
set -ag terminal-overrides ",xterm-256color:RGB"

The true color setup is a chain: Alacritty sets TERM=xterm-256color, tmux overrides that terminal to support RGB, nvim sees a true color terminal. If any link breaks you get washed-out 256-color themes. The way to verify it’s working:

python3 -c "
import sys
for i in range(0, 256):
    r, g, b = i*2, 100, 255-i*2
    sys.stdout.write(f'\x1b[48;2;{r};{g};{b}m \x1b[0m')
print()
"

Smooth gradient = true color. Banded = something in the chain is broken.

Neovim

Neovim ships prebuilt ARM64 binaries now — no need to compile:

wget https://github.com/neovim/neovim/releases/download/stable/nvim-linux-arm64.tar.gz
tar -xzf nvim-linux-arm64.tar.gz
sudo mv nvim-linux-arm64 /opt/nvim
sudo ln -s /opt/nvim/bin/nvim /usr/local/bin/nvim

Kickstart as the base config:

git clone https://github.com/nvim-lua/kickstart.nvim.git ~/.config/nvim

Kickstart uses lazy.nvim as its plugin manager — lazy.nvim is not a distro, just a package manager. The distros (LazyVim, AstroNvim, NvChad) are full configurations built on top of it. Kickstart is a single init.lua you own and modify directly. That distinction matters when things break.

LSP

Mason handles LSP installs. In nvim:

:MasonInstall gopls typescript-language-server eslint-lsp prettierd lua-language-server

Then in init.lua, find the servers table and add:

local servers = {
  gopls = {},
  ts_ls = {},
  eslint = {},
  lua_ls = {},
}

Without explicitly listing servers here, Mason installs the binaries but kickstart never tells the LSP client to attach them. Easy to miss.

Theme

Tokyo Night is already in kickstart, just commented out. Uncomment it and set:

vim.cmd.colorscheme 'tokyonight-night'

tokyonight-night is the darkest variant and matches the terminal palette exactly.

Runtimes

Go — grab the ARM64 tarball directly from go.dev, no script involved:

wget https://go.dev/dl/go1.23.4.linux-arm64.tar.gz
sudo tar -C /usr/local -xzf go1.23.4.linux-arm64.tar.gz

Node — nvm is the cleanest approach for managing versions:

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.0/install.sh | bash
nvm install --lts

Docker

Docker provides an official install script that handles everything automatically — architecture detection, repo setup, the works:

curl -sSL https://get.docker.com | sh

Worth inspecting before running if you’re cautious — visit get.docker.com to read it first. Docker is a trusted source and this is their officially recommended approach for Raspberry Pi.

Then add your user to the docker group so you’re not typing sudo on every command:

sudo usermod -aG docker $USER

Group changes don’t take effect in the current session — log out and back in, or reboot. Verify it stuck:

groups
# should include "docker" in the list

This gets you Docker Engine plus docker compose (v2) as a proper plugin.

SSH + GitLab

ssh-keygen -t ed25519 -C "you@yourdomain.com"
cat ~/.ssh/id_ed25519.pub
# add to GitLab → Preferences → SSH Keys
ssh -T git@gitlab.com

Use SSH URLs for cloning — no tokens, no passwords, no accidental credential exposure.

Final State

node    v24.14.0
npm     11.9.0
go      1.23.4 linux/arm64
nvim    0.11.6
tmux    3.5a
zsh     5.9 aarch64
git     2.47.3

TL;DR: Pi 500+ is a legitimate dev machine in 2026. The ARM64 constraint is a feature if your target is also ARM64. The main friction is true color passthrough across Alacritty → tmux → nvim, which comes down to TERM=xterm-256color in Alacritty and the terminal-overrides line in tmux. Get that chain right and everything else falls into place.