ContainerHive

Motivation

Managing container base and library images at scale is painful: scattered Dockerfiles, hand-rolled CI, inconsistent tagging and no dependency tracking. ContainerHive is a single static Go binary that resolves the dependency graph between your images, builds them with BuildKit, tests them and generates the CI pipeline. It is the production-grade successor of poc-container-image-manager.

Why not just do it manually?

Take a typical set of CI images, each building on another:

ubuntu-base      curl, wget, zip, internal CI tools
├── node            + Node.js, Yarn
│   └── node-browsers   + Chrome, Firefox, Playwright
└── python          + uv, Poetry, pip
    └── pre-commit      + pre-commit, global dev tools, toolchains hooks rely on

Doing this by hand means writing the CI pipeline yourself, wiring needs: so each child waits for its parent, handling tagging and pushing so children find the right parent, writing tests and hooking them into the pipeline, and updating all of it whenever an image is added or re-parented.

With ContainerHive you drop flat image directories into your project, and each Dockerfile references its parent with FROM __hive__/<image>:<tag>. ContainerHive resolves the dependency graph, generates the CI pipeline with the right build order and parallelism, detects which images have a test.yml and adds the test steps for them, and passes parent images to children without a registry round trip.

See Why use ContainerHive? for the full walkthrough with diagrams.

Features

• Next-gen builds: Powered by BuildKit, the modern container image builder behind Docker.
• Multi-platform ready: Build and push images for any architecture in a single workflow.
• YAML-driven management: Define and maintain image sets and variants declaratively.
• Reproducible layers: Guarantee consistent, bit-for-bit identical builds every time (given the same inputs).
• Testing built in: Validate images as part of the build process, no extra tooling needed.
• Smart caching: Optimized caching via S3 or registry backends, no manual tuning required.
• SBOM generation: Generate CycloneDX SBOMs for all built images using Syft.
• CI pipeline generation: Generate GitLab CI and GitHub Actions pipelines from your project definition.
• Bring your own BuildKit: Connect to any BuildKit instance — local daemon, shared cluster service, or sidecar in a hardened Kubernetes environment.
• Enterprise-ready: Built for scale, compliance, and integration with enterprise workflows.
• Nix and Chisel backends (experimental): Define the filesystem with a Nix flake, or cut minimal Ubuntu package slices with chisel — no Dockerfile needed.

Supported platforms

The following platforms have prebuilt binaries:

• Linux
  • 64-bit
  • ARM 64-bit
• Darwin
  • 64-bit (Intel)
  • ARM 64-bit (Apple Silicon)
• Docker (x86 & ARM)

Requirements

• BuildKit daemon
• S3-compatible storage for caching (optional)

Installation

Use 0install for automatic updates or install the binaries directly:

0install add ch https://0install.container-hive.eu/containerhive.xml

See the installation guide, then follow Get started.

Documentation

Documentation is available at container-hive.eu, hosted on GitHub Pages.

Maintainers wanted

ContainerHive currently has a single maintainer (Timo Reymann). To keep development healthy — reviews, releases, and urgent fixes even when the maintainer is unavailable — additional maintainers are welcome. You do not take over the project; responsibilities and expectations are discussed first, and shared ownership is the goal.

If you are interested, reach out to [email protected] to talk details.

Contributing

I love your input! I want to make contributing to this project as easy and transparent as possible, whether it's:

• Reporting a bug
• Discussing the current state of the configuration
• Submitting a fix
• Proposing new features
• Becoming a maintainer

To get started please read the Contribution Guidelines.

Development

Requirements

• GNU make
• Docker
• pre-commit
• Go

Test

make test-coverage-report

Build

make build

AI Usage

This project uses AI tooling to assist with development. All AI-generated or AI-assisted changes are human-reviewed and applied responsibly — this is not AI slop. Contributors are expected to uphold the same standard: AI tools are welcome, but every change must be understood, reviewed, and owned by the person submitting it.

Credits

Without these libraries this project would not be possible:

• syft by Anchore
• buildkit by the Moby Project
• container-structure-test by Google
• hadolint