ContainerHive
Swarm it. Build it. Run it. — Managing container base and library images has never been easier.
Motivation
Managing container base images and library images at scale is surprisingly painful. Teams end up with scattered Dockerfiles, manual build scripts, inconsistent tagging, and no dependency tracking between images. CI pipelines are hand-rolled per project, caching is an afterthought, and reproducibility is a dream.
ContainerHive grew out of poc-container-image-manager, a Python-based proof of concept that validated the core idea: declarative, YAML-driven image management with dependency resolution, templating, and CI generation. The PoC proved the concept works — but being Python-based, it required a runtime, bundled platform-specific binaries, and wasn't practical to distribute as a single portable tool.
ContainerHive is the production-grade successor, rewritten in Go as a single static binary with no external dependencies beyond BuildKit. It takes the validated ideas from the PoC and packages them into something you can drop into any CI pipeline or developer workstation without setup overhead.
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>. 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.
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://containerhive.github.io/0install/containerhive.xml
See the installation guide for detailed instructions.
Documentation
Documentation is available at container-hive.timo-reymann.de, hosted on GitHub Pages.
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
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
1 maintainer
Metadata
1 maintainer
Release files for containerhive 1.15.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Built distributions (wheels)
| File | Reset | |||
|---|---|---|---|---|
| containerhive-1.15.0-py3-none-manylinux_2_17_aarch64.manylinux2014_aarch64.whl | Python 3 | none | Linux glibc 2.17+ ARM64 | Details |
| containerhive-1.15.0-py3-none-manylinux_2_12_x86_64.manylinux2010_x86_64.whl | Python 3 | none | Linux glibc 2.12+ x86-64 | Details |
| containerhive-1.15.0-py3-none-macosx_11_0_arm64.whl | Python 3 | none | macOS 11.0+ ARM64 | Details |
| containerhive-1.15.0-py3-none-macosx_10_9_x86_64.whl | Python 3 | none | macOS 10.9+ x86-64 | Details |
Total release size: 339.6 MB
Release files / containerhive-1.15.0-py3-none-manylinux_2_17_aarch64.manylinux2014_aarch64.whl
| Download URL | containerhive-1.15.0-py3-none-manylinux_2_17_aarch64.manylinux2014_aarch64.whl |
|---|---|
| Size | 81.7 MB |
| Tags | Linux glibc 2.17+ ARM64 Python 3 |
|
SHA-256 checksum How to use checksums |
e9c737d659d799cf2a53f35ec466a9f8b7b0c9044a9f7caff84e8422a5f43b15
|
|
BLAKE2b-256 checksum How to use checksums |
af8a5ce5d2477c05eb5a87af8d76d7bc03e73869cfbca0e7ce33b83eb8dfdad5
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/5.1.1 CPython/3.14.9
|
Release files / containerhive-1.15.0-py3-none-manylinux_2_12_x86_64.manylinux2010_x86_64.whl
| Download URL | containerhive-1.15.0-py3-none-manylinux_2_12_x86_64.manylinux2010_x86_64.whl |
|---|---|
| Size | 84.8 MB |
| Tags | Linux glibc 2.12+ x86-64 Python 3 |
|
SHA-256 checksum How to use checksums |
b5b406744b1bac66f98038bf37a013e46afb2a7075313bdbca790f4cf6865615
|
|
BLAKE2b-256 checksum How to use checksums |
aec22293e3e2ebaf3c540bf763ef67aec9c19399966ffbb472a29c6eba527e3b
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/5.1.1 CPython/3.14.9
|
Release files / containerhive-1.15.0-py3-none-macosx_11_0_arm64.whl
| Download URL | containerhive-1.15.0-py3-none-macosx_11_0_arm64.whl |
|---|---|
| Size | 84.5 MB |
| Tags | Python 3 macOS 11.0+ ARM64 |
|
SHA-256 checksum How to use checksums |
8b9044fe4736a37bf53d07986a81840390ad655f5dfebe6f1fa9dd401a435a0f
|
|
BLAKE2b-256 checksum How to use checksums |
70a16f1a823cef8019939282697172e2aa8a6feacd3e4a10c1dcbf841626cbb9
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/5.1.1 CPython/3.14.9
|
Release files / containerhive-1.15.0-py3-none-macosx_10_9_x86_64.whl
| Download URL | containerhive-1.15.0-py3-none-macosx_10_9_x86_64.whl |
|---|---|
| Size | 88.7 MB |
| Tags | Python 3 macOS 10.9+ x86-64 |
|
SHA-256 checksum How to use checksums |
e2e1f7f3c37864dbbb82bca1dfff0a5403cd6763aee7e3fa6c55fff471143826
|
|
BLAKE2b-256 checksum How to use checksums |
4891381a25b164dd4f9b48714c682f21f1c2d171a48d5e5288a4ddb5bfbac069
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/5.1.1 CPython/3.14.9
|
Security for containerhive 1.15.0
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.
