Files
zeekay 1b367e2b62 chore: rebase the tree onto upstream master
The tree was a debranded snapshot of upstream taken around 2026-02-20, and
upstream has moved about five months since. This replaces it with upstream
master, mechanically re-derived: bin/debrand does the rename, and the
pipeline and squashed migrations are restored from the shipped tree.

Not a merge. The previous import replaced the tree wholesale in a single
commit, so there is no shared content history to merge against. Reproducing
the rename on the new tree is what actually converges.

What survives: .hanzo/workflows, the Dockerfiles and bin/docker* entrypoints,
compose files, LLM.md, and insights/migrations. The squashed initial
migration is load-bearing — the live database records it by name, so
upstream's ~918 individual migrations cannot come back.

Nine products are dropped as unreferenced. Twenty-one more that we do not run
are kept anyway because the core app still imports them; unpicking those is a
refactor and does not belong in a rebase.

This base does not build yet, and the reasons are not in the rename:
upstream now wants Python 3.13.13 against our 3.12.12 and Django 5.2 against
our 4.2, and the dependency manifests still name upstream packages that we
republish under our own names. Those are decisions, not renames.
2026-08-01 15:44:40 -07:00

4.8 KiB

Insights Hobby Installer

A TUI (Terminal User Interface) and CI-compatible installer for Insights self-hosted hobby deployments. Built with Go using Bubbletea.

Features

  • Interactive TUI mode: Beautiful terminal UI with spinners, colors, and step-by-step progress
  • CI mode: Non-interactive mode for automated deployments (GitHub Actions, GitLab CI, etc.)
  • Version picker (latest, latest-release, or custom tag/commit)
  • Domain configuration with validation
  • System requirement checks (Docker, memory, disk space, network)
  • Step-by-step installation progress
  • Health check waiting
  • Success/failure screens with troubleshooting tips

Usage

Interactive mode (default)

./hobby-installer

CI mode

CI mode is automatically enabled when common CI environment variables are detected (CI, GITHUB_ACTIONS, GITLAB_CI, etc.), or can be forced with --ci:

# Explicit CI mode
./hobby-installer --ci --domain insights.example.com

# With specific version
./hobby-installer --ci --domain insights.example.com --version latest

# Upgrade (domain read from existing .env)
./hobby-installer --ci

Flags:

  • --ci - Force non-interactive CI mode
  • --domain - Domain where Insights will be accessible (required in CI mode unless already in .env)
  • --version - Insights version to install (default: latest)

Building

Prerequisites

  • Go 1.25+

Build commands

cd bin/hobby-installer

# Build for development (current arch) and run
make

# Build for specific architecture
make build-darwin
make build-linux

# Build all (development, linux, darwin)
make build-all

Output binaries:

  • bin/hobby-installer-linux - Linux binary
  • bin/hobby-installer-darwin - macOS binary (gitignored, local testing only)
  • bin/hobby-installer-development - Development binary for current platform
  • bin/hobby-installer-demo - Demo binary for testing UI components

Running locally

# Build and run development binary
make run

# Or for macOS-specific binary
make build-darwin
../hobby-installer-darwin

Demos

Run isolated demos of specific UI components:

# Build demo binary only
make build-demo

# Build and run a specific demo
make demo DEMO=checks

Available demos:

  • checks - System requirements check UI

Other make targets

make deps         # Download Go dependencies
make clean        # Remove build artifacts
make test         # Run Go tests
make fmt          # Format Go code
make lint         # Run golangci-lint
make help         # Show all available targets

Architecture

bin/hobby-installer/
├── main.go        # Entry point: parses args, delegates to tui/ or ci/
├── core/          # Business logic (checks, install steps, docker, git, env)
├── tui/           # Interactive TUI mode (Bubbletea)
│   └── steps/     # Step views (welcome, version, domain, checks, install, complete)
├── ci/            # Non-interactive CI mode (console output)
├── ui/            # Shared UI components (styles, ASCII art)
└── demo/          # Demo binary for testing UI components

Both tui/ and ci/ consume the same core.GetChecks() and core.GetInstallSteps() - the logic is defined once, only the presentation differs.

Installation flow

  1. Welcome - Detect Install vs Upgrade mode
  2. Version - Select Insights version (latest recommended)
  3. Domain - Enter domain for TLS certificate (skipped if already in .env)
  4. Checks - Verify system requirements
  5. Install - Clone repo, generate config, pull images, start Docker stack
  6. Complete - Success message with URL or troubleshooting tips

Production deployment

On an Ubuntu server:

# Download and run
curl -L https://github.com/Insights/insights/releases/download/hobby-latest/insights-hobby -o insights-hobby
chmod +x insights-hobby
./insights-hobby

For CI/automated deployments:

curl -L https://github.com/Insights/insights/releases/download/hobby-latest/insights-hobby -o insights-hobby
chmod +x insights-hobby
./insights-hobby --ci --domain your-domain.com

Release process

The hobby installer binary is automatically built and released when changes are pushed to master in the bin/hobby-installer/ directory.

The GitHub workflow (.github/workflows/build-hobby-installer.yml) does the following:

  1. Builds the Linux binary using make build-linux
  2. Creates a versioned release (e.g., hobby-20260108-153045) for history
  3. Updates the hobby-latest release with the new binary

This means:

  • Stable URL: https://github.com/Insights/insights/releases/download/hobby-latest/insights-hobby always points to the latest build
  • Version history: All previous builds are available at https://github.com/Insights/insights/releases?q=hobby-&expanded=true