Web dashboard

bitloom --web serves a browser dashboard for the same build service the TUI uses. Builds queued from the browser and from the terminal share one serial queue and one history, so you can start a build in the TUI, follow it on a laptop or phone, and retry it from either place.

Screenshot Web dashboard following a running build

Start it#

bitloom --web                              # loopback only, opens a browser
bitloom --web --no-browser --port 9000     # pick the port; 0 chooses a free one
bitloom --web --config .bitloom/profiles.json --state .bitloom

The command prints a URL such as http://127.0.0.1:8765/#token=… and opens it in a graphical browser: on WSL the Windows browser (through wslview when installed, otherwise PowerShell). Text-mode browsers such as lynx or w3m are never started, because they would take over the terminal; without a graphical browser Bitloom only prints the URL. --no-browser skips opening. The token lives in the URL fragment: it is never sent in requests, the page keeps it for the browser tab and sends it as an X-Bitloom-Token header. Ctrl+C stops the web server only; builds keep running in the service. --state must match the TUI to see the same history.

The dashboard needs only the Python standard library. It is not a multi-user server: anyone holding the URL can queue builds for your profiles.

Remote access#

Keep the default loopback address and tunnel it:

ssh -L 8765:127.0.0.1:8765 build-server

--host 0.0.0.0 listens on every interface and prints a warning; use it only on a trusted network. On loopback the server also checks the Host header, which defeats DNS-rebinding attacks.

Sections#

Animation Recipes: a layer, the Images filter, then a search

Build target#

The target field in the top bar is a combobox. Click it, press t or ↓ to list the image recipes found in the project's layers: the kas target: and images already built come first, example and test images last, each with its layer and SUMMARY. Type to filter, ↑/↓ to choose, Enter to pick, Enter again to build. Any other recipe or several space-separated targets can still be typed.

An image recipe is a .bb that inherits core-image or image, or requires another image recipe. Only files with "image" in their path are read, so the list is ready in a few milliseconds.

Animation Typing in the target field filters the image recipes; Enter picks one

Animation A real force compile of busybox followed live, then its summary (about three times faster)

The build detail has Toaster-style tabs computed from the stored log: Summary (errors, warnings, failed tasks), Sstate reuse, grouped Warnings, observed task Timings and Compare with the previous run of the same command. A running build shows its ETA next to the task count.

Screenshot Build summary tab

The progress line above the tabs shows the task count, the percentage and the ETA; a dot marks where BitBake is, and a failed build keeps a ✖ where it stopped. When a build fails, a toast offers its summary, which starts with the failure diagnosis: the category, the failed tasks, their logs, the lines that caused it and the next step.

Animation A failed sample build: the toast, then the summary opening on the diagnosis

Notifications and animations#

The bell button in the top bar turns on browser notifications for builds that end while the tab is in the background; the build service's own desktop and webhook notifications are configured in Configuration (see Daily helpers). New jobs slide in at the top of the history; existing rows update in place, so the list never flickers while a job runs. Toasts slide in for every state change of a job: started, succeeded, failed (with a button that opens the summary) and cancelled. Hover a toast to pause its countdown; failures stay longer. Cards count up, rings and meters animate, the CPU card draws a live sparkline, and views fade in. With the operating system's reduce motion setting, all animations are disabled.

Keyboard#

The dashboard works without a mouse.

Screenshot Command palette filtered for SBOM operations

The operation dialog lists every non-interactive operation grouped like the TUI command center, previews the exact command and refuses operations your Yocto release does not provide, naming the alternative.

Phone and narrow windows#

The layout collapses to one column, the navigation becomes a scrolling bar and toasts move to the bottom.

Screenshot Dashboard on a phone, light theme

Themes#

The round button in the top bar (or Ctrl+K → Theme: …) chooses how the dashboard looks: System (the default: light or dark as the operating system says), Bitloom dark and light, and the palettes the TUI also has: Ubuntu, Darcula, Monokai, Nord, Dracula, Tokyo Night, Catppuccin Mocha and Latte, Gruvbox, Solarized Dark and Light, High contrast. The choice is remembered by this browser and applied before the page draws, so it never flashes the default first. Status colours (success, warning, error) and chart colours keep their meaning in every theme; the chart palette is checked for colour-blind separation against each theme's background.

Screenshot The theme menu with Tokyo Night applied

API#

The page uses a small JSON API that scripts can use too (all calls need the X-Bitloom-Token header):

Animation Animated tour of the web dashboard