Nix-built, reproducible containers for open-source data infrastructure. Managed from a TUI.

Firestream packages popular open-source projects — Airflow, Kafka, Spark, Superset, PostgreSQL, Redis, JupyterHub, and Odoo — as fully reproducible Nix-built Docker containers. Every container ships with CycloneDX 1.5 and SPDX 2.3 SBOMs for complete supply chain transparency. Install, run firestream, and the TUI auto-detects Docker, discovers available containers, and lets you build, configure, and launch them interactively.

Works on Linux, macOS, and Windows (WSL). Only requires Docker.

• Quick Start
• Containers
• Supply Chain Security
• TUI
• Make Commands
• Application Templates
• Architecture
• Development

• Docker (Docker Desktop on macOS/Windows, or Docker Engine on Linux)

cargo install firestream-tui
firestream

The TUI boots, detects your Docker environment, and shows all available containers. Select a container and press B to build it.

Or use make directly:

git clone https://github.com/Cogent-Creation-Co/Firestream.git && cd Firestream
make airflow-start    # Builds (if needed) and starts Airflow at http://localhost:8090

Every container is built from a Nix flake, producing a bit-for-bit reproducible image with a full software bill of materials.

Every Firestream container embeds four metadata files at /opt/firestream/ generated at build time:

SBOMs are generated by firestream-vib, a Rust tool that reads the Nix closure graph (exportReferencesGraph) at build time and produces industry-standard SBOM documents. Every dependency — including transitive ones — is traced with its exact hash, name, and version from the Nix store.

# Verify SBOMs are present in any Firestream container
docker run --rm firestream-airflow:3.0.3 cat /opt/firestream/sbom-cyclonedx.json | jq .bomFormat
# → "CycloneDX"

Containers can also be scanned with Trivy and Grype, and validated at runtime via Goss-based health checks.

The TUI provides a three-pane interface for managing Firestream containers:

• Resources (left) — tree view of available containers with build status and run state
• Details (top right) — image tag, ports, dependencies, and credentials for the selected container
• Logs (bottom right) — real-time build output and container logs

On startup, Firestream automatically detects:

• Docker availability and version
• Builder image (nixos/nix) presence
• Nix store cache volume (architecture-specific, persisted across builds)
• Existing Firestream images and running containers
• Disk space and stale build locks

If Docker is not available, the TUI enters demo mode.

Browse containers in the resource tree. Each shows its build status (built/not built) and run state (running/stopped). Select a container to see its full metadata — image tag, port mappings, service dependencies, and default credentials.

Builds are queued with dependency ordering (topological sort). For example, building Airflow will ensure Redis and PostgreSQL are built first. Build output streams in real time to the logs pane, and builds can be cancelled.

Every container follows the <service>-<action> pattern:

make <service>-build         # Build the container image via Nix
make <service>-start         # Start (auto-builds if image is missing)
make <service>-stop          # Stop
make <service>-restart       # Restart
make <service>-logs          # Tail logs
make <service>-status        # Show container status
make <service>-credentials   # Print connection info and default credentials
make <service>-clean         # Stop, remove images, and delete volumes

# Examples
make airflow-start           # Airflow at http://localhost:8090
make postgres-17-start       # PostgreSQL 17 at localhost:5432
make kafka-start             # Kafka at localhost:9092
make redis-8-start           # Redis 8 at localhost:6379

# Batch operations
make containers-build-all    # Build all containers
make containers-status       # Status of everything
make containers-clean-all    # Clean everything

Firestream includes a code generation engine that scaffolds complete, deployable projects from interactive prompts or config files. Templates are embedded in the binary — no network access needed.

# Generate a PySpark application
cargo run -p templatizer -- spark -n my-etl-job -l python -o ./output

# Generate from a config file
cargo run -p templatizer -- spark -n my-app -l python -o ./output --config my-config.yaml

# List all available templates
cargo run -p templatizer -- list --detailed

Dockerfiles are non-deterministic — the same Dockerfile produces different images depending on when and where you build it. Base images shift, package mirrors update, and apt-get install resolves to different versions daily. Nix flakes pin every dependency to an exact content hash, guaranteeing the same inputs always produce the same output. This is what makes per-package SBOM generation possible: every dependency is known and traced at build time, not guessed at scan time.

On macOS and WSL, Nix builds run inside Docker transparently using a nixos/nix builder container with a persistent, architecture-specific Nix store volume for fast rebuilds.

Firestream provides composable Nix factory functions for building containers:

Each container definition in src/containers/firestream/<name>/ includes a module.nix (using these factories), an overrides.nix (for Python package overrides), and a docker-compose.yml (for local development).

Only requires Docker and Make. Nix builds run inside Docker automatically:

make airflow-start   # Works on macOS, Linux, WSL

Open in VS Code and click "Reopen in Container", or launch via GitHub Codespaces. Minimum: 4 CPUs, 8 GB RAM, 32 GB storage.

direnv allow   # Activates the Nix flake dev environment

cargo build --workspace     # Build all crates
cargo test --workspace      # Run all tests

Contributions are welcome. See the Contributing Guide.

MIT License

Built by Cogent Creation Co.