Bazel rules that fit
how you actually build.

The problem

Bazel adoption rarely fails because of performance or correctness. It fails because of ergonomic and compositional friction:

• Rule sets are narrowly scoped and difficult to integrate
• Cross-cutting concerns — metadata, tagging, packaging, rendering — are inconsistently handled
• Infrastructure and application workflows are treated as separate worlds
• Air-gapped, reproducible, and multi-stage builds are poorly supported
• Real production tooling — Helm, Packer, image pipelines, CI systems — is treated as an afterthought

Teams are left to fork and heavily customise rule sets, or abandon Bazel for simpler but less robust tooling. Slash2-3Dot is built for teams that refuse both options.

What we ship

A curated ecosystem of licensed Bazel rule sets, designed as cells that intentionally fit together — shared conventions, predictable metadata flow, compatible tagging, explicit integration surfaces.

Real patterns, encoded:

• Bazel + Helm pipelines with post-rendering and metadata injection
• Air-gapped artifacts for Packer and offline environments
• Reproducible packaging across infrastructure and application delivery
• Bridges from Bazel outputs into existing deployment ecosystems
• Toolchains managed externally from the rules, with declared support ranges

Why a paid product

Slash2-3Dot is a product, not a hobby project. Licensing exists to sustain the design quality and long-term maintenance that make Bazel usable beyond toy or single-purpose scenarios. You pay for sustained design effort, declared support boundaries, and the time you do not spend building bespoke internal rule sets.

See licensing →

North star

“This looks like how we actually build things.”

If a team can look at a Slash2-3Dot repository and say that, the project is succeeding.