google/fully-homomorphic-encryption: What the Repository Actually Ships

What google/fully-homomorphic-encryption is now, and who it is for

The name suggests a single tool. The README describes something else: a demos repository that points at two separate projects. HEIR is the MLIR-based compiler toolchain, and Jaxite is the FHE backend written in JAX that targets TPUs and GPUs. The README states that what started as a C++ transpiler five years ago morphed into those two libraries. Anyone arriving expecting the original transpiler is told to look at the archived codebase instead.

So the audience is narrow and specific. You are a compiler engineer or an applied researcher who wants to see FHE models running end to end without writing the cryptography. The README says the team is working through models including CNNs, and that the goal is to let developers use them "without requiring you to master cryptography or the complex nuances of FHE." That is the promise. The repository itself is the demonstration layer, not the compiler and not the backend.

If you are evaluating FHE for a product, this is the wrong first stop. There is no supported library API here, no versioned release of a runtime, and no compatibility statement about which HEIR revision a demo was validated against beyond what MODULE.bazel pins.

The data flow: a Starlark build around an MLIR compiler and a JAX backend

The repository's primary language is listed as Starlark, which tells you most of what you need to know about its shape. Starlark in this context means BUILD and MODULE.bazel files: the repository is largely a Bazel workspace that assembles demos from external dependencies rather than a large body of application code.

The top-level entries confirm it. There is a BUILD file, a MODULE.bazel, a .bazelrc, a patches directory, and a demos directory. The patches directory matters: when a repository carries patches for its own dependencies, it usually means a pinned upstream revision needs a local fix to build. That is a maintenance cost you inherit.

The compilation path runs through MLIR, which the README describes as the abstraction that lets HEIR "represent and scale complex models across diverse dialects." In practice that means a model is lowered through MLIR dialects until it reaches something an FHE backend can execute. Jaxite is named as one such backend. The demos directory is where those lowered pipelines are exercised.

There is a second, separate thread. The go.mod file declares the module fully_homomorphic_encryption and requires github.com/tuneinsight/lattigo/v6 v6.1.0 alongside github.com/bazelbuild/rules_go v0.62.0. Lattigo is a Go library for lattice-based homomorphic encryption. So the repository also carries a Go component that talks to an FHE scheme implementation directly, independent of the MLIR path. Two toolchains, one repository.

Getting the demos running: what the repository tells you to do

The top-level README does not print a build command. It points at the demos directory and says to check out the FHE Demos repository to see HEIR in action, so the entry point is the demos README rather than the one at the root. That is the first thing to read, and the fact that it is not reproduced at the top level is itself a signal about how much the project expects you to work out yourself.

Everything past that point depends on what that file says. The repository ships MODULE.bazel, so it is a Bzlmod workspace rather than a WORKSPACE one, and it ships a .bazelrc and a patches directory. Those three files are the build's configuration surface, and none of them is explained in the root README.

The Go side is declared separately. The go.mod file gives the module name and the toolchain version:

module fully_homomorphic_encryption

go 1.24.2

That directive means Go 1.24.2 or newer for anything that imports this module. The direct requirements listed alongside it are rules_go v0.62.0 and Lattigo v6.1.0. The README does not document a Go entry point or a command to run, so treat the Go component as a library dependency you wire up yourself rather than something with a documented invocation.

What you should expect from a first attempt is a dependency resolution step that may fail. The patches directory exists because something in the pinned graph needed a local fix. If the build breaks, that is where to look first.

Where the repository stops being useful

The original C++ transpiler is archived. The README is explicit: if you are looking for the original Google Transpiler project, see the archived codebase, and it links to a release tag rather than a branch. An archived codebase does not receive fixes. Anyone whose integration depends on that transpiler is on a path with no upstream.

The README also does not document rollback, version compatibility between a demo and a specific HEIR revision, or what happens when the pinned Lattigo version in go.mod conflicts with the version your own Go module already requires. Those are real questions for anyone embedding this, and the top-level README is silent on all of them.

There is a scope limit too. This is a demos repository. The README describes HEIR and Jaxite as separate projects with their own repositories and their own community links. If you want the compiler, you go to HEIR. If you want the backend, you go to Jaxite. Cloning this repository gets you the demonstrations, the build scaffolding, and the patches, not the compiler itself. Teams that want a stable dependency to pin in production should be looking at those upstream projects and their release cadence, not at this one.

HEIR and Jaxite versus using Lattigo directly

The clearest alternative is visible inside this repository's own go.mod. Lattigo v6.1.0 is a Go library for lattice-based homomorphic encryption, and it is a direct dependency here. Using Lattigo directly means you write Go, you choose the scheme parameters, you manage keys and ciphertexts, and you call the arithmetic yourself. There is no MLIR in that path and no model lowering.

The difference in approach is where the abstraction sits. HEIR takes an existing model and lowers it through MLIR dialects until it reaches an FHE backend, aiming to remove the need to understand the cryptography. Lattigo gives you the cryptographic primitives and expects you to know what to do with them. If your workload is a neural network you want to compile, the HEIR path is the one the README describes. If your workload is a small number of specific operations and you want control over parameters and noise budget, going straight to a library like Lattigo is less machinery.

Jaxite is the third position. It is a backend written in JAX targeting TPUs and GPUs, which is a hardware bet rather than a language bet. Choosing between these is not a quality question. It is a question of whether you want a compiler, a library, or an accelerator path, and this repository only demonstrates the first two in combination.

Maintenance, licence, and the upgrade cost you inherit

The repository is not archived, and the last push was on 2026-09-14. The most recent release listed is helrm, HE-LRM artifacts, dated 2026-07-24. The release before that is the transpiler, dated 2025-05-13, which lines up with the README's statement that the transpiler is now archived code. Two releases in roughly fourteen months, on different subjects, tells you the release channel is not a steady train.

The dependency surface is the real cost. MODULE.bazel pins external revisions, patches/ carries local fixes for them, and go.mod pins Lattigo at v6.1.0 with a Go 1.24.2 directive. Every one of those is a thing you have to move when you upgrade, and the patches are the part most likely to break silently, because an upstream change can make a patch unnecessary or make it fail to apply.

Licensing is Apache-2.0, per the LICENSE file at the repository root. Apache-2.0 includes an express patent grant and requires that you preserve notices and state changes. That is a summary of the licence text, not legal advice; if you are shipping this inside a product, have counsel read the actual file, including any notices attached to the dependencies it pulls in, since those carry their own terms.

Editorial conclusion

Adopt this repository if you want runnable FHE demos around HEIR and Jaxite, or if you are migrating off the archived C++ transpiler and need the Go and Lattigo path. Do not adopt it if you need a maintained standalone transpiler, because the README points to the archived codebase for that. Before building anything, read demos/README.md, confirm which targets exist in BUILD, and check which HEIR revision MODULE.bazel pulls in.

Frequently asked questions

Official sources

1. google/fully-homomorphic-encryption on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases