The Boot.dev CLI: a small Go program that runs and submits your coding lessons

Installing the binary with go install

The README is unusually long on installation, and for a tool this small that is the right emphasis, because the failure mode is almost always about paths rather than the program. There are two steps and one login.

The CLI is a Go program, so step one is a current Go toolchain. The README recommends the Webi installer as the simplest route on Linux, WSL and macOS:

curl -sS https://webi.sh/golang | sh

The alternative is the official Go installation instructions at go.dev, which on Windows is a downloaded `.msi`. After either, open a new shell and run `go version`, because the README's own advice is that a new shell session is needed before the binary is visible.

Step two installs the CLI itself into the Go toolchain's bin directory:

go install github.com/bootdotdev/bootdev@latest

Then `bootdev --version` confirms it worked. Step three is `bootdev login`, which authenticates against your Boot.dev account.

There is a platform caveat that matters more than it first appears. The README says the overwhelming majority of courses using this CLI are designed for Linux or macOS, or Linux inside Windows via WSL, and suggests WSL is usually what a Windows user wants. It notes one Windows-native course, the data visualization one for Power BI, and asks you to be aware of which platform you are actually on.

Running a lesson's checks and submitting it

Once logged in, the CLI detects the current lesson from your course progress. That detection is the design decision worth noticing: you are not told to pass a lesson identifier, because the tool already knows where you are.

bootdev run

runs the checks without submitting. Submission is a separate command:

bootdev submit

Both accept an explicit UUID if you want to name the lesson rather than infer it:

bootdev run UUID
bootdev submit UUID

And there is a combined form with the `-s` flag, which the README gives as `--submit`:

bootdev run -s
bootdev run -s UUID

That is the entire command surface for lessons, and the design consequence is significant. The checks execute against your working tree on your machine, which means a lesson about building an HTTP server runs your server. It also means the checks are only as good as the environment they run in, which is why the README spends a section on overriding the base URL.

Every command has `-h` and `--help`, and the repository has a `main_test.go` alongside `main.go`, so the flag surface is at least partly under test.

Pointing HTTP lessons at a different port

Lessons that test an HTTP server need to know where to send requests, and the CLI exposes that as one setting with three verbs. The default value is an empty string, which means the lesson's own default applies:

bootdev config base_url YOUR_URL

Reading the current value is the same command with no argument, and resetting is the same command with `--reset`:

bootdev config base_url
bootdev config base_url --reset

The README's stated use case is running your server on a port other than the one the lesson specifies, and it makes one requirement explicit: include the protocol scheme in the URL.

Configuration lives in a YAML file, defaulting to `~/.bootdev.yaml`, or `$XDG_CONFIG_HOME/bootdev/config.yaml` when that environment variable is set. That dual location is a small quality signal, since it means the tool behaves the way other CLI configuration on the platform already behaves.

Colours are configurable in the same `config` subcommand:

bootdev config colors --red VALUE --green VALUE --gray VALUE --magenta VALUE --yellow VALUE

Values can be ANSI colour codes. This is not decoration. A CLI that renders success in green and errors in red is telling you something, and being able to remap those five channels is what makes the output usable over SSH or in a terminal with a different theme.

What the Go dependencies say about the implementation

`go.mod` is short enough to read as a description of the design. The module is `github.com/bootdotdev/bootdev`, requiring Go 1.24.2, and the direct dependencies fall into three groups.

The interface layer is the `charmbracelet` set: `bubbletea` for the interactive terminal program model, `bubbles` for its components, `lipgloss` for styling and `charmbracelet/x/ansi` for escape sequences. This is a TUI, not a plain line-oriented tool, which matches a CLI whose job is showing test output and asking you to log in.

The command and configuration layer is `spf13/cobra` and `spf13/viper`, the standard pairing in Go for a multi-subcommand CLI with YAML configuration. Seeing Viper confirms the `~/.bootdev.yaml` design rather than leaving it to inference.

The lesson-processing layer is the interesting one. `itchyny/gojq` is a pure-Go implementation of `jq`, which is almost certainly how the CLI evaluates lesson check definitions, and `tailscale/hujson` is Tailscale's JSON-with-comments parser, which handles configuration that is not strictly valid JSON. `goccy/go-json` gives faster decoding. `pkg/browser` opens the login page, and `golang.org/x/mod` and `golang.org/x/term` handle module resolution and terminal capabilities.

The repository tree matches: `cmd/` for commands, `client/` for the API client, `checks/` for the check execution, `render/` for output formatting, `messages/` for user-facing strings, and `version.txt` plus `version/` for the version string. Nothing here suggests a server component. The CLI is a client that happens to run code.

Maintenance, upgrade path and what is not in the repository

The project is MIT licensed, the repository is not archived, and the last push was on 2026-09-18. There are no published GitHub releases, so versioning comes from the `version.txt` file and `go install ...@latest`, which resolves to the tip of the default branch rather than a tagged release. That is the usual Go pattern and it has a consequence for reproducibility: there is no release tag to pin to if you need a fixed version in a container build.

The README does document an upgrade story. It notes that if you already installed Go with Webi, running the same Webi command updates it, and for a Go installed another way you check with `which go` on Linux and macOS or `Get-Command go` in PowerShell. For the CLI itself, `go install` at a later date replaces the binary.

The troubleshooting content is mostly about `PATH`, and the README is thorough about it. It identifies where the Go toolchain typically lands, `~/.local/opt/go/bin` for Webi and `/usr/local/go/bin` for the official install, and tells you to test with a full path first:

~/.local/opt/go/bin/go version

If that works, the fix is to add the directory to `PATH` and reload the shell, with separate snippets for `~/.bashrc`, `~/.zshrc` and `fish_add_path`. The same pattern repeats for the `bootdev` binary itself, where the directory is `$HOME/go/bin`, the default `GOBIN` location.

What is absent is as notable as what is present. There is no plugin system, no local lesson files and no offline mode in this repository, and no release notes to consult. The CLI is a thin, well-packaged bridge to a hosted course, and the repository reflects that.

Where this CLI fits against other course tooling

There is a comparison to be made with tools that let you run course exercises locally, and it comes down to where the checks live.

An alternative approach is a self-hosted runner: you clone exercises, run them with whatever test runner the course language uses, and submit nothing. That is more flexible, since it works offline and never phones home, and it is what you want if you are studying material the course only uses as a source.

The Boot.dev CLI goes the other way. The checks come from the service, tied to your progress, and `bootdev submit` is what marks a lesson complete. In exchange you get a consistent interface across languages rather than per-course setup, and a `gojq` based check evaluator that applies the same rules every time.

The honest limit is that both approaches assume you can already run a language's tooling. If a lesson asks you to build an HTTP server, this CLI still needs your server to start, your port to be right, and your dependencies installed. It removes the submission step and the grading ambiguity; it does not remove any of the setup.

For a reader deciding whether the tool is usable outside the courses it ships with, the answer is not really. The lesson checks are defined server side and the README describes no way to point the CLI at your own check definitions, so this is a companion to boot.dev rather than a general-purpose exercise runner.

Editorial conclusion

This is a well-built wrapper for one workflow, and reading it tells you something about how the course works: lesson checks run on your machine, so your editor and toolchain matter as much as the lesson does. `go install github.com/bootdotdev/bootdev@latest` is the whole installation, and `bootdev run -s` is the command you will type most. Two things to check before adopting it inside a container: the CLI needs `$HOME/go/bin` on your `PATH`, and the HTTP base URL override is per machine, so a lesson that assumes a port other than the default will fail in CI unless someone sets `bootdev config base_url` first.

Frequently asked questions

Official sources

1. bootdotdev/bootdev on GitHub
2. Issues
3. License: MIT
4. Project website
5. README