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.
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 binarybin/hobby-installer-darwin- macOS binary (gitignored, local testing only)bin/hobby-installer-development- Development binary for current platformbin/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
- Welcome - Detect Install vs Upgrade mode
- Version - Select Insights version (latest recommended)
- Domain - Enter domain for TLS certificate (skipped if already in
.env) - Checks - Verify system requirements
- Install - Clone repo, generate config, pull images, start Docker stack
- 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:
- Builds the Linux binary using
make build-linux - Creates a versioned release (e.g.,
hobby-20260108-153045) for history - Updates the
hobby-latestrelease with the new binary
This means:
- Stable URL:
https://github.com/Insights/insights/releases/download/hobby-latest/insights-hobbyalways points to the latest build - Version history: All previous builds are available at
https://github.com/Insights/insights/releases?q=hobby-&expanded=true