Starship is a cross-shell terminal prompt written in Rust that runs on Bash, Zsh, Fish, PowerShell, Nushell, and every other major shell on Linux, Mac, and Windows. It replaces your default prompt with contextual output that adapts to what you’re actually doing at that moment. This guide covers how the Starship prompt works, how to install and configure it, and which modules are worth enabling for security and DevOps work.
Tip: Runstarship explainat any point to see which modules are currently active in your prompt and why each one is showing. It's the fastest way to debug an unexpected prompt change.
Most shell prompts run modules one at a time in sequence. Starship runs every active module in parallel. That’s the core reason it stays fast even when you have Git status, a Kubernetes context, a Python version, and a Docker context all active simultaneously.
The modules are also contextual. Starship only displays a module when it detects the relevant context: step into a Python project directory and the Python version appears; leave that directory and it disappears. Nothing shows unless it’s directly relevant to where you are.
Starship is also not a replacement shell. It hooks into your shell’s native prompt mechanism via a single initialization line. That means you keep your existing shell, your existing scripts, and your existing configuration, and just get a better prompt on top of it.
Install a Nerd Font in your terminal emulator before anything else. Nerd Fonts patch standard typefaces to include icons and symbols. Without one, Starship’s prompt icons render as broken Unicode boxes instead of recognizable glyphs, and no configuration change will fix it.
Install Starship with your package manager or the official install script:
# Linux (official install script) curl -sS https://starship.rs/install.sh | sh # macOS with Homebrew brew install starship # Windows with Scoop scoop install starship # Arch Linux pacman -S starship
The curl install script works on most Linux distributions and does not require root for a user-level install. Package manager versions may run a release or two behind the latest.
After installing, add the initialization line to your shell config. This line must be the last entry in the config file. Loading it before other configuration blocks breaks the prompt silently.
# Bash — add to ~/.bashrc eval "$(starship init bash)" # Zsh — add to ~/.zshrc eval "$(starship init zsh)" # Fish — add to ~/.config/fish/config.fish starship init fish | source # PowerShell — add to your PowerShell profile Invoke-Expression (&starship init powershell)
If you’re new to working with shell configuration files, these lines go at the very bottom of the relevant config file, below everything else you have there.
All configuration lives in a single TOML file at ~/.config/starship.toml. Starship uses TOML because it’s human-readable and supports inline comments without any special syntax. The official Starship configuration documentation lists every available module and its full set of options.
To store your config in a different location, set the STARSHIP_CONFIG environment variable to a custom path. Use the env command to confirm the variable is active in your current session before troubleshooting a prompt issue:
export STARSHIP_CONFIG=~/dotfiles/starship.toml # Verify it's set env | grep STARSHIP
Each module has its own config block in the TOML file. Here’s an example that limits directory truncation and disables the package version module, which is noisy in most workflows:
[directory] truncation_length = 3 truncate_to_repo = true
[package]
disabled = true
You can also display custom data using the [custom.name] block. It runs any shell command and displays the output inline in your prompt. Common uses include showing an active VPN status, the current AWS profile, or a lab environment indicator that no built-in module covers.
The Git modules deliver the most immediate value. Starship shows the current branch name, ahead/behind commit counts, staged changes, unstaged changes, and stash count directly in the prompt. Knowing your git branch status without running a separate command removes a small but constant source of friction across the workday.
| Module | What It Shows | Useful For |
|---|---|---|
git_branch | Current branch name and status indicator | All Git workflows |
git_status | Staged, unstaged, and ahead/behind counts | Code review and commits |
kubernetes | Active cluster and namespace | Cloud ops and DevOps |
aws | Active AWS profile and region | Cloud security assessments |
python | Python version and active virtualenv name | Scripting and exploit dev |
docker_context | Active Docker context | Container-based workflows |
cmd_duration | Time the last command took to run | Performance profiling |
status | Exit code of the last command | Script debugging |
The status module is off by default. Turn it on to display the exit code of the last command. That’s specifically useful when running tools that fail silently or return non-zero codes you’d otherwise miss.
The cmd_duration module shows how long the last command took. Set a minimum threshold so it only appears for slow commands and stays hidden during normal fast operations:
[cmd_duration] min_time = 2_000 format = "took [$duration]() "
The Starship prompt is one of the most practical terminal improvements for Linux and Kali workflows. It’s fast because of Rust and parallel execution, flexible because of TOML configuration, and portable because the same config file works across every shell you use. Set it up once and it stays out of your way.